No going back ๐
Sometimes when you make a change, it ends up changing you.
The first example I remember clearly is learning Test-Driven Development. It was somewhere in the middle of the 2000s when I decided to go all-in on TDD. I tried to do everything test-driven. I spent a lot of time writing tests, some good and many bad. Overย time, I learned how to write good tests, what kind of code was easy to test, and what made testing hard. It was a great learning experience and my skills improved a lot.1
But there was one thing about the experience that surprised me. Writing production code before writing tests started to feel dirty. It felt wrong. Unprofessional. Today, it can happen that I choose to write code without tests, but when I do, I still get that uneasy feeling.
Since then, I’ve experienced other similar mental paradigm shifts.
- After more than a decade of writing Java code,
null
felt like a fact of life. Then I started experimenting with null-safe languages, and realized that you don’t have to be constantly afraid ofNullPointerException
s ruining your day. Today, I’m used to writing code in Kotlin and TypeScript. I look over the fence into Java-land (or Go) and feel surprised that people want to live in a world where every variable is a potential hand-grenade. - When I somewhat reluctantly learned Scala and functional programming, I was deeply ingrained in the classes-with-getters-and-setters mindset of traditional Java. It took some time to get used to the idea that data structures could not change. But then I started to get the hang of it. I started to appreciate the peace of mind you get from knowing that things will not change.2 Today, working with mutable data feels dirty, like itโs introducing unpredictable elements into what should be a controlled environment. I do use mutable data from time to time, but it makes me feel weird. Itย feels like things could change under my feet at any time.
These are some examples of things that changed the way I look at writing code. They all changed me (for the better) and now there is no going back.
What changes have you made, that ended up changing you?
-
In the blog archive, you can see some of my earlier blog posts on unit testing, for example: Don’t test private methods, How unit testing changes your design, or How to write robust tests. ↩︎
-
For more details on the benefits of immutable data structures, as well as other powerful programming techniques, see my Functional foundations post. ↩︎