Developing applications is a very stressful job. No one is perfect, so bugs in code are fairly common in the industry. Faced with bugs, some programmers get angry, frustrated, upset, or even frustrated, while others remain calm and composed. Therefore, how to handle the process of fixing bugs is also worth thinking about.
I want to share some thoughts about what programmers go through when fixing their source code. It’s the lighthearted humor that comes when things get tense. Generally speaking, the application will eventually work, and then you can move on to the next great task.
I’m sure many Web developers and software engineers have experienced these hardships and laughed them off in hindsight.
1. “I don’t know whether to delete it or rewrite it”
Looking back at old source code, there is a temptation to rework it into larger clusters. Ugly logical statements and long syntax make the code very hard to read! But then again, if the code isn’t broken, don’t fix it. This kind of messy struggle is something I face on a regular basis, and it clearly bothers many software developers.
2. “I should check Github for the starter framework”
I think most developers know about Github, where a surprising number of open source projects are released every day. Programmers in any language can use the Internet to borrow from existing projects, join wiki discussions, or create their own code repository. It’s a great resource for plugins and templates for all kinds of projects.
3. “Why does this script need so many libraries?”
Especially for more popular languages such as Java and Objective-C, the number of libraries can become ferocious. When building a framework that requires a lot of foundation, the number of libraries required becomes much more obvious. Even some plug-ins for JavaScript require countless additional files. Sometimes, this can feel annoying — but at least it’s useful!
4. “There must be a solution somewhere on the Internet.”
My first reaction to a tough problem is to look it up on the Internet. Programmers post their problems to the forum via a post, and the problem is eventually resolved and archived. Google is a great way to point you in the right direction. Unfortunately, sometimes it’s just too much information without a particular problem at hand.
5. “Is there a plug-in for this?”
Why reinvent the wheel? Plug-ins are a great resource for expanding the user interface of any program or website. In addition, they provide some customization and unique options for developers. Why not build your own plug-in if you don’t have one?
6. “The website works, but I’m afraid of Internet Explorer.”
The history of rendering web pages in Internet Explorer is full of trials that we have seen or experienced firsthand. Upgrading from version 5.5 to IE9 to IE10 always requires the support of more advanced browsers. Web developers can be afraid to debug web pages because opening pages in IE6 is a rendering nightmare. Thankfully, those days are fading away.
7. “That doesn’t seem logical to a logical expression.”
There are logical expressions for if/else loops, for loops, while loops, do loops, and so on. As I looked through the sample code, I tried to figure out how my logic worked. There are so many NOT operators and comparison tags. I often go back and update my own logic to better suit future practices.
8. “I spend 30 minutes writing the function and 2 hours making it work.”
Doesn’t that sound like our own programming story? You’re happily building something, but all of a sudden, the function outputs a fatal error. So now you have to go back and delete some code blocks to find the line number where the error occurred. When you finally find the culprit and fix it, it’s exhausting but also comforting.
9. “After reading multiple blog posts, I realized THAT I had been wrong all along.”
I often start by diving in with my programming ideas, but this can lead to trouble if things don’t go as planned. There have been many times when I started a project, got stuck, and then had to seek support from blogs and other papers. Then I found out that my whole approach was actually wrong, and that it was easier to start over! It would save me time in the long run if I did some research at the beginning.
10. “Nice people on Stack Overflow might be willing to help me.”
I can’t tell you how many times I’ve solved a problem with Stack Overflow. The community is full of nice and smart people who are more than willing to help if you make the first move. Of all the online forums, Stack Overflow is definitely the most widely supported network for software programming and front-end/back-end Web development.
11. “It took a lot of effort to figure out the cause of the problem was the missing close parenthesis.”
Debugging is a step you have to take. Two steps forward, one step back. It’s nice to stare at code for hours, thinking there’s something wrong with a function name or variable scope, only to discover that a parenthesis is missing. All that time was wasted because of a small grammatical error.
12. “Take a coffee break!”
Sometimes, you just need to stand up and step away from the monitor. Hovering your mouse over your keyboard for hours can help break the mold. Most health guidelines recommend taking short breaks every 30-60 minutes. But it all depends on your needs, and if you find it more frustrating to take a break in the middle of a program, don’t interrupt.
13. “I should put this project on the back burner and deal with it later.”
Another option for a break is to step away from your project, not just your computer. If something else needs to be done, do something else. This is a much better allocation of time and resources than having spent 5 hours trying to solve the problem and still not getting started.
14. “I doubt classical music will inspire my programming skills.”
One theory is that classical music can promote plant growth in the early stages of life. I personally enjoy listening to classical music while writing complex notes. Jazz, piano, big band, elegant music has a place in human cultures all over the world. So does listening to intelligent music while programming really make you debug smarter? Probably not, but hopefully it won’t make you any dumber.
15. “Over a few drinks, maybe now is a good time to test ballmer’s peak theory.”
Many readers have heard of Ballmer’s peak theory, based on a special XKCD comic. Put simply, the theory states that a programmer’s coding ability reaches a peak after a certain amount of alcohol is consumed. The author’s name is Steve Ballmer, and he acts like a drunk, which is ironic because Ballmer was never really a programmer at Microsoft. Maybe we need to wait for someone else to test the theory.
16. “Did someone touch my source code?”
It sounds delusional and paranoid, but sometimes you can’t help but wonder if someone wrote this while you were catching up on your sleep. Reviewing projects you’ve worked on over the past few weeks or months will keep your heart sinking. Sometimes you’ll find something that you don’t remember adding — even if you just looked at it last week! I’m crazy about code, but you never know…
17. “I don’t know what it means.”
The worst you can do is have no idea what to do with the source code you’re browsing. It could be your own project, it could be someone else’s, but the root of the problem is the same. Now, you have to decide if it’s worth spending more time searching for alternatives, or going through the script to see how it works.
18. “I need Google error information.”
After years of working in PHP, I have to say that Google is my best friend when it comes to debugging problems. The same is true with Objective-C, C ++, Java, Python, and other major languages. Error messages are very helpful, but unless you remember what the different code means, it reads more like translated computer language. Thankfully, there’s plenty of online support to help us determine what these mismessages really mean.
19. “I should stop and call it a day… But I really want to fix it!”
We’ve all experienced the feeling of being extremely frustrated and wanting to give up, but it always feels like giving up halfway isn’t the right choice. So you keep digging and trying new solutions to debug. But what if it still means another wasted hour? I’m familiar with this situation, and it’s very frustrating.
20. “Oh, god, why didn’t I write notes before?”
When it comes to basic front-end HTML/CSS/JS, there is no need to write comments. But more complex scripts and programs require some form of organization when you need to look back months or even years later. Sometimes you forget to comment out functions with their arguments, output formats, and other necessary data. This undoubtedly leads to confusion after a while, and when bugs start appearing, you have to debug the entire script to find a solution. Therefore, it would be helpful to have some helpful comments.
21. “Twenty minutes ago it was working…”
Probably the most frustrating part of building a program is when it goes from working to not working — and you don’t update any part of the code! I swear it’s true. And it doesn’t make any sense — maybe some other program is running a cached version? There are many times when you update a little bit of code and the whole program crashes and stops working completely. Restore to the latest working copy and work your way up from there.
22. “Just forgot a semicolon, and the whole program came crashing down.”
Almost every programming language I use requires terminators. It is common in C/C ++, though not in all languages. Forgetting to add the terminator is just an obvious mistake! But the parser doesn’t know this, and it throws a fatal error. As a result, you have to spend an extra 20 minutes searching for technical glitches when it would have taken only a second to fill in the missing semicolon. Well, that’s the fun of debugging software.
23. “I don’t know how much it would cost to have someone fix my code.”
The idea of hiring another developer is tempting, but not financially viable. And how can you learn from them if you don’t experience them yourself? It feels great when you finally understand a programming concept after so many failures. Still, every now and then I have a “let someone else fix the code” impulse in my head.
“Surfing Hackers News quickly can improve my work efficiency.”
Many programmers like to read the front pages of Hackers News of choice for social News about software and startups. It has lots of information about freelancing, time management, software development, and startup publishing and financing. While the HN can make you feel more productive by educating yourself, it can also waste your time. Surfing Hackers News every few hours isn’t so bad.
25. “Why is there no documentation for this API? !”
One of the most frustrating things about using plug-ins or frameworks with bad documentation is that you have to delve into the source code yourself. I like projects where developers take the time to specifically design usable documentation pages. All parameters and options are clearly explained and may even be used in some sample code snippets. Sadly, this is not always the case. So the easiest thing to do is to stay away from bad documents and not ask for trouble.
26. “I wish I had a backup copy of that database…”
When WRITING and debugging code, I don’t think about backups. However, data backups provide stepping stones that allow us to go back and make changes. This is especially useful in a real-time server environment, where changes are executed immediately. We should remember to save local copies of the site files and database just in case! While this can be an annoying task, it’s nowhere near as annoying as rebuilding a corrupted SQL database.
27. “What’s the fastest solution to make it work?”
After spending hours agonizing over a custom solution, it becomes clear that you need a new approach. Before designing a beautiful interface, the first thing programmers think about is making things work. Identify the fastest, most accurate solution, and implement that solution so that it works 100% of the time. Then, move on to beauty.
28. “I bet updating my software will solve the problem.”
Teams that manage programming language dependencies and plug-ins do not need to release frequently. Sometimes, updating the PHP /Ruby/ Python/SQL version can solve debugging problems when you transfer files from your computer to a live server. Native updates rarely help fix bugs in your source code unless your version is hopelessly out of date. So, it’s worth a try!
29. “I should get more organized and learn About Git… I’ll study it next week.”
Git, the open source version control package, is very popular among programmers. It offers an easier learning curve than its competitors and is used by many online code repositories such as Github and Bitbucket. It’s easy for developers to put off learning Git because it’s obviously difficult for beginners. But once you know the basic commands, Git is a piece of cake. It also makes debug version control clearer.
30. “You know what? I’ll just start over.”
Sometimes, after you’ve been racking your brain for hours, all you need to do is move your work files to your archive (or delete them) and start all over again. However, it’s hard to make up your mind given the amount of time you’ve already spent. However, when I’m at a loss, I often choose to start from scratch because it’s possible to find the right path to complete the project.