One of the main pieces of advice that people give in learning programming is that you should pick a language and learn it. Just pick the language that you think you'll most want to do, get a couple of classes or tutorials on it, and learn programming!

I think that that's pretty bad advice. Someone who knows nothing about programming, picking up a language, and trying to learn that language is an extremely inefficient and slow way of learning how to program. It's like telling someone to choose their favorite saw, saw some things, and they'll eventually learn carpentry. Although they will learn a facet of it, it will be very hard for them to know how it all fits together.

This advice reminds me of The Karate Kid. Mr. Miagi has Daniel-san sand his deck and paint his fence and then, lo and behold, Daniel-san knows karate! It's a nice fantasy for the movies, but it's not very realistic.

Now, it's absolutely true that you need some sort of raw material to get into topics around programming and to practice it. But focusing on the language or that you have to pick the right language, is extremely counterproductive.

In language learning theory, a lot of ink is spilled on what is the most effective way to learn. And there are many studies that talk about how learning facts is very counterproductive for learning, when in fact, what you should be learning are ideas, or what I like to think of as concepts. This doesn't just apply to programming, it applies to many different areas. If you want to learn chess, you sort of have to know the rules of chess, but that doesn't teach you how to play chess. Experts also have to weigh bigger ideas around what those rules mean. They evaluate pawn structures and board control and lines of pressure. Some of this is experience for sure. You won't get better at chess by only reading about it, but you can advance pretty quickly by also learning about the concepts once you have the basic rules down.

Understanding concepts is what is most important and then after that, learning how to apply the tools to achieve those concepts. So if you want to become a programmer, you need to learn the concepts behind programming. I have built systems in about ten different languages over my career and the thing that has let me do that is that the concepts are applicable no matter what language I am working in. The rest is just the details of figuring out how to express those concepts in a new language, which is much easier to look up.

Now, what does it mean to focus on the concepts? What are the actual practical things that you can do?

When you're presented with a new concept, what you should be doing is sitting down and trying to build some sort of mental model of how it works, to think through and build in your head a way of thinking through these specific types of problems.

So for example, if you're just starting out learning programming, you might run into arrays. Sit down and think about a representation that you can reason about. What would an array look like if it was a physical thing? Would it look like pigeon holes that you see at hotels with different room numbers on them, or they may be P.O. boxes at the post office? When teaching this concept, I will show the students one of those seven day pill holders and put 0 through 6 on them to try and build some sort of mental representation of what is essentially an abstract concept that doesn't actually exist. But having a mental model of how it works in your head will allow you to problem solve how to program with arrays.

What about when you get into object orientation? If you're looking at a number of objects that are working together, if you don't have a way of representing this in your mind, you're going to get very quickly lost. Everyone has had the experience of jumping between files and not having any clear idea of what's going on. And you can't remember what object called what method? Next time, try and sit down and think about it this way: if these objects were on this table in front of me, what would it look like? Which objects are inside other objects? Which objects are talking to each other? Are some of these objects in an array?

Learn how to visually lay this out and draw it on a piece of paper. Draw boxes for each object in the system. Draw lines between them that are method calls. Draw little boxes inside of them that represent instance variables and those are objects that are inside objects or variables that are inside objects. Where does everything live? And where is it at?

Why do this? Because the files themselves will never represent how the system works. They are blueprints, not a house, and you need a model of the house to understand what's going on.

Once you have something like that written out, it is much more possible to know what file to go look at for a certain part of the code. Because you're saying that this object is calling this method on this object? You know the type of that object and can now go to that class and look up what that method is.

What about the services on a server that are all working together? You have your web server, you have your database server, how are these working together? Again, draw it out on a piece of paper. In your head, imagine that they are actual computers in a room. How are they laid out? What wires are connecting from one computer to another? You can start to reason about these things, once you have some sort of representation that you can work with in your head. Just knowing the facts about them isn't good enough, it doesn't take you far enough, you need to have something that you can work with that makes sense to you.

Now, I don't know if this works for everybody. This physical representation idea. But it is vital to my understanding of programming. I am a very visual, physical type of learner. I grew up with Legos and Lincoln Logs. I am someone that can see a visual representation of things in my head, as I'm working through them. A lot of that came through experience. But the only way that started was by doing this exercise and trying to build a mental representation of programming concepts. Once I understand the concept, I can start to understand other concepts by putting these together like Legos.

Once I have my Lego house, I can start to put chimneys on it, I can put windows in. This is how I understand these concepts working, by having a visual representation of them in my head. If I run into something that doesn't fit my mental representation of it, that's good. I don't have to throw everything out, it means that I'm modifying what's already there and I see that now as the process of learning. If I have a concept of an array, and then I find out about queues and stacks, and somehow those don't fit with my representation of an array, that means I need to fix my representation.

So the next time you run into some sort of concept that you don't understand in programming, sit down and try and build a representation of it. If you're just copying and pasting facts, you're never going to get to a point where you're programming confidently and where you're building something new based on concepts that you've learned before. Understanding the concepts enough to try new things with them is what being a programmer is all about.