Facing the Bug, Fixing the Heart: A Debugger’s Emotional Support Session.
This is not a blog on flies or mosquitoes. It is about what every developer’s fear: BUGS.
Not the kind of bugs that give you a buzz in the ear, but the one that haunt your mind…. in the bathroom, while you‘re sleeping, even when you are praying.
If you are a fellow dev, you know that feeling. If the solution to that mysterious error on line 103 doesn’t suddenly hit you in your sleep, then congrats you are safe……for now. These bugs are waiting patiently, sneaking up on you the moment you relax, lie down, and finally drift off. Then crawl back into your brain like: “Hey … remember me?'“
Writing and debugging the code are two different concept, if you ask me. Anyone can write code and debug their own mess. But someone who truly knows how to debug, they can fix any code even those huge bugs from a code written by someone who apparently hated whoever would have to work on that code next, or simply he did write and deployed the code on a random Friday afternoon.
As time goes, I’ve had the chance to work on open source projects, interns and help different people fix their bugs, as a small freelance thing on the side. It wasn’t something huge, but I enjoyed helping others and learning from their mistakes too. That made me draw a common patterns that I have noticed among them.
In today’s tech world, the biggest problem is relying on AI tools to write code, or fixing errors. But what really does is changing your whole code, bypassing the bug or adding extra lines of code that turn your code into pure spaghetti code or as I call it ZAALOUK code, who does not know it, it’s a morocccan dish with eggplant, pepper, onions and tomato and everything is smashed there but it is delicious on a plate …. but a disaster. Suddenly, instead of error on line 103, you now have a new error on line 240 in a file you didn’t even remember that you did create it. Using AI tools to save time is totally fine. Write the base yourself, read and understand the syntax, and know what each part of your code does. That way, when you add something new, you actually understand how it works and you avoid ending up with ten different files, imports you don’t recognize, and functions you can’t trace.
The second mistake is related to the first one, but it deserves an explanation and a whole paragraph about it. It’s the habit of writing random code from the internet because it “solves the problem” … or does it? (Yes, a question mark intentional, because sometimes it does solve it but often it creates three new ones.) The code is not only lines but also a language we use to communicate with the computer, a bunch of commands, logic and structure. Understanding it, is like understanding the local language of a country you are visiting, you can’t just point at things and hope people get it (They do after guessing wrong for 3 times)
One of my client had a final year project and he relied on AI to write most of the code. The result? A tragedy, multiple lines, duplicated files, and conflicting functions. In addition, the deadline is approaching. Half of the project is working, the other half did the opposite of the work, and he was overwhelmed …. Understandably. When I started digging into the project, I found out that a function existed twice in different files while they are both imported and both trying to execute, so the program didn’t even know which one to use. The importance of calling and executing each function in its time is alone enough to confuse the system. And while fixing that, of course a new error appeared… but hey, at least the old one disappeared, so progress? All of this chaos happened because the code wasn’t properly understood from the start. When you don’t know what each line does, you end up blindly patching errors while the clock is ticking and stress keeps rising. Understanding your code first is what saves time, not random fixes or quick copy-paste solutions.
Another scenario is when several people are working on the same project, and they all continue to add code without really considering the bigger picture. For instance, developers frequently write code for each feature separately. Then, additional lines are just stacked on top of the ones that already exist when something new needs to be added. The codebase gradually expands in an unstructured way, which eventually causes more bugs.
I discovered that writing code is not everything when I was studying. Writing clear, organized, and readable code is what really counts. A well-designed codebase facilitates future updates, enhances teamwork, and keeps the project from becoming a confusing mess that nobody wants to maintain.
Also, keep in mind that the client will always want to add new features into its project.
The best thing in learning multiple languages and working on multiple projects to solve problems is that you don’t really have to be familiar with the whole project, you will figured out things on your own.
Coding is not just a job you could have to pay bills, coding is passion, a one love side, it takes time, consistency, and your social life. I’ve seen people not passionate by coding and let me tell you, they have changed their career or just there in corporate job and not evolving in there career. You have to always find the things you love about coding.
Debugging and finding errors were my first real love in tech. Back in first year of university, I once participated in a Bug Bounty training. That was the moment I realized something clicked. I didn’t just enjoy writing code, I genuinely loved breaking it understanding why it failed, and then fixing it.
There was something unuasually satisfying about finding a bug that no one else noticed and watching everything suddenly make sense again. Even during group projects, I naturally ended up being the one fixing errors in other people’s parts, not because I had to, but because I actually enjoyed it. What felt like a chore to others slowly became my favorite part of the process.
I realized then that bugs weren’t just problems. They were puzzles that needed to be solved.
