Did you ever try to sing and clap the beat at the same time? For many people this is quite challenging, because when they concentrate on the lyrics they loose the beat and when they concentrate on the beat they stumble across the lyrics. This gets worse when they replace the clapping with playing an instrument. As long as one of the activities requires much of their attention, they’re hard pressed to continue the other in parallel.

When I first learned to play the guitar, I could hardly sing along. This improved over the years, but when I learn a new song that’s either a little tricky to play or to sing, I still find myself at first unable to do both in parallel. My solution — and that of any other musician I know — is to practice singing and playing separately until I don’t have to think about them anymore. Then I can put them together and after a little more practice I added another tune to my repertoire.

What does this have to do with software development, you ask? Fair enough. Here’s the answer:

“If you develop real-world software, in a new language and IDE, and try out TDD at the same time, you do at least 3 things too many. #focus” – @letsdeveloper

In software development we’re often faced with many things at the same time. For one, there is the current task. Then, there are frameworks or libraries and the programming language we’re using and the development environment of our choice, plus its extensions. That makes at least four things, which should already push us to our limits, if we’re unfamiliar with one or more of them. Nevertheless, I regularly see people trying to adopt, say, TDD as they go along.

@letsdeveloper but it works 🙂 – @yuriy_tymchuk

Do you truly believe that? To me this sounds like a statement of somebody with the sheepish grin of a person who actually knows better. Unless you’re one of these rare geniuses — but then most rules don’t apply to you anyways — I simply don’t believe you. No offense. It doesn’t work for me and it doesn’t for anyone I’ve met so far. By which I don’t mean that you can’t survive it. But you will find yourself distracted from your task, because of problems with your testing framework. Or kept from rigorous TDDing, because you miss the right shortcuts for the IDE. Or entirely kept from progress, because your thoughts circle around how to break down the task for TDD. In other words, you find that the individual challenges require too much attention for you to execute them in parallel. This tires you. This slows you down. This makes you do more careless mistakes.

If you find yourself overwhelmed, follow the first law of holes. The solution is not force or willpower. It’s divide and conquer. Just like the musician, you should separate things and train them individually. Then put them back together, when you’re more proficient about them individually. It pays of. I promise.

For me, Code Kata are a great way of practicing. The core idea is to work on an easy task. One that you may have already solved a dozen times or more. A task so simple, that you have all your focus left for whatever to want to practice. I use Kata to learn new programming languages. I use Kata to try new libraries. I use Kata to try new tools and I use them to practice methods like TDD, micro-committing, or even pair programming. I set an alarm clock to at most one hour and get started. When time is up, I lean back and reflect on what I achieved. Sometimes I record what I’m doing, to analyze it afterwards. This is where I usually have my aha! moments.

When I want to dive into something a little deeper, Code Kata are sometimes insufficient. When this happens, I try to find something a little bigger. I often refer to such things as pet projects, although I mostly treat them as throwaway products, just for training purposes. The important thing is that I try to keep the task as simple as possible to be able to concentrate on whatever it is I want to practice. Because the only thing I never felt the need to practice is coming up with challenging tasks. Those usually find me on their own.