The life of a developer is not easy.
- Your code (or a bug in it) accidentally kills or maims someone
- Internet Explorer (if you are a Web developer).
- Requirement changed, again.
- GitHub merge conflict
- Accidentally typing rm -rf * in a wrong directory. THE END. :(
- Stack Overflow is down!
- Going to Stack Overflow and seeing someone’s post with the exact same question you have been trying to get answered. Posted a year ago with no answers.
- Reaching your question limit on Stack Overflow
- The bug only occurs in production and can’t be replicated or triggered locally.
- The probability of the bug occurring is low, but not low enough to ignore.
- The cause of the bug involves a race condition that only occurs under load.
- The cause of the bug is unknown.
- You didn’t write the code that caused the bug but are responsible for fixing it; the person who wrote the code no longer works for the company.
- The issue that caused the bug is in some library that is reliable 99.9% of the time and thus is the last place you would look.
- Hardware bug, but everybody assumes it’s the software.
- Many others have attempted to debug it over the years; nobody succeeded.
- The bug is a logical error that only occurs at run-time after a long period of time.
- Debugging requires expertise in a field you know nothing about.
- You have a tight deadline to fix the bug.
- The bug can’t be ignored because your job is at stake.
- Semicolon key not working
- Seeing your uncommented code a year later on an awesome working project and screaming while struggling, “How the hell did I do this?” and “Did I really write this code?” It’s like getting lost in your own house.
- A library with no documentation.
- = instead of ==
- Overconfidence. Lack of preparation. Underestimation. Furious activity instead of working.
- “My code works, I don’t know why”
- Fixing 1 error, got 927234 error more.
- Under-communication: Programmers need to understand what they are building, and how it will be used. You need to establish context. This is because while building something there are about 100 different points in which you need to make a judgment call. Having the context allows you to make the judgment call.
- Over-communication: Meetings, meetings, meetings… can be death of programmers.
- Have to wait a day for getting clarifications, if the “Client” is in another Time Zone
- No documentation or much worse, useless documentation. (e.g., stating the obvious, having nothing to do with the code, etc)
- Indentation is messy and you cannot debug your code because of the illogical structure
- The program stops responding due to a bug in a particular version of the OS you do not have access to.
- The boss tries to test the program with an old version.
- A client does something unimaginable that stops your program from working. You don’t know what the client did and your manager wants you to fix it by the next day. THE END :(