Nothing Works and I Hate Everything!
If web development has never elicited a response akin to that of Ron Swanson in the .gif below, you are either very new to web development and have not yet had the experience of being utterly at a loss as to why your code does not work (just give it some time…), or you are some sort of Zen master (major kudos, I envy your serenity).
Hopefully, of course, these feelings are fleeting — bursts of agony that arrive and vanish, leaving behind the motivation to press on. But even if brief, feeling this way is rather unpleasant, not necessarily useful, and definitely not something that you want to occur with any sort of regularly in a long-term career. So what can be done to mitigate this response?
There are plenty of stress management techniques like focusing on breathing or meditation, that can be very helpful in the moment. But I often find that digging a little deeper to try to identify the root of an issue can lead to more sustainable solutions. So in these instances, where exactly does the annoyance come from? Why does something that we typically (hopefully!) enjoy also lead to such grievance?
Of course this answer could be different for everyone, but I identified a distinction that has helped me immensely, and thought I would share it, in case it is a source of trouble for others as well.
Many of the problems web developers face are genuinely challenging feats of logic — puzzles that are objectively tricky, things that can get “stuck” in our heads, as we strategize potential solutions, analyze failures in our reasoning, and grapple with nuanced edge cases. These puzzles can feel frustrating, sure, and difficulty solving them can lead to self-doubt (as I discussed in a previous post). But there is something inherently righteous about them. They are authentic problems — real, qualitative issues that need solutions. As such, while they can be maddening at times, ultimately, there is something seductive about them: genuine intrigue that tickles the problem-solving part of the brain that lead many of us to web development in the first place. And solving them — even getting close and coming up with a plan — is exciting. There is a sense of achievement once a challenging bit of code executes the way you want it to — and even knowing that reward exists, makes the moments of annoyance feel less weighty.
And then there are the other kinds of problems. Typos. Minor syntax errors. A slightly-misnamed variable or method (e.g. complete vs completed). Unanticipated issues with deployment. A rubocop error that just feels superfluous (and, frankly a little rude — who are you, rubocop, to decide how many lines I should have in my method?!). The sort of technical issues that are not failures of logic, misunderstanding of the language, or challenging unique edge cases — just silly, minor errors. Things that feel small, that feel like they shouldn’t break your application, things that don’t feel satisfying when fixed. If anything, finding a minor bug and realizing how simple it is can be even more frustrating, because you realize how much time you wasted over something so insignificant.
But — wait! There it is: the feeling that debugging these non-logical errors is a waste of time.
For me, at least, time spent parsing code for typos and other minor errors can feel like it is somehow separate from my actual work — like it is taking away from my real task as a programmer, from my real responsibility, which is thinking through problems and pumping out solutions. Debugging can feel like a distraction — an example of my own failure, and a non-useful time-sink that definitely isn’t part of my real job.
Of course nothing could be farther from the truth. Talk to any professional programmer and they will tell you as much — heck, even watch any video where someone is coding in real time and you will see these sorts of errors. Debugging is not separate from the task of web development; it is a massive part of the job, and always will be.
And not only that, but hunting down these problems absolutely isn’t time thrown away. Every single endeavor results in a lesson. A “simple” mistake you spend an hour (or more…) trying to figure out, is not going to be a simple mistake you make again — or if you do, you will realize it right away. Solving these problems actually does make you write better code. Not only do you avoid repeat mistakes, but working through these issues illuminates the value of clear, readable code. Clear code allows for much more rapid debugging; if your program is full of impressive but almost indecipherable single-line Codewars-like solutions, you are going to spend much more time parsing it every time an issue comes up than you will if your code is easy to read. Being forced to debug your code helps you see what needs to be improved.
Debugging minor errors can feel extraneous to actual web development, but it’s absolutely not. And this isn’t a feeling that’s unique to web development — most tasks have seemingly unrelated components. Before you can paint a room, you have to cover the floors and furniture, clean up the walls, apply painter’s tape. Before you can bake an apple pie, you have to peel the apples and be sure your dishes are clean. If you want a garden, you don’t just plant the seeds — you have to weed and prepare the soil. For each of these things, if you think only of the “glamorous” part of the job as important or meaningful, and the other bits as a waste of time, you are likely to rush through them or do a poor job, so you can get to the “main task.” But if you don’t properly cover your furniture and apply painter’s tape, you are going to get paint in places you don’t want it — making your paint job less successful, and creating more work for yourself later. If you don’t peel your apples and cook with dirty dishes, your pie is not going to be good. (I love pie. It takes a lot to make a bad pie. But that would be a bad pie.) If you don’t pull the roots of the weeds in your garden, they are just going to grow back and take space and nutrients from your vegetables. You get the gist.
What’s possibly worse, in addition to not executing these tasks with care, thinking of them as superfluous leads to the problematic feelings of frustration that are the focus of this article, turning what should be an enjoyable activity into an unpleasant one.
Now, to be clear, I don’t know that I will ever fully consider debugging minor errors “enjoyable” per se, but gaining clarity on this distinction that I was unintentionally making, and re-calibrating my thinking about this use of time has reshaped my experience. Since I began thinking of this sort of troubleshooting as part of my work, rather than a distraction from it, as an opportunity to improve my code, rather than an exercise in being disappointed with myself, I have been much more successful at averting the “nothing works and I hate everything” experience.
That said, this has been a fairly recent epiphany for me; I am still human and reserve the right to shake an occasional angry fist at the sky when I discover that I typed a homophone of a parameter, rather than my actual parameter (darn you rolls vs. roles!), or something equally silly. But thus far, despite being a fairly simple observation, it has been helpful for me, so I thought I would share in case it might be of use to anyone else!
