Different ways to get better at programming

Painters in training spend most of their time understanding the theory of light, pigmentation, dilution and so on, and put these to practice through painting exercises that allow them to explore the theory and witness it play out on canvas.

When a painter graduates from school, she begins to put her knowledge and skills into use, painting “actual” paintings. To do that, every bit of prior knowledge and exploration of the brush and ink on the canvas comes to her fingertips, quietly but faithfully guiding her every decision to stroke where, how hard to press against the fabric, with what colours and how much water to mix into them. Without studying, the furthest a self-fashioned painter can go is a poorly expressed abstractionist.

Good writers, singers, carpenters and programmers go through the same process of studying as painters. To even get close to being able to make good work, we must first seek an understanding of the principles and tools of the craft.

The way new programmers do this is quite straightforward. We listen to a less-new programmer tell us how things work with a computer, the internet and so on. Things like how the right webpages get delivered to the browser when we access websites, how Chrome renders the HTML and CSS and applies the JavaScript to display things, or how conditional statements are used to determine who gets access to which pages are first told to us and then demonstrated to us. Then, at some point, we try writing the code to prove it to ourselves, and we internalise it as knowledge and we gain a skill.

Three months of this and any person can become adept at identifying the best way to implement an algorithm to use one instead of nested for loops. I’ve seen this happen at General Assembly’s web development bootcamp once when I was in it, and I’m again seeing it with the new batch of students. This is great, but it isn’t good enough.

We need to practice with projects. It’s possible to be great at solving coding challenges as they’re presented to you and still suck at building software.

Coding challenges are designed to train us to solve complex but isolated programming problems.

A project is different. It forces us to carefully consider every HTML element, every function, every library that we use, the order we should be writing them, how extendable it will be in the future and so on.

There’s getting good at solving specific programming problems, and there’s getting good at building software. The knowledge and skills involved are not mutually exclusive, but I think it’s easier to solve coding challenges than to design good structures.

I’ve been allocating too much time to coding challenges and it’s come to nib me in the butt recently when I worked with a team on an actual product. That taught me a lesson. Regardless of the truth, if we are to get better at programming, we must be deliberate in how much time we spend on Codewars versus Terminal and our code editor. Ignore this and risk getting fired at your first dev job.