Fix Your Bugs, Hack Your Life

On the 23rd June 2016, I was absolutely flattered to be involved in Code Slinger. It was an excellent conference and an absolute pleasure to be a part of.

Here's a transcript of the article that inspired my talk - enjoy!

Fold Your Arms

Before I get started with the presentation I’d first like to try a little experiment.
Could you all please fold your arms in a way that comes most naturally. Now try folding them the other way. It feels strange right?!

You might say uncomfortable. That’s your sub-conscious telling you that the way you just folded your arms is out of your comfort zone and not the norm.

Autopilot ON

If fact we do things everyday because of this instinct. We often find ourselves entering auto-pilot when we’re driving a familiar route, suddenly realising we're on our way to an old house or previous place of work, when we open the fridge, or brush our teeth using the same hand - we all use similar motions. Even to how we write code!

I'm pretty passionate about productivity hacks and human psychology so this topic really interests me - and my aim is that a few of you go away and try a few different things to make some changes to your own habits or at least start thinking about how you can change them.

Old Habits / New Habits

So what does this have to do with being a software engineer, project manager, engineering lead, designer or UX developer?

Our own bad habits are the one of the main things holding us back from becoming better people and accomplishing greater things. Software projects don't write themselves. It's in combination with our specialist knowledge and our own habits that we produce great software projects. So by improving your habits, you can improve the standard of code.

When we think about habits with developers, you even have a particular style of code that you write, you handle particular problems in a certain way because that’s what your habits have taught you to do. You commit code at certain times because your habits have partially dictated when you feel most comfortable committing code. Our habits control our actions more than we know.

I'm not a great developer

There's a really great quote by Kent Beck that talks about the values of habit and specifically in relation to Test-Driven Development that, to me anyway, really sums up the benefits of learning to create habits:

"I'm not a great developer, I'm just a good developer with great habits" - Kent Beck

Break a Habit

There’s a common misconception though, that habits are hard to break. Habits are not as hard to break as they appear. People just don't know or don't think about the strategies that are required to help break those habits.

Before we can break or replace a habit with a better one, we need to understand why it happens and what triggers it. What makes you follow a habit and how is it we can sub-consciously follow them without even being aware.

How does your code make you feel?

Now let's imagine this really really bad piece of code. Poorly named variables, repitition with multiple return statements. How does this code make you “feel“ on initial inspection.

Anger? Disgust? Horror?

Sure this is a huge exaggeration, most of us will never write code like this let alone see it. However, we probably do write code that sometimes falls well short of our own standards.

This is what I would want to happen

The Cue

How you 'felt' about that code is called this the cue.

We can think of a cue is 'a trigger that tells your brain to go into automatic mode and which habit to use'.

Now the cue is very important, because it gives you an idea of when that bad habit might creep in. If we're constantly mindful of that cue we can switch the behaviour or stop ourselves when the bad habit is in mid-flow.

Let's say you've just turned your Macbook on, you're ready to work and your phone buzzes. You decide to check it out, after all it could be something pretty urgent right? Before you know it, you've also clicked through to Facebook and you're now watching a video of a cat slapping another cat down some stairs.

Funny right?

The Routine

The click, following that link to the next thing this is the routine.

In this case a bad routine. This routine is 'the behaviour you want to change'

If we take this back to the bad code example our routine is to clean up that godawful vile mess of code. Maybe you start by renaming a few methods, putting some of the repetitive code inside a single abstract private method with the end product being that, not only can you read the code but you can also make the changes you wanted to make in the first place that little bit easier.


I don't know about you but once I've finished cleaning up that bit of code I get a feeling of gratification and satisfaction of a job well done.

This is my reward

In the words of Uncle Bob, you left the campground a little bit cleaner than when you last found it. There's an added bonus that you'll have less pain in the long run. The technical debt has been paid off early.

Feedback Loop

These three things. Cue - Routine - Reward are what make up the structure of almost every habit imaginable. So if you can figure out what that cue is you can change the routine. However, if you want to change a habit effectively you must remember to do these three things.

  • Keep the Cue
  • Change the routine
  • Change the reward

Pavlov's Dog

You've all probably heard of a Russian Physiologist called Ivan Pavlov. During the 1890s Pavlov showed that even some "hired-wired" responses, such as his dogs salivating at the sight of food, could be "trained".

Pavlov found that he could train his dogs to salivate at the command of a bell through the use of conditioning. At first, he would bring the food and the ring the bell at the same time thereby associating the bell as a cue to food being given.

He would then gradually phase out the food until only the bell was left.

To his astonishment the dogs were still salivating when he rang the bell without any food being present at all. If we can teach dogs to salivate on command, we can learn to change our own habits.

Maintaining a Habit

This brings me on to the next and probably most mysterious piece of the puzzle.

How to maintain a habit.

Now, there are two well known ways in which habits are kept.

There's option number #1 which the vast majority of people follow. I have no idea what proportion of people do it, or at least attempt to do it this way, but it's visible pretty much anywhere you look.

They'll make bold statements about reinventing themselves.

I'm going on a diet - for a few weeks then they cave when the office doughnuts appear.

I'm joining a gym starting on 1st Jan. Gym's live for this behaviour. They rub their hands gleefully when yet another sucker walks into their gym on the 1st still suffering from a post-hangover with alcohol literally seeping out of their skin like water from a sponge. They have no chance - and gym's know it.

Re-inventing yourself - in general doesn't work for most people. So my advice would be forget it.

We can do ONE better!

The Kaizen Technique

And this is where Option no #2 comes in The Kaizen Technique.

Kaizen, whilst a Japanese word, was actually invented by the Americans during World War II. Many of the american manufacturers during the war needed to mobilise and become more effective at producing wartime goods. So, what they did was they reached out to employees who submitted small suggestions such as selling on scrap metal at the end of a manufacturing process rather than disgarding it.

Kaizen was eventually adopted by the Japanese after having been brought over by the Americans as a way of kickstarting the Japanese economy. This was all part of America's

Journey of a Thousand Miles

Those of you who'd not heard of Kaizen I'm absolutely sure you've heard of this infamous quote:

“A Journey of a thousand miles must begin with the first step“ - Lao Tzu

This, is essentially what Kaizen is all about - small changes creating continuous improvement. Which if you think about it is also the essence of the Agile methodology. Delivering value through software in small increments.

Man with Three Brains

The thing is why would small changes have a greater chance of introducing a new habit than trying to make more radical changes?

To understand this we need to look at human biology. Fear of change is rooted as part of the human psyche or more specifically our brain. Our brain is actually split into three distinct parts.

The brain stem - which is responsible for our basic intuitions. From breathing to ensuring your heart keeps beating to waking you up and making sure you go to sleep.

Right at the top we have our cerebral cortex. That part of the brain is what makes us the creative human civilisation we are today. It forms the majority of our brain. It's also the most recently evolved part.

The brain just below it, is the mid-level brain, also known as the amygdala (A-MIG-Du-luh); responsible for our natural flight or fight response. It's formed over hundreds of millions of years it keeps us alive when we're threatened with dangers.

Our brain, whilst evolved, does not always operate in a smooth way. Sometimes our amygdala gets in the way, we experience writers block or blocks in our creative thinking. It's designed to shut down the creative and rational thinking that could interfere with our physical fight-or-flight tendencies.

And this VERY reason is why the Kaizen technique works. By reducing the size of change, we reduce the resistance to it. Once the change we want to make is small enough, there's no way we can say no.

Fixing the 5 Habits of Dysfunctional Developers

To demonstrate how we can apply the Kaizen Technique to real life issues I've come up with 5 habits of dysfunctional developers and for each I'll suggest a small step or two you can make to illustrate how The Kaizen Technique in action.

#1 Over-promising on Deadlines

First off... Over-promising on deadlines

How many of you have said the following words "I'm nearly done. It's pretty straightforward I just need to do this one last thing." Then it turns up a couple of days later than you'd hoped.

I'm also totally guilty of this one. I use words and phrases that give the impression that the final touches are going into a piece of work and that it'll be done that afternoon. The reality though, is it will probably take a few days when we've taken into account unexpected blockers or meetings that are scheduled.

No one's perfect. We've all done this.

So, how do we make it right?

Instead of answering the question right away, we could start by saying we'll get back to them on an estimate to give us more time to consider the answer to the question. After we've considered more carefully the work that may remain and the time we have left we'll be a lot closer to the kind of estimate we would expect. Don't rush into being committed for an answer right there on the spot if the estimate is difficult to work out.

#2 Large commits

This brings us to our second bad habit, making our commits too large.

Now, let's imagine that we've been asked to implement a feature in an existing project.

We start by adding the tests and the required production code to the application, but then we realise that the pieces just won't fit right. Some changes are needed to make the design fit in a way that we're comfortable and happy with as an end product.

So, what we do is we go about refactoring the few things we need as we go along.

The thing is, along the way we realise also that there's yet further work we need to do.

We're in the flow - and we certainly wouldn't want to break the flow - OH NO! We make those other changes, rename a few things and refactor a few classes before we're finally happy with what we've done.

Before we know it, our once simple feature request, has ballooned into a pretty large refactor and we now have a pull request that looks pretty simple to you but looks like a three-headed hydra with saliva dripping from it's jaws to any unsuspecting Pull Request reviewer. Not good.

To break this behaviour can be hard, especially when you lack experience. What you can do is look at the work you need to do before you do it and think hard about how you can break the commits down.

If at any point you feel uncomfortable trying to break your commits down.... DON'T YET.

Instead after you've finished your pull request, reflect on it. Write down how you could have broken it down. After you've done this a few times you should start to gain a sense of how and under what circumstances your commits can be broken down.

#3 Ignoring Coding Standards

There's always at least one developer in the team that either forgets to conform to coding standards or is so stuck in their own habits that they just carry on regardless because doing anything else makes them feel uncomfortable.

They prefer their own style, it's a comfort blanket of a blissful code utopia.

The big problem comes when others shy away from confronting them on it because they don't want to rock the boat. This sort of attitude makes it really difficult for people to speak up and for change to happen. Sure, you can add linting but you're not solving the underlying problem, you're just papering over the cracks and masking bad attitudes formed through habit.

Coding standards should be composed in agreement with the rest of the team irrespective of whether they're right or wrong. Maybe you all agree to use a particular tool to ensure code standards are committed to. Consistency is better than being correct.

Changing the behaviour of others is considerably harder than changing your own behaviour. However, with Kaizen we can still make progress.

Why not try correcting one particular standard? It could be brackets or braces; forget the rest, for now. When they get into the habit of writing braces the way you do, you'll probably find they are more and more accepting when it comes to other changes.

Remember a journey of a thousand miles begins with a single step.

#4 Ability to Challenge Leadership

It is natural that when you're new to a business to not wish to immediately force your opinions onto others, you want to become part of the team and you don't feel like you're in a place yet to criticise. This is completely understandable.

However, once you feel comfortable you should feel compelled to speak up when you strongly believe in something.

We as humans don't want to offend people. We want to be liked. To be accepted as part of the pack. This though, is a habit that can be unlearned as well as learned.

By making small steps each and every day we can change our long-term habits and behaviour.

If it feels too much to confront your boss or technical lead over an issue, you can try smaller steps. Try first writing down what you intended to say, if it feels too much of a leap to actually say it.

Once you've become more comfortable perhaps discuss it in confidence with your wife/husband or family member.

Then once you're confident enough with that step, talk with your fellow colleagues and perhaps all agree to raise your concerns in a retrospective if appropriate, if you're not happy to confront them in person about it.

#5 Ignoring Non-Functional Requirements

In our day-to-day roles as developers we always have to be thinking about our end goal when writing a website, mobile app or service. To provide excellent experiences for our customers.

Our problem is that we tend to be spending most of our time with our heads stuck in the code so it can be difficult for us to pull ourselves up and start surveying from above street level.

I will admit this is certainly a problem I've experienced now and again. You can often allow the details to obscure the end goal. With experience we get better at this.

When I used to play chess as a youngster it was said that I

"couldn't see the wood for the trees"

Often this used to result in blundering and there were telltale signs that would indicate this problem. This was indeed a habit.

So as developers how can we avoid getting our head stuck in the details?

What we can do is, start by writing down what our end goal is for a feature. What does the customer want?

Write it down somewhere near your monitor or keyboard as a constant visible reminder of where you need to head while you're writing the code. That way it'll act as a constant reminder for you to think about why you're doing what you're doing.


What we've spoken about is how, through the application of small changes we can, whatever our profession, project manager, software engineer, QA engineer or designer, make any changes we need to.

While old habits form in the brain over time through repetition of old habits, they can be changed through swapping a routine using the same cue's and a different pay-off.

One of the key strategies for achieving this change of routine, with least resistance to it, is to apply the Kaizen Technique. Making the the slightest alteration to our behaviour. A change so small we just can't say no.

Through small changes to our behaviour, like a stone rolling downhill gathering moss we can forever change our hard-wired bad habits through constantly forming new ones.

I hope at least a few of you have some takeaways from today that you can apply to your own lives - thanks for listening.

James Murphy

Java dev by day, entrepreneur by night. James has 10+ years experience working with some of the largest UK businesses ranging from the BBC, to The Hut Group finally finding a home at Rentalcars.

Manchester, UK
comments powered by Disqus