Developing an application is a very stressful job. No one is perfect, so bugs in code are fairly common in this industry. In the face of bugs, some programmers get angry, frustrated, distracted, and even discouraged, while others remain calm and composed. Therefore, how to deal with the process of fixing bugs is also worth pondering.
I would like to share some thoughts that programmers go through when fixing their source code. It's the lighthearted humor that's triggered when things get tense. Generally speaking, the application will work eventually, and then you can also move on to the next great task.
I'm sure many web developers and software engineers have gone through these hardships and then laughed it off afterward.
1. "I don't know whether to delete or rewrite it"
Looking back at old source code, there is an urge and temptation to rework it into larger clusters. Ugly logic statements and verbose syntax make the code very hard to read! But then again, if the code isn't broken, don't fix it. This turbulent struggle is something I often face, and one that obviously plagues many software developers.
2. "For starter frameworks I should check out Github"
I think most developers are aware of Github, where an astonishing number of open source projects are released every day. Programmers in any language can borrow from existing projects over the Internet, join wiki discussions, or create their own code repositories. It's a great resource for plugins and templates you need for all kinds of projects.
3. "Why does this script need so many libraries?"
Especially in some of the more popular languages, such as Java and Objective-C, the number of libraries can become extremely ferocious. When building a framework that requires a lot of foundation, the number of required libraries becomes much more apparent. Even some plugins for JavaScript require countless additional files. At times, this can feel cumbersome and annoying - but at least it works!
4. "There must be a solution somewhere on the internet."
My first reaction to a tough question is to look it up online. Programmers post issues they encounter to the forum, and the issue is eventually resolved and archived. A good helper for Googling question keywords can point you in the right direction of discussion. Unfortunately, sometimes you can't find it because you don't have too much information on a particular problem at hand.
5. "Is there a plugin for this function?"
Why reinvent the wheel? Plugins are a great resource for extending the user interface of any program or website. Additionally, they provide developers with some customization and unique options. In case there really isn't a plugin available, is there nothing not to build one yourself?
6. "Although the site works, I'm afraid of IE."
The history of rendering web pages in Internet Explorer is full of hardships that we have all seen or experienced. Upgrading from version 5.5 to IE9-IE10 always requires getting support from more advanced browsers. Web developers may be afraid to debug web pages because opening the page in IE6 is a rendering nightmare. Thankfully, those days are slowly becoming a thing of the past.
7. "It doesn't seem very logical for a logical expression."
There are logical expressions for if/else loops, for loops, while loops, do loops, etc. When going through the sample code, I'm trying to figure out how my logic works. There are so many NOT operators and comparison tokens. I often go back and update my own logic to better fit future practices.
8. “I spend 30 minutes writing a function and 2 hours making it work.”
Doesn't this look 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 out the line number where the error occurred. When you finally find the culprit and fix it, it's exhausting but comforting.
9. "After reading multiple blog posts, I realized that I was all wrong."
I often dive right in with my programming ideas from the start, but this can lead to trouble if things don't go as well as originally intended. There have been many times when I've started a project, got bogged down, and had to seek support from blogs and other papers. Then I found out that my whole approach was actually wrong, and it was easier to start over! It would save time in the long run if I did some research first when I started.
10. "Nice people on Stack Overflow may be willing to help me."
I've lost count of how many times I've solved a puzzle through Stack Overflow. The community is full of nice and smart people who are more than willing to help if you take your first steps. 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 problem was the lack of a closing parenthesis."
Debugging is a step you must take. Two steps forward, one step back. Staring at the code for hours, thinking there is something wrong in the function name or variable scope, only to find out that a parenthesis is missing, it's a bittersweet feeling. All this time wasted on a small syntax error.
2. "Have a coffee and take a break!"
Sometimes, you just need to stand up and stay away from the monitor. Hovering over the keyboard for hours can instead help break the routine. Most health guidelines recommend that we take 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.
3. "I should put this project on the shelf and deal with it later."
Another option for taking a break is to get away from your project, not just away from your computer. If there is other work to be done, then you might as well do other work. This is a better allocation of time and resources than if you've spent 5 hours trying to solve a problem and still can't get started.
14. "I'm very skeptical that classical music can inspire my programming skills."
There is a theory that classical music can promote plant growth in the early stages of life. I personally really enjoy listening to classical music while writing complex notes. Jazz, piano, big orchestra, elegant music has a place in human culture all over the world. So, does listening to smart music while programming really make you debug smarter? Probably not, but hopefully it doesn't make you more clumsy.
15. "Have a drink, maybe now is a good time to test Ballmer's peak theory."
Many readers have heard of Ballmer's peak theory, based on a particular XKCD comic. Simply put, the theory is that a programmer's coding ability peaks after a certain amount of alcohol. The author's name is Steve Ballmer, and he acts eccentrically like a drunk, which is somewhat ironic, since Ballmer was never a real programmer at Microsoft. Maybe we need to wait for others to prove this theory in practice.
16. "Did someone touch my source code?"
It sounds a bit delusional and paranoid, but sometimes you can't help but wonder if someone wrote this while you were resting. Thinking back on projects you've worked on over the past few weeks or months will keep your heart sinking. Sometimes you'll find something you don't remember adding - even this project you've only browsed in the last week! I'm crazy about code, but you never know...
17. "I don't know what that means."
The worst you can have is that you have absolutely no idea what to do with the source code you're browsing. It could be your own project or someone else's, but the source of the problem is the same. Now, you have to decide if it's worth spending more time searching for alternatives, or scrutinizing the script to see how it works.
18. "I need Google error information."
After working in PHP for many years, I have to say that Google is my best friend when it comes to debugging problems. The same goes for Objective-C, C++, Java, Python, and other major languages. Error messages are very helpful, but unless you remember what the different codes mean, it reads more like a translated computer language. Thankfully, there's plenty of online support out there to help us figure out what these misinformation really means.
19. "I should stop and call it quits...but I really want to fix it!"
We've all been extremely discouraged and want to give up, but it always feels like giving up halfway is not the right choice. So you keep digging in and trying new solutions to debug. But what if that still means another hour of wasted? I'm no stranger to situations like this, and it's very frustrating.
20. "Oh my gosh, why didn't I write some notes before?"
When it comes to comparing basic front-end HTML/CSS/JS, we don't have to write comments. But more complex scripts and programs require some form of organization when you need to look back in a few months, or even years. Sometimes you forget to annotate the function and its parameters, output format, and other necessary data. This will undoubtedly lead to confusion after a while, and, when bugs start appearing, you have to debug the entire script to find a solution. Therefore, you will benefit a lot from having some helpful comments.
21. "It was working 20 minutes ago..."
Probably the most frustrating part of building a program is that it goes from working to not working - and you haven't updated any part of the code! I swear it's true. And it's something that doesn't make any sense - maybe some other program is running the cached version? There are many times when you update a tiny bit of code and it crashes the whole program and stops working completely. Revert to the most recent working copy and work your way up from there.
22. “Just forgot a semicolon and the whole program crashed because of it.”
Almost all programming languages I use require terminators. Although not available in all languages, it is common in C/C++. Forgot to add the terminator, but a very obvious mistake! But the parser doesn't know this and it throws a fatal error. So, you had to spend an extra 20 minutes searching for technical glitches when it only took 1 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 clearly not so financially viable. And how can you learn from these mistakes if you don't experience it yourself? When you finally understand a programming concept after many failures, it feels really good. Still, there is a "let someone else fix the code" rush in my head from time to time.
24. “A quick glance at Hackers News has improved my productivity.”
A favorite read by many programmers, with a selection of social news about software and startups, is the Hackers News front page. It has a lot of information on freelancing, time management, software development, and startup launching and financing. While HN can make you feel more productive through self-education, it can also waste your time. A quick glance at Hackers News every few hours isn't that bad either.
25. "How come there is no documentation for this API?!"
The most frustrating thing about using a plugin or framework with bad documentation is that you have to dig deep into the source code on your own. 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. But sadly, that wasn't always the case. So the easiest way is to stay away from bad documentation and not ask for trouble.
26. "I wish I kept a backup copy of that database..."
When writing and debugging code, I don't think of backups. However, data backups provide a stepping stone that allows us to go back and make changes. This is especially useful in a real-time server environment, where changes are implemented immediately. We should remember to save a local copy of the website files and database just in case! While this can be an annoying task, it is far less annoying than rebuilding a corrupt SQL database.
27. "What's the quickest fix to get it working?"
After spending hours mulling over a custom solution, it became clear that you needed a new approach. Before designing a beautiful interface, the programmer's first thought is to make the function work. Identifying the fastest, most accurate solution and implementing that solution to make it work is 100% time-consuming. Then, move on to the beauty aspect.
28. "I bet updating my software will fix this."
Teams that manage programming language dependencies and plugins don't need to release releases as often. Sometimes updating the PHP/Ruby/Python/SQL version can solve debugging problems when you are transferring files from your computer to the live server. Local updates rarely help fix bugs in the source code, unless your version is hopelessly out of date. So, it's worth a try!
29. "I should be more organized and go learn Git...going to work on it next week."
The open source version control package Git is very popular among programmers. Compared to other competitors, it offers an easier learning curve and is used by many online code repositories such as Github and Bitbucket. It's easy for developers to put off learning Git in action because it's obviously difficult for beginners. But once you know the basic commands, Git is a piece of cake. And it also makes debug version control clearer.
30. "Forget it, I'll start from scratch."
Sometimes, after you've been racking your brains for hours, all you might do is move your work files to an archive directory (or delete them) and start over from scratch. However, considering the time that has been spent before, it is difficult for you to make this determination. However, when I'm at a loss, I tend to start from scratch because it's possible to find the right path to completing the project.
The article is transferred from: Code Agricultural Network