Whether you just installed rails for the first time or wrote a 32-bit kernel in Rust for fun, you can increase your rate of improvement by deliberately practicing programming. Thanks to advances in neuroscience, our understanding of how people learn has grown tremendously in recent years, but there is still one big problem: it’s hard to apply the general principles of deliberate practice to any specific domain other than music or sports.

Since it’s my job at General Assembly to help people learn to code, I’ve thought a lot about why some students learn faster than others. In this essay, you’ll learn 3 simple things you can do to learn faster.

1. Repeat yourself

There’s a reason why golf courses have driving ranges. Repetition strengthens the neural pathways in your brain that get triggered when you perform an action. The more you do something, the more subtleties you start to notice, and the better you become at doing that thing.

There are lots of ways you can build repetition into your programming habit, but here are my two favorites:

  1. If you’re new to a framework or library, it helps to go through the motions of creating a new “hello world” project several times.
  2. If you’re in the middle of working on an app, try rewriting a feature immediately after you get done building it. To be clear: rewriting (starting again from scratch) is not the same as refactoring (modifying existing code).

2. Get out of your comfort zone

You should constantly be adding new tools to your toolbelt. Try a new library, or language, or feature of a language as often as possible. Experts become experts by mastering a ton of tiny things. Never fool yourself into thinking that you are focusing on your strenghts when you’re really just stagnating and going through the motions.

A good way to tell if you’re learning enough new things is to measure how fast you usually build things. If you pride yourself on being able to build an app in 2 hours, using muscle memory alone, you’ve made the classic mistake of under-investing in production capacity by focusing solely on short-term output.

A good rule of thumb I’ve picked up from Chad Etzel (jazzychad) is to make sure you learn at least one new thing in each of your projects.

3. Seek negative feedback

Hearing “you’re doing a great job!” may feel good, but it’s far less useful than specific, timely feedback on areas where you can improve. Pair programming with an expert is by far the best way to get this type of feedback, but code reviews also work. The point is that you should get other people to look at your code as much as possible, and you should ask them to tell you what’s wrong with it.


Repeat yourself, get out of your comfort zone, and seek negative feedback. If that doesn’t sound like very much fun, it’s because it’s not. If you’re serious about getting better at anything, pain is your north star.

You know you’re doing it right when it hurts.


Do you have anything to add? Let’s chat about it on twitter.