Fixing a bug is so satisfying
Published June 20, 2025
Sometimes something doesn't work the way you want it to. Sometimes something doesn't work the way you expect it to. Sometimes something doesn't work the way it's supposed to. Sometimes something just doesn't work. In software engineering we call something like this a "bug". ( I was planning to regale you here, yet again, with the famous story of Admiral Grace Hopper finding a moth in the relays of a computer causing it a malfunction and thus coining the term "bug" but it seems that that story is not factually accurate.)
In any case, the majority of software engineering is debugging (the rest of it being, obviously, writing the bugs.) While no one likes finding out
that the code that they wrote isn't perfect (I don't and I can't imagine you do either) it is a fact of life that software is written by people and
people make mistakes. So when someone finds a mistake in our code we call it a bug and we go through the process of figuring out what's causing it.
Depending on the complexity of the code this process can take a while because sometimes the bug is scattered in multiple places while other times
it's as simple as a ( being in the wrong place (*). Once we've figured out what the problem is we can fix it (and hopefully not break anything else
in the process.)
Finally finding what caused the bug is a hugely satisfying thing (for me, at least.) But nothing is more satisfying than squashing it once it's been found. Fixing it so that it won't happen again. This is made all the sweeter when the code being fixed is something you actually use on a regular basis (**).
Today I had that joy. I had the joy of fixing a bug in Render Enginer that has irked me for a while. It's not a bug that impacts how you see my site
but it is one that impacts how I work on it. Essentially, I work on my site on my computer and I type away, slowly but surely, until whatever I'm
writing is ready for me to publish. That usually involves me wanting to see it in the browser while I'm working on it. So I need to actually serve
the site locally. So we have a command line tool that lets us do that. And it has a reload option that checks the directories where the files are
stored for changes and re-renders the site. Except it wasn't working the way it was supposed to.
It actually had a few bugs. If there was an issue with re-rendering the part that watches for changes would die but the server would live on meaning that you had to kill it and restart it (after fixing whatever caused the rendering to fail.) And for some reason, when plugins got involved it wasn't actually rendering the site again at all. There were a couple of smaller things that were happening as well, but those were the big ones.
So today I took some time, sat down and played with it. And figured out what was causing the issue. And fixed it. So as I type this I switch to my browser periodically and make sure it looks OK. That the links are linking and that the formatting is what I want.
Today I had the immense joy of squashing a bug in my own house and I loved it.
*Very often the parenthesis in the wrong place is actually really hard to find. It take a long time to see it just like you're likely to miss a typo when you proofread your own writing.
** True story - most commercial software isn't really used by the people who write it. If it's consumer software (a messaging app, or something like that) the engineers that work on it probably do use it ("dogfooding" is what it's called) but if it's enterprise software like a CRM or an ERP (don't worry about the acronyms, trust me when I say that if you don't know what they are it doesn't matter) they probably have never used it outside of testing the changes they've made. They don't know how it's used in real life.