In the past few years, an idea has grown in popularity among software developers: That “Deliberate Practice”, that is practice only for the sake of practice, is the best way to improve your programming abilities. Code retreats, for example, formalize this very strictly: Every 45 minutes, you delete all the code. While code retreats are fun and you can indeed learn a lot there, I still think that this idea of “Deliberate Practice in Software Development” is overrated.

When people argue that software developers should do deliberate practice, they usually say something like “Good musicians don’t just play beautiful music every day. They spend hours practicing scales.” But can you really compare music to software development? I think not. And yet I have not seen a single empirical study backing that deliberate practice makes you a better developer.

I know one example does not prove anything, but here’s how I try to improve my skills: I pick an interesting project and work on it. For weeks or months. And I try to ship something to the public at the end - Usually I decide upfront what I want to ship. And because it’s a side project anyway and there is no schedule pressure, I try to do really good work.

Working on a project for several weeks or months has some advantages to doing a Kata and then deleting the code. For example, I have to live with the decisions I made earlier. I have to refactor as I learn, and I have to grow an architecture. I tried learning clojure just by doing the examples from the book. For weeks, I just didn’t get it. Then I decided to start a project using clojure. Now I see progress in my learning every day I work on the project.

I said before that you can not compare practice in music to practice in software development. This is because musicians practice mechanical skills. This is compared to us developers learning to touch-type or learning the keyboard shortcuts of our IDEs. Of course we should practice these mechanical skills! And of course we should learn to recognize patterns and read code! But that does not mean that you have to deliberately practice programming itself:

There's a difference between what we do as software engineers and what a violinist (or anything else that requires physical practice would do). A violinist spends hours practicing methodically because they are teaching their brain very specific patterns of how to interact with an instrument. Practicing software engineering also involves learning patterns. The more projects you do, the more you will learn (hopefully) about what works and what doesn't. DXM on stackexchange programmers

It is said that it takes 10,000 hours to become an expert, although it might be more like ten years. But this does not necessarily mean that you have to do deliberate practice the whole time. Craftsmen usually learn on the job. They learn to create beautiful things while creating beautiful things. If software is a craft - and I really believe it is - we should create beautiful things (and maybe try to ship them) and learn as much as we can in the process.

I think, at least in this respect, programming has some things in common with photography. In photography, there is no sense in deliberately practicing something. Just go out often and try to shoot beautiful pictures. If the light is bad, you’ll automatically practice available light. If your subjects are moving fast - action pictures. And so on. So, in closing, I want to quote Mike Spinak, a greate nature photographer:

If you want to learn how to spot meter, you don’t need to sit in your living room and take practice shots spot metered on the door, the wall, the window, the carpet, etc. If you want to learn macro photography, you don’t need to take practice shots of pawns on a chessboard. If you want to learn off-camera flash photography, you don’t need to take practice shots of your bored son sitting on a stool with his hands in his lap, staring vacantly. Nothing is stopping you from doing real photography – i.e., trying to make worthwhile photos – and learning your spot metering, macro skills, flash techniques, etc., in real photography situations, instead. If you want to better your photography, then treat every shutter actuation as an opportunity to make something significant. Treat it that way by making your best effort. Learn by actually doing, not by setting unnecessary, artificial boundaries, and then hollowly going through the motions. Practice makes practice </div> Read more about how software architecture, design and technical practices impact your agility in my book "Quick Glance At: Agile Anti-Patterns": Buy it now!

You might also be interested in...