Learning new ways of working by going to extremes

As software engineers, we have to constantly update our skills. Each day some new javascript framework is created, yet another CI tool emerges or a new version of some library is released. It’s clearly impossible to be up to date with all the technological stack.

It’s not wise to pursue the impossible, that’s why this article will focus on something completely different — developing skills around work organization and good coding practices. I practised this learning approach for a few years and it works well for me.

My wife learning trad-climbing in practice. It’s worth having more gear than necessary. Only through experience, you can learn how to balance weight against security (how much gear you should take)

Learning TDD — do it 100% of the time?

Let’s start with an example. Imagine that you’d like to learn how to do Test Driven Development. Firstly, you have to prepare — probably read an article, maybe a book. After gaining the initial theoretical knowledge it’s high time to forge it into a practical use. You might decide to go one of the following ways:

  1. Do TDD only if the task is simple
  2. Do TDD from time to time only you have enough time
  3. Before starting the task decide if given task is TDD-friendly
  4. Do TDD always

I’m an advocate for option ‘Do TDD always’ for the learning phase. Only after experimenting with going to extreme (doing TDD all the time) you can decide what to do on a daily basis.

Non-scientific TDD payoff. It’s difficult to find the balance on when to use some methodology

The payoff line is not straight (as most reactions in nature are nonlinear and asymmetrical). Not using TDD at all is a valid option for many developers, others (including me) find it useful in most use cases but learnt that sometimes it does not work (e.g. when trying out a new technology). The important thing about this line is that it is very subjective and depends highly on the person and the work environment. Only through experience, you can find your own sweet spot.

Extremes: sprint length

Another example of nonlinearity in software engineering is how much value we deliver based on sprint length. If this variable was linear then we could either say that spring length does not matter or the shorter/the longer sprint the better. Clearly, that’s not the case (neither 1-hour long nor 1-year long sprint works).

Estimated value delivered based on sprint length

So if you (and your team) would like to learn how to work efficiently, then it might be a good idea to fiddle with your sprint length. You can try One Day Sprints, 1-month long sprints, evaluate and move closer to the preferred side.

Going to extremes other ideas

  1. Code review size. Bigger merge requests are not as thoroughly reviewed as smaller ones. Try capping code review size to 100 lines of code. Do you feel any difference? How about test && commit || revert?
  2. Code coverage. Start where you are, then test 100% of your (new) code. Where do you find culprits? Maybe 100% code coverage makes more sense than you initially thought?
  3. Pair Programming. Try doing it 100% time. How do you feel? Tired? Happy? Any specific tasks that are good for PP?
  4. Limit meetings length to 15 minutes. Has anything changed?
  5. If you’re using Kanban limit your WIP to 1. How it affects the throughput?

Summary

If you want to be efficient at your work you have to experiment with your habits and behaviours. When learning any methodology finding the right balance requires going to both extremes — not doing it at all and then trying an absurd (100% time TDD, One Day Sprints, daily releases [oh wait, it was extreme 5 years ago, now it’s normal, or even a bit lame]). Working this way can make you inefficient in a short-term, but definitely pays off long-term.

Have you ever tried going to an extreme when learning new skills? Do you find any other examples where this idea might be beneficial?