Title says it all.
Mine are:
- reading someone else's crappy formatted code and trying to make sense of it
- testing some small change buried deep inside the software so that I have to think very hard on how to create a UI use case where my code change is executed
- realizing, when you actually wanted to commit some changes to the repo, that you have to merge a whole bunch of other people's changes in first (and test them... and debug them...)
- after programming a week and finally finishing a "desperately needed" feature that required a partial redesign of the data model, your project leader tells you that said feature has been dropped after all
- thinking about ways of how to tell your colleagues it might be good to think about the impact of code changes in other places than just the file they are currently working an (and realizing it would be useless to tell them...) ;)
- trying to make sense of the changes someone else made to a file I once wrote and finally realizing that what he/she was trying to accomplish would have taken him 1 line instead of 20 (scattered all over the place) while still avoiding new bugs
- reading code with (obviously) misspelled variable names
- reading code that performs a very simple thing using a lot (a lot) of lines of (badly formatted) code
I am sure there are more...
- Establish coding style guidelines. There should NOT be only one way, but all the different formats should be compatible in terms of feeling comfortable to read them. Also, weed out senior candidates who paid no attention to coding styles during interview.
- Establish modular codebase as much as you can.
- It happens in a big team. Modular codebase would help.
- This happens quite often in start-ups. It is part of the business and I think we must accept it.
- Hiring good engineers. Most engineers will learn, especially from their own mistakes. I admit that some people will never get it.
- Same as the last one. You can always improve it if it doesn't require much of your time.
- Refactor them.
- Try to talk to the engineer who performed the task. Most inexperienced engineers would appreciate your showing them a better way to do it. For those who don't, you can do nothing about it, except talking to the manager if it comes to the point that almost all of his/her code have to be rewritten.