First, realize that the world of programming (and technology in general) is full of a lot of very opinionated people. They will say that this or that language is terrible; that language A is better than language B; that learning language X will actually harm your ability to be a good programmer; or that language Y is slow. At this stage, most of this advice can be safely ignored. Comparing and contrasting technologies will be useful and interesting later on, but even then, a lot of the time it’s comparing two tools that do almost exactly the same thing. Some of this advice may involve different ways to learn programming. If someone is willing to teach you, that is probably your best bet. This post is roughly how I learned it. There may be better ways, but bear with me for a little while.
Step 1: Learn some syntax and semantics.
At first, don’t worry about doing anything useful. You just need to learn the mechanics of some programming language: what are the words and symbols in your language, and how are they allowed to go together (this is called the syntax)? And when you put the symbols together in this way, what does the computer do (this is called the semantics)? It doesn’t really matter which language you start with, and once you know one, you will find that others have a lot of similarities that make it easy to learn. If you have friends who are programmers, you may want to pick the language that they use, so you get the most out of their advice. If you don’t, I’ll go ahead and recommend Python. I like the language, and it has seemed to have a shallow learning curve. But again, if another language sounds more interesting to you, or seems to be used more often by people you know, or for the things you want to do, pick that. Search the web for a beginner-level tutorial in the language you pick. (For example, type “Python tutorial for beginners” into Google. You will find that you do Web searches a lot, even as an advanced programmer, because there’s just too much information to keep in your head. The most common types of searches are “how to do X in language Y”, and “X problem happened, what do I do?”)
Go through this tutorial until you understand how the basic primitive parts of your language work: variables, if statements, loops, functions, arrays, structures/objects/dictionaries (they are called different things, depending on the language), reading input and writing output to the command line. Running programs from the command line. How to reference code that’s in a different file, module, or package. Learn a little bit about classes as well (they are basically just structures or dictionaries on steroids, but they get used a lot). Once you understand this stuff, move on to step 2.
Step 2: Learn to design programs.
Once you learn the basic syntax and semantics, i.e. what a program really is, you then need to learn how to think about programs, particularly programs that you haven’t written yet. This process is called design. The best resource I’ve seen on this was the one I encountered during my Freshman year at college: Chapter 1 of Programming and Problem Solving in Ada (Ada was the first language that was taught in my college courses. I don’t recommend it as a first language, but I do recommend this book). I had been fortunate enough to be exposed to computers as a child and in high school, but it was this course, and in particular this chapter, that made me a programmer. By this I mean that, after that, I was really able to write programs to do what I wanted them to do. These programs weren’t necessarily very good, and there was certainly a lot I didn’t know about technologies one needs to make programs actually useful (like APIs, Web servers, and frameworks), but I could at least figure out how to write the logic of a program. I’ll try to hit a few of the high points that were covered in that chapter. You may not need the book if you google some of these techniques and experiment with them.
Divide and conquer
In solving a complex problem, it often helps to break it down into less complex sub-problems. These sub-problems will often correspond to parts of the program that you need to write: modules, functions, classes, sometimes even separate individual programs.
Represent the problem or program visually
This can take different forms. For example, as you divide and conquer, you may make a diagram that shows a box for the main problem at the top, branching out into boxes for each sub problem below (and sub-problems of each of those, on down). It may take the form of a flow chart of the sequence of operations in a program; a “block diagram” or “data flow diagram”, showing the components and how they are connected. There are also diagrams that show how the data is structured, such as UML class diagrams, and Entity-Relationship diagrams. You can search for these types of diagrams for examples. You don’t need to do these diagrams the same way, or using all the exact symbols, as the examples you find. What’s important is that they help you understand and communicate about the problem and solution.
Write pseudocode
This technique was most helpful for me when learning to program, and I still use it sometimes. Pseudocoding means writing down the steps of a program, but in a loose combination of English (or your own native language) and code. For example, you might write a loop, but in the body of the loop, describe what should happen in English. This can be combined with the divide and conquer approach: Write a list of the high-level steps that the program will need to do. Then write a more detailed list for each of those steps, and so on until things are clear enough to start coding. When you code it, you might write a function by coding each of the steps in one of those lists. Again, what’s important isn’t following a particular format, but getting things clear for your own understanding or communication, without having to worry about the vagaries of the compiler.
It may seem like experienced programmers can sit down and just start coding. Sometimes that means that they have internalized some of these design techniques so that they can do them in their head, even unconsciously. But they still come in handy when you want to communicate how a program works, or how you want it to work.
You can practice your design skills with toy programs, such as solving a maze defined in a text file, or writing a program to play tic-tac-toe. Or you can try to combine this practice with step 3.
Step 3: Learn a technology stack
Now for the hard part, but also the part that lets you make things that are actually useful. Picking a technology stack depends a lot on what you want to do, but there may still be many competing stacks. Pick one that seems to have good tutorials (say Rails or Django); go through some of them, up to the point where you at least know where to look up the functions and classes you need to do something; and then dive in and try to make the app you’ve always wanted.
Step 4: Keep learning
As you may have guessed by the amount of “it depends”, software development is a very broad field that is always evolving, so it’s impossible to know everything. Expand your knowledge by reading blogs, watching conference talks online, and following the writers/speakers on Twitter.