Stop coding by coincidence, start coding mindfully

Stop coding by coincidence, start coding mindfully

Dave Thomas and Andy Hunt coined a phrase I love in their book the Pragmatic Programmer. They refer to a process of “programming by coincidence”. They contrast this with “programming deliberately”. We can capture this idea with a more relevant phrase and repurpose it a bit as “mindful coding”. The names pretty accurately describe these ideas, but let’s dive a little deeper.

Programming by Coincidence

We’ve all been there. You write some code, it doesn’t work. “What’s happening, I was sure it would work”, you thought. “It’s late, let’s just flip the greater than sign to a less than sign in this expression… Holy shit it worked! Done!”

We all code like this from time to time, you might have even been guilty of this exact thing. I know I have been. But guess what, we both know this code is going to be hard to maintain. If by some miracle it is easy to maintain, it is pure coincidence.

So how did this happen? Developers work on a ton of different things. Our attention is pulled in a myriad of directions. Unfortunately, this causes things like this. You may not even remember writing a piece of code, you were so distracted while writing. How could you possibly guarantee its “correctness”.

This is something TDD was trying to solve. Break a problem into such small steps you can’t possibly mess it up. Even if you didn’t apply your full attention, you’ve made a guarantee that the code will do certain actions and things would be ok. You passed the unit tests before you could move on.

But TDD isn’t enough. This clearly doesn’t guarantee that your tests are even worthwhile. So what is the alternative?

Mindful Coding

This is where mindful coding comes in. Writing code deliberately that solves the problem you’re trying to solve.

This is clear when trying to debug why your code doesn’t work. Take a step back, think about what you’re trying to solve. Rather than just flipping that greater than sign, think about what criteria you’re trying to meet. What are you invariants?

Breaking the problem down helps a lot here too. Chunk it out, solve the smaller bits first. How do the pieces fit together? Don’t just mash them together, then we’re right back into our mindless coding.

I introduce the concept of mindful coding very deliberately. For me, it draws an obvious parallel to the mindfulness movement. If you aren’t aware of it, read up.

Mindfulness is about being present in the moment. Being aware of what you’re doing. You’re walking somewhere, but to do that, your legs are moving. You can feel the ground in your feet when you take a step, that kind of thing.

Let’s apply that same idea to coding. You’re writing your if statement. Why are you writing it? Oh yeah, we need to make a choice here. What are our two choices. Let’s wrap the choice in a function to make it more clear to the next reader.

See where I’m going with this? Mindful coding leads to code that someone else might be able to read because we’re constantly being attentive to what we’re putting on the screen.

How to code more mindfully

So how can we write code while being more mindful about what we’re writing? There are many techniques we can use to pull this off.

Understand the code you are modifying. This might sound self explanatory, but let me dive in further. Kent Beck discusses exploratory testing in his book TDD. This is exactly the type of thing we need to be doing to understand the code we’re working on better. Furthermore, code that doesn’t have unit tests could benefit from them, and so will your understanding in writing them. Write tests that explore how the code functions, why it functions that way, and where it functions unexpectedly.

Slow down. So many of us are in a race to finish what we’re doing. Of course we are, we’re all fighting tight deadlines, and its hard to predict the future. But the reality is that 9 times out of 10, slowing down will speed you up in the future. Slowing down, being aware of what you are writing, will pay off in spades when you come back to this same code tomorrow.

Have a plan. Do you know what the plan is going to be before you put code to screen? Take a look at this video, where google shows you how to do one of its interviews. Pay attention to how the interviewee describes his plan before writing it out. They look for this because it allows a developer to think through their intentions before writing out what they’re doing blindly.

Building on that… know your assumptions. If you have a plan, you must have built that plan on something. You might have already detailed these in unit tests, and I think this is one of the great insights that Beck was trying to get to with TDD. You’re literally testing your own assumptions in your unit tests, so think through them.

There are many other ways to remain mindful while coding, these are just a few from my own perspective.

We could all code a bit more mindfully

I’ll be the first to admit, I’m not always great at this. I sure try to be, but there are times I find myself lost in my own code. But that moment that you come to, you recognize your own ignorance, is a critical moment. Take note of those moments, they are the most important. It is mindfulness at work, and the key to a new feedback loop to help yourself be just a bit more mindful next time.

3 Comments

I totally agree. I’ve always been bugged by that little moment when flipping the comparison made everything work and I wasn’t sure why. While I struggle to practice it, I always found that TDD made me mindful not only of the code I was writing, but what I might be doing with it in the future.

Are there any authors or bloggers you recommend for learning more about the mindfulness movement which you refer to?

One final thing to mention is a word of caution. The movement is gaining popularity to the point where there are many different takes on it. Some are more practical, some are more spiritual. It is easy to rathole down a bad path with the topic, so I recommend doing a bit of research and mostly sticking to books when diving into it.