10 Worst Nightmares For Web Developers

Many people around me think my job as a web developer is easy. Usually they see me pummel the keyboard from home, with a nice hot cup of coffee or tea next to me. What they don’t see is what goes on in the machine in front of me.

Almost every developer will face the same problems I face: the worse case scenarios, the nightmare-inducing horrors; the sometimes unfortunate; sometimes "someone must be pulling a horrible prank on me" feelings – at times jumping off a bridge seems like the easier thing to do. If you are a seasoned web developer who has worked with many clients and projects, you may have come across some of these situations.

For those of you who are thinking of becoming a web or app developer, these are some of the situations you may eventually find yourself in. Be prepared to face them, and don’t say you were never warned. These are the 10 worst nightmares developers have to face.

1. Fixing Other Developers Perplexing Codes (and Bugs)

If you have just joined a new company, you will most probably find yourself in the position of cleaning up a project left behind by the developer you just replaced. Chances are the code is lengthy, real complex, unreadable, critically ridden with bugs… and already live online. Of course, you could be the lucky 5% who don’t have to fix another developer’s code, but frankly code-fixing happens more often than not.

The problem arises because developers, like writers, have their own style of coding. This is where documentation becomes a godsend – if you have always hated doing the documentation (don’t we all?) then know that this is essential for the sanity of anyone who has to touch your code.

Without proper documentation, the new developer has to scan through lines of code to figure out your (or the original developer’s) thought process. It’s times like this that we wish telepathy actually exists.

2. Bugs Appear at The Worst Possible Moment

After months of hard work and tons of caffeine, you finally released your app to the masses or present it to your client. You are very excited and can see the light at the end of the tunnel, after months of dragging through the same project night after night.

Then, it hits. A critical bug occurs during the demo, or elicits complaints from hundreds of new users. Your perfect view of your perfect project comes crashing down. But hit "pause" for a moment.

First of all, know that this could happen to anyone – even to brilliant developers of major products like Facebook and Twitter. For those who have been there, you know how frustrating this situation can be; the bad reviews just keep coming in, or the clients look at you like you have committed the ultimate crime or soiled the family name.

You know what you can do? Keep calm. Fix the bugs ASAP and just keep a straight face. Don’t let this drag you down for too long… unless the fix causes other bugs to appear!

3. Fixed a Bug; cause New Ones

Bug fixing is a necessary evil. Torturous, unproductive and just a heart-problem inducing activity that makes you question why you want to be a developer in the first place. Every developer has been there. After hours of tapping on your keyboard, you finally fix the original bug only to find that you have created additional ones!

It could be that you have updated a library because it was not compatible with another library you were using, only to find that the new library conflicted with your code. Meanwhile the deadline looms on, the calls to check up on you keep coming in, and the number of errors just keep piling up.

Stop tugging at your hair and try to plan ahead for this. To prevent a similar situation from happening with future projects, use Git to manage your revisions as it allows you to revert to previous revisions if the new one doesn’t work properly.

Also, remember to document each revision carefully. It may seem like a neve-wrecking task but when push comes to shove, you will thank your past self for hanging on and actually doing the documentation.

4. The Bug Resides In the Library You Rely On

You know what is an even worse nightmare? When the bug you found in your code doesn’t actually exist in your code but in one of the libraries you used. We often rely on multiple libraries to build websites, and developers may use the same library for multiple projects, without a hitch.

In this particular scenario, however, a bug occurs, you check on it, and you find that the bug happens to come from one of the libraries you use. What do you do? It’s a dilemma, isn’t it? Let’s consider the options.

  • You may want to fix the library on your own, in which case you should ask yourself how proficient are you with the codes within the library to actually do that?
  • Can’t fix it? Then, should you file for a request for the developer to fix it? That’s going to take some time, which they aren’t obligated to rush out since you are the one with the deadline, not them.
  • What about replacing that library with another one? That would get the bug out of the system. But then you will need to rewrite chunks of your code just to make things work.

Look, I said they were options, I never said that any of them is easy. Just pray to the programming gods that you never have to be subjected to this situation, or to the next one either.

5. The Bug Cause is "Unknown"

No, this can’t be! You have been searching for days for the bug, creating multiple Git branches for testing, but the bug remains elusive. You go to StackOverflow for a reprieve, only to find a question with the same problem posted 2 years ago with zero answers.

It may not be a critical error, yet it tugs on you like an itch that you can’t reach or get rid of. Your head starts to spin, you keep telling yourself that if you spend one more hour searching, you will find that damn bug.

Stop. The solution to this problem is actually the direct opposite. You should stay away from your computer for half a day, or longer (going for 2 days is best). You are suffering from mental fatigue that prevents you from "seeing" or "finding" the actual problem. Taking a break will help get you up to 100% again.

And if my experience can be a source of reference, sometimes the bug rectifies itself and ceases to be a problem, without your interference. It just happens, and when you are exhausted, you really don’t care to find out why.

6. Data Lost, No Backup

Holey moley, this is a nightmare even non-developers can relate to. You suffer from complete data loss and you curse yourself for not spending the time to backup your files. If this happens to you, you definitely have yourself to blame.

Even when working with very stable systems, your hard disk may suddenly act up, your kids may press the Delete button, or you accidentally spill coffee on your laptop. Rather than cry over spilled coffee, revert to your backup copy, and keep your high blood pressure down. This is not a lesson you want to learn the hard way.

Personally I don’t have only one or two sources for backing up important files – I have three: Time Machine, Dropbox, and OneDrive. OS X users should enable Time Machine. For Windows users, enable the Backup and Restore feature from the Control Panel.

7. Making it Work in Internet Explorer 6

For some reason, there is still a need to make modern apps work on Internet Explorer 6 because some clients and their customers still insist on using Internet Explorer 6. If you are one of these people, let me make it clear to you how time-consuming and distressing coding for IE 6 is.

The time developers spend to make a web app work in IE 6 could be three or more times longer than to build the app for modern browsers like Chrome or Firefox. The frustrating part is that it will not run as smoothly or as impressive on IE 6 as it will on the new browsers. Some of the effects won’t take effect, some of the bugs will keep bugging you and don’t get me started on security issues.

You are making life hard for developers because you or your system refuse to use a newer browser. And if I have any advice to share with fellow developers, it is that you should charge double or more for those who ask for a modern day web app to still be able to run on IE 6. And it still would not be worth the trouble.

8. The Semicolon Key is Not Working

Several programming languages JavaScript and PHP need the semicolon to mark the end of a statement. It is like the period or full stop that ends a sentence.

Many errors happen because of the missing semicolon, and you definitely cannot have your semicolon key on your keyboard stop working. Consider having a spare keyboard that you can plug in to use in case of emergencies like this.

9. Internet and Google is Down

If Google is important to you in your work or study, know that it is doubly important for developers. As web developers, we use Google to search for code samples, find solution for bugs, collaborate with peers, and more.

If the Internet and Google goes down, we would have to go back to an earlier, isolated "period of darkness". We will be stuck, not knowing what to do if we encounter particular bug. For the most part, Google always saves us. So, hats off to the developers or programmers who were doing this before the age of the Internet – I bow to thee.

10. You are the expert (You can do anything)

To conclude this list of nightmares developers have to face, I leave you with this Youtube video called The Expert by Lauris Beinerts. You will find out how painful it is to become the Expert.

Further Reading

For an inside look into other types of freelancing or online jobs, you might be interested in:


Leave a Comment