How Developers Really Learn

Ask a room of developers how they learned their craft and few will say "from a course". Most will describe a mix: a book here, a project there, a colleague who showed them something, a lot of stubborn debugging. Learning to program is mostly learning by doing, and doing in the right way. Here are the habits that tend to work.

Practise on purpose: katas

Musicians play scales; athletes drill moves. Developers can do the same with katas, small exercises repeated to improve technique rather than to produce anything useful. The value is in repetition and variation. Solve a problem, then solve it again with a different approach, a different order of tests or a different language.

A good example is the Ordered Jobs kata, which looks like a small sorting problem and turns out to teach test-driven design, recursion and error handling. Because the problem is already solved in your head, you can focus on how you work.

Build side projects

Work projects are shaped by deadlines and by decisions made years ago. A side project is a laboratory with no customers: you pick the tools, you make the mistakes and you see the whole system end to end. Building a tiny web framework, as in the web framework experiment, is a classic example of a project whose point is the learning.

Make them small enough to finish. A finished small project teaches more than an abandoned ambitious one, and finishing is itself a skill. If you struggle to keep them going, sustainable side projects has some practical tips.

Read other people's code

Writers read; developers often do not. Reading a well-made open source project is like looking at a finished building after only ever seeing your own scaffolding. A routine that works:

1. Pick a small project in a language you know.
2. Start from the entry point and follow one feature through.
3. Write down what surprised you, whether good or bad.
4. Try to predict what the next function will do before you open it.

Reading bad code teaches too. You learn to recognise the smells that make a codebase painful, a topic that overlaps with the legacy page story.

Learn by breaking things

You remember the bug you chased for three hours far longer than the paragraph you skimmed. Treat bugs as lessons. When you fix one, ask what would have caught it earlier: a test, a better name, a smaller function. Write the test that would have caught it. Over time, your instinct for where bugs live improves.

The same applies to experiments that go wrong. A culture that allows small, fast failures learns faster, as described in failing enough.

Teach what you learn

Explaining a concept exposes the holes in your understanding. Write a blog post, give a short talk to your team, answer a question from someone further behind. You do not need to be an authority; you need to be one step ahead of the person you are helping.

Learn from people

Pair with a colleague. Go to a meetup. Ask questions in public forums and read the answers. People share the things that never make it into documentation: why they chose this approach, what they tried first, what they would do differently. Even an informal evening, like the one described in the developer tweetup, can seed ideas.

Balance breadth and depth

There is always a new framework. Chasing each one leaves you with shallow familiarity and little mastery. A workable balance:

• Go deep on fundamentals: data structures, HTTP, how your language manages memory and concurrency, how to test.
• Go wide in samples: try a different language or paradigm once a year to stretch your thinking.
• Be wary of fashion. Wait for a technology to prove itself before betting a project on it.

Keep a learning log

A short note at the end of each week, with what you learned, what puzzled you and what to try next, makes progress visible. It also gives you a record to look back on when you doubt yourself. The act of writing helps consolidate what you learned.

A simple weekly routine

1. One kata or small exercise, about an hour.
2. One stretch of reading someone else's code.
3. Some time on a side project, even thirty minutes.
4. One thing explained to someone else.
5. Five minutes to write down what you learned.

Even a modest version of this beats sporadic cramming. And as you practise techniques such as writing testable code, tools like isolating code with Moles and Fakes or injected delegates become a natural part of your toolkit rather than something to look up in a hurry.