Which 3 Coding Habits Have You Come to Love?

As more grey hairs start to appear on my head, more contentious opinions on the art of programming start to develop inside it. And I’ve noticed three of those opinions that just keep getting stronger. Either I’m completely wrong (did happen once), or you should be taking more notice of these good habits, too.



And please tell me, which 3 beliefs have you come to hold so dearly that you wish everyone else did, too?

I love my type system like a big, cuddly teddy bear

Loving The Type System

Over the years, I’ve come to realise that type system is like a big cuddly teddy bear who wants me to feel warm, comfortable and loved. If I can express all my intentions as types and interactions between types, I’m going to get lots of big warm hugs from the compiler.

What I don’t love anymore, though, are things that try to outsmart the type system. “Ooh, there’s this clever little library that uses reflection to save me a few keystrokes”. “I just deleted a class and nothing happened… until the application blew up at runtime”. “I just moved a class from one module to another and nothing happened… until the application blew up at runtime”.

There’s an argument that testing your code can catch these problems. There’s also a counter argument that having to write tests to compensate for something that bypasses your type system…

I do still love tests. And I’m absolutely still in love with that TDD stuff. But too many tests in my life all wanting my attention is just too much for one programmer to handle.

Loving Immutability

For a long time, I was deeply in love with the ideals that get bundled up with object oriented programming — behaviour-rich classes that hide their state. I do still hang out with those ideals from time-to-time, but it’s not an exclusive arrangement anymore.

For the past three years, my relationship with immutability has grown strong. Exposing data, but not letting others change it, *feels* like the single biggest improvement I have made in my coding habits.

When I look at a piece of code that is almost entirely immutable, I feel a warm comfort. I feel like I don’t have to go hunting through the code to see where something gets changed, because… it doesn’t change. And no nasty surprises where I was naive to assume something wouldn’t change.

A lot of the time, separating the behaviour and the data actually *feels* much cleaner.

I’m not saying never use mutability, but I would say if you’re in the mutability comfort zone, get out of it for a while. It will be fun.

In the Scala community, where there is always a choice between mutability and immutability, immutability is unanimously the default choice. Now, I don’t love everything about Scala, but the strong consensus on immutability and a language which provides strong support for immutability are definitely things I do love. I’ve noticed this is a philosophy that is spreading into other programming languages and communities, too.

If you’ve not really explored the world of functional programming yet, you really should make a start. I’m not saying everything is great, but there are lots of ideas to challenge your view of the world.

Loving The Vertical Slices

It seems natural to group things by type: controllers, repositories, services. The majority of codebases I’ve worked with actually do this, but there are repeating problems I’ve seen in each instance.

In the most extreme case, you have a large monolithic system that needs to be broken down into smaller chunks. But you can’t do that easily because everything in each layer is so tightly coupled together.

For the past few years, I’ve been strongly leaning towards creating modules that align with specific use cases or business capabilities — things that change together for business reasons. Things that would enable one autonomous team to own that piece of work.

The number one biggest problem I’ve seen all throughout my career in software development is the pain of not being able to get on with writing code and creating value. Having to coordinate with other teams about evolving shared code or infrastructure, for example.

I’m a huge believer in the loosely-coupled, highly-aligned mantra Netflix have been talking about for years. Starting to think in vertical slices and organise your code that way is one of the fundamental building blocks to support this approach; especially before you start to distribute your system.

So, Which 3 Coding Habits Have You Come To Love?

I’d love to know what 3 habits other developers have come to love.

Over the past 1–3 years, which things have changed your outlook on programming? What do you do now that you didn’t do before? What beliefs did you have 2 years ago that you look back on with slight discomfort or even disgust?

Hopefully not any of the things I’ve mentioned here! But please tell me how wrong I am if that is the case.