Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

May 23rd, 2011 at 3:36 pm

Top 7 programmers bad habits

with 21 comments

1.- The all code is crap, except mine, attitude.

I have bad news for you buddy, all code is crap. No matter how much effort you put on it, there is always a majority of programmers who are going to think that your code sucks and that they could have done it 10 times better. I have already covered this topic in previous posts, you can find more information of what exactly I mean when I say that all the code is crap here and here.

How to fix it: Don’t criticise others people code, it could be yours the one in the spotlight, try to make objective and professional observations instead, but don’t judge. Be humble and try to learn from everyone around you, hopefully then your code won’t be so bad.

2.- The “I fix that in a second” catastrophe.

homer-simpson-dohTaking shortcuts is very tempting, everyone has done it. There are actually situations where they are necessary, but in overall, they are dangerous, very dangerous and should be avoided. A shortcut which goes wrong may save you a few hours, but may cause months of pain.

How to fix it: Don’t trust yourself when carrying delicate activities. Ask someone else to review what you are doing. Make sure that if you are about to take a shortcut, you make very clear to the stakeholders what the reasons and the risks are. Try to get a manager to sign off every time you are about to take a shortcut, aka “cover your ass”.

3.- The “That will only take a second” misconception.

Being Barcelona my hometown, I am very proud of the Sagrada Familia Cathedral, which is very well know for its beautiness, and also for the time is estimated it will take to complete, (in construction since 1882), but that’s probably because they didn’t ask a programmer to estimate, otherwise the estimate would probably have been somewhere around 2 weeks.

How to fix it: For starters, is important to understand that accurate estimations in software development for non trivial solutions are impossible, we can only guess. Also remember that is very likely that you will find so many things which you didn’t foresee when you start developing that is worth multiplying the estimate to cover for those, I usually go with 1.5 or 2.

4.- The ego spiral.

chicken dance

The last design meeting...

Many programmers discussions look more like rooster fights than human discussions. This usually happens in design and architectural meetings. It is actually quite easy to detect this ego spirals, you just have to substitute most of what the contenders are saying with COC! COC! COCOCOOCCC! COOC!

How to fix it: Leave your ego at home. Big egos are one of the biggest non technical issues for any programmer. Keep in mind some basic considerations when making decisions.

5.- “It wasn’t me!”

In my opinion, other bad habit from most programmers is the lack of accountability. We always have an excuse… It’s like if we were saying that under normal conditions we would never make a mistake, which honestly is quite hard to believe.

How to fix it: No need to cry, or to perform seppuku, (aka harakiri), when we make a mistake. Having a healthy attitude where we can you just say something like: “yeah, sorry, now we need to do this to fix this issue, my fault” is a very professional attitude, and it will help you to build a reputation and to be better considered by your colleagues.

6.- The demotivated genius.

Repetitive and simple tasks are not the best motivators, but they need to be done, programmers tend to get demotivated and very unproductive when they need to complete them.

How to fix it: Discipline. Unfortunately, there isn’t any other remedy I can think of.

7.- The premature programmer.

If programming was sex, there would be a lot of unsatisfied computers. You can just not go in, do things halfway through and then fall sleep. One of the concepts that I find most programmers struggling with is the concept of “Done”. Remember that done means: tested (and not only unit tested), documented, committed, merged…

How to fix it: This one is tricky, the complexity of non apparent necessary tasks to fully complete some functionality is quite high and usually requires discipline and training. Probably the two easiest ways to help a programmer understand if some code is done are peer reviews and demos.

21 Responses to 'Top 7 programmers bad habits'

Subscribe to comments with RSS or TrackBack to 'Top 7 programmers bad habits'.

  1. Very nice :) It was a good read, I think I’ve seen all mistakes you list here and also committed some of them. Nice article presented in a nice style, congratulations and thanks.

    I’ve also written an article about improving as a developer, see Being a better developer


    23 May 11 at 11:59 pm

  2. The concept of “done” is easily influenced by the concept of “deadline”.


    24 May 11 at 7:35 am

  3. the second interesting article here :) frankly speaking, i was laughing a lot having read this – i just know a few people who are described here :) the first bad habit of a programmer is the most funny in this list


    24 May 11 at 10:46 am

  4. i can totally relate with item#6 :)


    24 May 11 at 8:53 pm

  5. Love that design meeting! 😀


    24 May 11 at 9:50 pm

  6. So true! I wish you wrote this article ten years ago, it might have saved me making some of these mistakes. 😉
    My “fix it” tip: learn to detect these bad habits, it will save you a lot of trouble and energy.
    My “fix it” tip 2: if you’re working in a company where you detect many of these bad habits (especially the ego one), don’t hide….RUN, RUN, RUN!!!


    24 May 11 at 11:42 pm

  7. Great post, you hit the nail on the head with 1 and 4. Its so easy to be an egomaniac when you are a programmer. I actually wrote a blog post about ego’s and a developers career a little while back

    Ryan Anklam

    25 May 11 at 1:23 pm

  8. Great points you make here Alberto. Here my 2 cents:

    “The demotivated genius”
    How to fix it:
    – Use a framework that makes these repetitive tasks simple. E.g. a validation-framework makes it easy to define validation-rules for web-forms
    – Use libraries that contain the desired functionality (this bites with bad habit number 1.- “The all code is crap, except mine, attitude.”)


    25 May 11 at 1:55 pm

  9. Good post …

    “The demotivated genius” not just on the repeated tasks but there are few more things too for this..

    Only Discipline will work…

    Senthil Kumar B

    26 May 11 at 1:36 am

  10. Nice post!! All the points seems very familiar, something that we come across frequently but don’t realize that it is “not the right way”.


    26 May 11 at 7:25 am

  11. Um…I’ve watched developers eat, and seen what they eat. All code is crap. *laugh*

    Wes Morgan

    26 May 11 at 8:16 am

  12. ¡Más razón que un santo!
    En 30 años de profesión los he visto todos en acción, y he caído en alguno más de una vez.
    Quizás añadiría algo acerca del compañerismo o de la ayuda mutua inexistente en la mayoría de equipos, o al menos es lo que he vivido, por desgracia.


    26 May 11 at 10:54 am

  13. […] Fuente: MakingGoodSoftware […]

  14. […] Top 7 programmers bad habits […]

  15. […] Top 7 programmers bad habits – Alberto Gutierrez goes at it again with developers.  Mind you, he’s not just about pointing out faults, check some of these posts “The four golder rules to be a better software developer” and “My ten development principles” […]

  16. […] Top 7 programmers bad habits […]

  17. Nice. Fix for number 6 is surely to write some code to automate the task, preferably in a really cool new programming language, using several new frameworks. Takes a lot longer of course, but much more rewarding.

    Mark Heath

    27 Jun 11 at 5:28 am

  18. […] Top 7 programmers bad habits […]

  19. […] 本文是从 Top 7 programmers bad habits 这篇文章翻译而来。 […]

  20. […] 原文:Alberto Gutierrez 译文:外刊IT评论 […]

Leave a Reply