For beginning programs, there are two classifications that I remember being taught way back when. First, there were the class of problems that can be summed up by "Write a program to generate a sequence of Fibonacci numbers". These were all algorithmic / somewhat math based problems. They usually came from classes that were sponsored by the Engineering side of the school. The second classification can be summed up by "You have two files, each containing a list of [data items]. Produce a program that generates a third list of [data items] [having a given characteristic]". These seamed to me to be more practical / instructive.

So as a marketing person, think of some types of reports you would like to see given some data that you have. Remember that the input data should consist of a number of items (records or lines) that have consistent characteristics, somewhat like you would get from a spreadsheet. Maybe you want to get a list of how many customers from each zip code bought a blue widget vs. a green widget. So in this case you would write down a mock up of what your resulting report would look like, then figure out what manual steps you would do to get there.

When going through this exercise manually, pretend that you can't remember anything but your current thought, and that you have to write down everything else. Each thing you write down on paper translates to a program variable. Then, every time you have to change what is written down, make sure that is done via a repeatable list of steps. That then translates into an algorithm, which directly translates into lines of code.

Most of the first programs I had to do in "the real world" consisted of simply taking data from multiple sources, and making reports that others in the business could analyze. In some cases it was simple compound interest reports based on employee deposits/withdraws in a company savings account (kind of like an in-house mini credit union). Other times it was something like an Inventory Turns report for our head of purchasing (a report of how many times each product would completely cycle in inventory in a given month). These were all done on a Unix command line, using a combination of shell scripts, sort, join, uniq, and awk (this was well before perl came out). Eventually this type of work became second nature (so i didn't have to think through the logic), and I was able to move on to more advanced programming.

Thank you! That is great advice.

This is a great point. "Just start" can be bad advice. People thrive on constraints.

Build something that you do every day in your job. Build something where you click a button and you get a response.

Build something that makes your current job easier.

Build a piece of your favorite app, a very small piece.

When in doubt, build a to-do list.

I agree. I think it's a lot easier to get started if you have SOME idea of what you want to accomplish or what direction you want to go in. And who couldn't use a good to-do list?