Learning to program

Tim O’Reilly has an interesting post on the O’Reilly Radar where he references some discussions they have had when it comes to learning, and in particular learning to program.

In essence it requires practice, and we need to work hard at it. There is however a bit of a paradox here. If you are going to practice that means doing the same thing over and over again with small variations to get good at it. I see in the discussions that it is often compared to learning maths, and I have no doubt that my utterly horrible math skills stems from the fact that I never took the time to sit down and practice. But the repetitions is difficult when it comes to software, as it is written to avoid doing repetitive tasks and we always learn that one of the basic principles of software development is DRY.

The way we usually work doesn’t really foster continuous repetition and learning either. When you are working in a project the solution is created and then you move on. The next time you get to try the same thing with a little twist from what you learned the last time around, is when the next project kicks off. With the worst projects around this means 2-3 years between each repetition. And according this definition of mastery you’re going to have a hard time reaching that:

According to Dizzy Gillespie, it takes ten years of practicing your butt off to achieve Mastery. His statement has been backed up by scientific research which shows that to reach a very high state of mastery, a task should be repeated about a million times, which takes about ten years. Better get busy! – (Sound the Trumpet, pp 67-68)

Related to practice is also another pet peeve of mine: We need to practice at it and use real OO. Usually we’re not good enough at using the power of our OO languages like encapsulation and separation of concerns. You can of course debate whether OO is the best way for developing software, but if you are using an OO language we need to get better at the basics. I believe that if we practice these basics more it will give us big returns in regards to quality and cost of systems. Way too many systems are built around POJOs acting as data carriers with all kinds of logic scattered all over the system.

So how and when to practice? Most companies should have structures for facilitating this during work hours, but ineveitably you will also need to spend some of your own time. One thing I like doing is participating in small projects. The smaller the project the sooner I get to move on and try a new angle on how to do systems development. Other ways may be to participate at a code dojo, or contribute to Open Source projects. I haven’t really tried a code dojo yet, but it sounds like a great idea. How would you practice?

The bottom line is that we can not read about something like programming and get good at it. Mastering software development requires practice and we need to focus on finding, using and creating spaces for practice.