Following Hakuna Matata or always striving for perfection are two very different ways of living your life. In the short term Hakuna Matata (which means “No Worries”) looks tempting, but there’s also happiness to be found in the strive for perfection through a continuous improvement mindset.

Image courtesy of Wikimedia Commons

Earlier this year I went on a skiing vacation for a week. Looking at the people in the slopes, there were many different styles of skiing. Some were good, some were bad. Some looked concentrated, some looked happy. But I think that everyone enjoyed being there. During the week I thought about different mindsets for skiing (mindsets that are also applicable to programming, don’t worry – this post is about programming and not only skiing).

I think that by just watching the people skiing, they can be grouped into four categories that reveal their mindset. Are they living by Hakuna Matata or are they continuous improvers that always want to learn? Those different mindsets are important when you form a software development team.

Where’s the Beer?

Image courtesy of Wikimedia Commons

To some people skiing is just an excuse to have some more beer. You’ll never meet them early in the morning – they are still sleeping. Once out in the hills they take the lift up, goes slowly down a green or blue trail to the closest ski-in-ski-out restaurant where they have a beer before lunch. When the beer is finished, they order lunch (with another beer) and then it’s time for an after-lunch beer. Times goes by, so there’s really no need to go out skiing again before the after ski starts, so they head for another beer instead.

To the beer-drinkers the skiing is merely an excuse to have some beer in the sun in the afternoon. If you’re a ski team these are the people you want to get rid of. They won’t be part of your skiing effort, they will only stop you from searching for the perfect snow as they prioritize keeping close to the restaurant.

If you’re on a programming team these are the people that are there for anything but programming. They might be in the business because they want a high salary. Or because they like computers (as in playing games). They are not interested in programming and as a consequence, they are not skilled at it. This is the kind of personality to avoid having in your team.

Just Go!

The faster the better! Having control on what you do? Nahhh… why? This is the attitude many small children have. (at least until the first time they crash and hurt themself). For a 4 year old it’s perfectly natural to have this attitude. For adults – it’s more scary. Having an adult going down the hill at high speed with total lack of control is scary – there are other people in the trail as well.

In a programmer team this is the “let’s start coding” people. The ones that never enables their brain before starting typing. The ones that make the same mistakes over and over again and just laugh at it and goes on to do the same mistake again. In some ways I’m jealous on these people. They are the true masters of Hakuna Matata. They are having fun. They don’t care.

They don’t care if their commit breaks the build. They don’t care about the long term effects on code quality. Although they can be fun to work with thanks to their inspiring attitude, do you really want them on your team?

Basics are Enough

The “basics are enough” skiier learnt the basics of skiing – probably by being put in ski school as a kid. Once the basics are learnt, they see no need to improve, they use the same equipment as they’ve done the last 20 years with the same skiing technique as the last 20 years.

They can ski and they do it safely, within the margins of their skills, but they won’t go down a black trail.

Programmers with this mindset typically ends up as “maintenance developers”, working on the same in the same system with the same technology. They see no need to improve, neither themselves or the system they’re working on, until one day it’s too late. The system is replaced because the code is in such a bad state that it can’t be saved any more. The programmers look for new jobs – only to find that all of their skills related to technologies that went out of fashion 10 years ago.

Nevertheless there is a place for maintainers – they often have the right mood to take care of a system over several years without getting too bored. But you can’t have only maintainers on a team, you need some continuous improvers as well that drive the change needed.

Continuous Improvers

Image courtesy of Wikimedia Commons

The continuous improver is only happy when a turn in the slope is better than the one before, if it is the best one that day, or even the best they’ve ever done. There is no such thing as a turn just for fun. Every turn is an opportunity to strive for perfection. The continuous improver flows down the hill under perfect concentration, experiencing the joy that only the flow of a perfect run down the hill can give.

The continuous improving programmer always catch up on new technology and knows what’s next up and knows how to turn new technology into practical use that gives benefits. The continuous improver keeps the code base tidy, performing small refactorings on the go to reduce technical debt.

The continuous improver might be slower sometimes, due to the extra time required for learning and improving. But in the long term, the continuous improvers are blazingly fast because they quickly gain so much more knowledge, insight and skills than their peers.

Many of us were the kids that could not go to bed until something compiled, or we figured out how something worked. When we weren’t programming, we were thinking about programming. Things in nature reminded us of concepts in programming, it was an all-consuming drive to learn as much as we possibly could about it. I never dreamed that I’d be working with C professionally all those years back when I was up at night modifying the source code to my BBS system.

Tim Post

To the continuous improver, software development might be a job, but Coding is a Passion. The continuous improver is a rare species – I’d say only ~10% of professional developers are continuous improvers, but they are the ones that you want on your team, if you can handle elite performers.