10 Worst Nightmares For Web Developers
Written By Thoriq Firdaus / Courtesy of Honkiat.com
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.
Continue reading the entire article over at Hongkiat.com.
