Never commit code with careless mistakes… again!

You know how to write clean code, but sometimes you check code into the repository with tiny little errors? Errors like forgetting null check, misspelling method names or poor documentation. This may have serval causes.


The primary cause for careless mistakes are distractions. Distractions usually results in interruptions. And the negative impact of interruptions are immense ([1]; [2]; [3]):

  • Significant recovery time
  • Kill productivity
  • Task takes longer time and contain more errors

There are a tons of things you can do that prevent interruptions ( Pomodoro/ working in coffee shops, headphones working distraction free in the late night or early morning [7]).But what can you do to minimize your recovery time if you are distracted?

  • Consider TDD – with your tests you will always have the context to get back to the point where you stopped.
  • Make a To-Do-List, whenever you have to do serval different things all at once. But try to keep the list short. Mine are usually designed for just one day with less than 5 items. And yes I write them down. During the process of note taking, you will put effort in evaluating and ordering and that will help to fix ideas/information in your brain, which just makes it easier to recall them later [8].


It is quite common to suffer from afternoon fatigue during the day. Consider taking a brief nap (5-15 min). You will almost immediately improve your cognitive performance and reduce your sleepiness for up to three hours [4]. I recommend this article which teach you how to fall asleep quickly [5].

But what if it is not possible to nap, for whatever reason? Stretch! Stretching improves blood circulation, especially after coding for hours at a desk. Stretching for a few minutes will help you to relieve stress and tension [6].

And whenever you need a little break take that break. Sometimes that’s the only thing that prevents you  from not seeing the wood for the trees.


Deadlines are stressful. On the other hand you do want to deliver an excellent result, don’t you? Maybe you think ”I will fix it quickly”. But quick doesn’t necessarily lead to a clean solution. In most cases it will make your code harder to maintain. Quick also means more error prone. Question every step you take. Whenever making changes, ask yourself why you’re coding the solution that way. This helps you to reflect better. Or even consider a rubber duck to explain your code to.



Are you on the right track?

Sometimes developers implement a task slightly differently than it was meant to be. If not sure ask. And even if you’re sure, do ask too. Or discuss your solution shortly (really shortly) before implementing it –and after you have an implementation concept in mind (!)- With your team colleagues. During your lunch break, or maybe right after your Daily (Scrum). It is a chance for you to see, if you are on the right track. And discussing your solution can even lead to better ideas.

Relying heavily on reviews?

Whenever you have a senior developer reviewing every piece of code you write, there is a greater chance of commiting bugs. Because you think unconsciously: “If there is a bug -and that is not the case- he will find it”. You just feel more secure, when commiting. Which just lead in my team to bad code from non-senior developers . And that means more work for the senior developer. He couldn’t “trust” the new code. So don’t rely on him or her. Write your code as though it will be immediatly be released for your client. Any bugs would be directly  detected. You wouldn’t want that?  And for all those seniors: Don’t review everything. Your team colleagues do have to fail sometimes in order to grow. And they triple check their code next time before commiting.

What are you committing into the repository?

Before commiting your code, check every change you have made. Do you have spelling errors? Have you written any Tests (I think TDD is a great way for ensuring quality, especially to detect NPEs– therefore check if your new code is covered by Unit and Integration-Tests)? Did you document your new code (Check for new classes/Interface and especially methods in your Interface)? Is there any uncommented code? Delete it then- you certainly don’t need it. You use maven? Then perform a clean install BEFORE the commit. And don’t forget to inspect the logic of your code (Like searching for duplicate code, bad method names and everything that indicates bad code. If you are still having problems to write clean code read for example [9]).

Learn more!

You live and learn. Read books on how to write clean code. Learn more about design patterns or read advices about how to organize yourself better. All those things will help you to write better code.



[1] Chris Parnin, Spencer Rugaber (2011): Resumption strategies for interrupted programming tasks. In: Software Quality Journal, March 2011, Volume 19, Issue 1, pp 5-34

[2] Mary Czerwinski, Eric Horvitz, Susan Wilhite (2004): A diary study of task switching and interruptions. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ’04). ACM, New York, NY, USA, 175-182.

[3] Derek Johnson (2015): Why developers hate being interrupted., 06.01.2015

[4] Nicole Lovato, Leon Lack (2010): The effects of napping on cognitive functioning. In: Progress in Brain Research, 2010 Volume 185, pp.155-166

[5] Azel (2015): How to make yourself fall asleep., 03.12.2015

[6] Heather Hitchcock(2013): Why Do You Stretch After Sleeping?

[7] Chris Parnin (2013): Programmer interrupted.

[8] Dustin Wax(2015): Why we remember what we write.

[9]Robert C. Martin (2011): The Clean Coder: A Code of Conduct for Professional Programmer


One thought on “Never commit code with careless mistakes… again!

  1. Great Post!

    I agree with every single point you make, especially “Relying heavily on reviews”.

    From a senior developer’s point of view I can emphasize: it’s a trap. A hideous one at that.
    In our team with multiple seniors we had bugs surface in production and couldn’t quite explain why. When we went back to analyse what went wrong. The reason was that I had made a change I was uncertain about, believing my colleagues would check it thorougly. My senior colleagues on the other hand assumed that if I made that change I must have been really certain it was correct. This should never happen.
    Thus “Relying heavily on reviews” applies to all experience and skill levels. Never rely on reviews! (or properly communicate a commit as a draft)

    Another aspect to this is company and team culture. You need a culture that fosters throrough and critical reviews. You need positive enforcement for every bug found. You need seniors that provide straight feedback, and juniors that are willing to learn and listen.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s