What they don’t teach you about programming

Often someone will come to me and inquire about following the path to become a programmer. These people can come from a range of backgrounds, such as data analysts, pilots, robotics automation, etc.

I find it hard to provide the right advice because what is right for me might not be right for them.

What makes me suitable able to help share my insights into what makes a great programmer? I've been programming for a long time. I started when I was 11 years old and over the years I have filed patents through my employment at IBM and Ericsson, as well as program the web site for Mattress Online completely from scratch. I'm even building Flowtelic, my own note-taking app to help inspire a generation of thinkers and doers.

So with this insight, I've reflected on what makes the difference between where I am in my programming journey to those who are just starting out. Let's explore what is often missing from most education around programming, but I feel is more important than learning the latest language or framework.

To become a programmer, you need to be:

• Curious—have an intrinsic desire to make it work
• Focused—know exactly what you are trying to achieve
• Determined—needs to take priority over other things
• Slightly obsessed—think about it when you’re not at the computer

Most people's motivation usually comes from:

• The idea of remote working
• Job security
• Money

But when I speak to them, what is lacking is an innate excitement about BEING a programmer. As in, sitting for hours at a time and just wanting to create something.

So while I can recommend a pathway, give insights into what goes on in each area, and explain what the jobs look like—I can’t make them want it. And I mean really WANT it. That can only come from them.

But I’ve been reflecting on this. What is different between them and me? What is missing from those who are starting out programming and the struggles they experience? What makes a good programmer different from a mediocre one? Let’s explore.

1. The ability to abstract

Thinking in abstractions is the number one skill when it comes to programming. The code represents some logic that in turn represents the real world. For example, in e-commerce, the customer ‘object’ represents a real person who is buying a product. That person may buy many products, one product, or refund a product. All this is abstracted through a ‘customer object’.

The same is true for conceptual logic. For example, if I’m building a text editor, I have abstracted the concepts of blocks (paragraphs, titles, lists, etc.), selection (where the cursor is), the render (how it’s displayed on screen), etc. Knowing what is abstracted and where, and what their role is in the system is vital. For example, is a cursor position the same as a selection? What if it’s a multi-user edit and there are multiple cursors?

2. To see in your mind’s eye what’s not in the code you’re looking at

Programming software applications can become very complicated. When you look at a piece of code, it’s performing a set of responsibilities in a larger system. How do they relate to the other parts of the system that aren’t on the screen?

This is where your ability to see the ‘system’ in your mind’s eye and have an awareness of what it might do as a result of you changing the code in front of you is vital.

For example, you’re working on an API response that gets the customer orders for a given customer. You find that it’s running out of memory because one customer has thousands of orders. So you want to introduce pagination (where only a part of the list is sent at a time). How does this impact the code that depends on it? What client programs expect the full list? Will it be backward compatible until the front end is updated with the “Load more” button? What if a customer wants to find their older orders and can no longer search their web page?

Let’s try an example. Close your eyes and imagine a car. Conceptually in your mind’s eye, you know where the engine or motor is, where the driver’s seat and steering wheel are, where the passengers go, where the doors are, and where the wheels are.

You also know that the function of the steering wheel is related to the wheels, the pedal to the engine or motor. But the doors aren’t critical to either of those.

You have a concept map in your mind of how things relate together. Because you’ve seen and experienced a car, it’s easier to visualise.

But in the mind of a programmer, you can do the same but with abstract components. You can see the server, the API layer, the authentication layer, the middleware, the database connector, etc. These are all components in a larger system, that have a relationship with the other components.

When debugging a program, this concept map that you have will help you quickly identify where the impact of the bug is, and where the possible causes might be.

3. Data structures are the foundation

Most applications need to store some type of state. This might be in the running application (such as where you’ve filled in your email on a form) or could be a database (such as saving customer details).

How you reason about this state is absolutely vital. Get it wrong and you find that you can’t implement the code you need because something is missing. Get it right and everything seems to fall into place.

Being able to understand how that state will be used is a crucial skill. For example, if I’m recording purchases by a customer in a database, I may want to store their details such as name, email, and address. Then I might want to record the list of products they have ordered in a ‘purchase’ table.

Conventional learning will teach you how to relate the purchases with the products so you can easily allow many customers to buy the same product. All is good.

Then you realise you need to increase the price of the product. That’s when it dawns on you. Everyone who purchased previously will now have their purchases look like they paid the new price. The data structure was insufficient to model the real world.

So having an awareness of what the implications of the data structure is, is vital. This also means you need to have a strong awareness and understanding of what goes on commercially running a business. You need to know that prices might change, customers might cancel orders, discount might get applied, or partial refunds might get issued. How you model this in your data structures can have a huge impact on being able to maintain the code over time.

4. The ability to recall how to do things

I like to call this the ‘blank sheet of paper’ problem. Often a new programmer will be learning from other code and can easily reason about what it’s doing and how it works. Life is great.

Then they’re faced with building their own project—from scratch. Where do they start?

Knowing how to create something from scratch starts by understanding the building blocks that need to be in place. You may have a database, server API, client API, front-end UI, and the logic that renders it. These are all building blocks that are used to assemble an application, each with their own set of responsibilities. This can be overwhelming for new developers as they’re often only introduced to each block, and haven’t spent enough time assembling them, swapping them for a different technology, or creating their own.

5. The obsession to tinker and create

The final critical skill that will determine if you’ve become a great programmer is your curiosity to tinker, extrapolate, and create.

From this example, let’s say you want to create a new text editor, but you’re using an open-source editor library and you following their documentation. You understand the concepts. What do you do after learning this? Do you move on to the next thing to learn?

No. A true programmer will take this editor and start to break it, rebuild it, adapt it, and try out new ideas.

Start to explore doing things that the editor doesn’t necessarily do from their documentation.

For example, you might want a toolbar to appear only when you select text. Or you might want to be able to style the text from a predefined set of styles. Or you might want to allow the user to drag an image into the document. None of these may be examples in the documentation, so what do you do?

You try to reverse engineer how other plugins are done and extrapolate how it could be used for your own goals. You reach out on forums and scan GitHub issues to see how others approach solving the problem. Your curiosity pulls you forward and along the way you start to become an expert in it.

What if you aren’t curious or obsessed with programming?

If you just don’t have the innate drive to be curious and obsessed with programming, then you’re going to be on a slower path to success. Simply because you’ll try out fewer things and put in less time. Boredom will creep in and you’ll move on to other things. This is a common pattern I see. People like the idea of being a programmer, but their actions tell the truth.

That said, do not despair if this is you. I said it will be slower, but not impossible. Being obsessed means you’ll gain the skills more rapidly. Not being obsessed but still putting some time in will mean you’ll still gain skills, but it will take longer. Just be careful that you’re actually progressing with deliberate practice and not churning over the same beginner exercises. You need to stretch yourself.

Over time, you’ll naturally gain these skills mentioned above. That will make it easier, and when things are easier, you'll enjoy them more and do them with less friction. That’s when true mastery can settle in. You just need to stick with it long enough for that to happen. You need your 10,000 hours.

I hope that you’ve enjoyed this article. Email me your thoughts as I’d love to learn more about your experiences and find out how I can improve my teaching.

If you enjoyed this article and want to learn how to improve your own ability to recall the information you learn—particularly if you want to be a great programmer—then check out my book Atomic Note-Taking.