This was originally posted on my personal blog, here.
Over the summer, I had the opportunity to work with a few of our summer interns. One day we were helping a coworker implement a story. We were coding, building, and testing in short cycles as we went. One time a build failed. After a few minutes of looking, we found that we'd omitted a semi-colon. We fixed it quickly and got back to work.
This experience and a few others like it caused one of the interns to ask what's the longest that I've spent on a simple error like that. Without thinking too much I'd responded that I've spent a few hours at least once on something so simple. While that seems quite ridiculous, especially to a new-comer, it's not out of the ordinary.
Over the years I've come to prefer simple, stupid mistakes like this. While they can be frustrating to find, they're easy to understand and fix. You find it, you fix it, and you're on your way. Simple. Easy. Quick. This is much preferred to some of the other problems you can fix as a software engineer.
The problems I don't like to encounter are problems with architecture, design, or dirty code. Admittedly these can sometimes be fun to fix, but they're much, much more difficult especially in a system that's been around for a number of years. These problems require a lot of digging, both in the code and with product owners and product managers. When you have a problem like this, not only do you have to find the problem, you have to understand why things are the way they are and derive a solution that both addresses the issue and meets existing needs.
Instead of finding an issue, almost mindlessly typing one character, and continuing on, you now have to find the issue, understand how everything works well enough to describe the issue, talk with a product owner and find out what the code is supposed to be doing, derive a solution, ensure that solution meets all the requirements and fixes the issue, then implement and test it. All-in-all, errors that are more complex than a missing or misplaced character cost a lot more and are a lot more involved.
So, if you're going to put errors and mistakes in your code, try to make them simple and easy. Take the necessary time up front and as you go to make your design right and the errors and bugs you see will be a lot easier and less costly to fix.
Latest comments (6)
You're not wrong about taking the necessary time up front to really design something well. But I'd rather spend three hours sorting out a complex issue than 15 minutes hunting down a missing semicolon. The semicolon was a stupid mistake that the linter should have caught and reduces how much I can make an hour (or how much work I can get done on a side project). The long in-depth troubleshooting is generally built into the contract, or is the meat of what I'm trying to do.
I've been thinking on-and-off about this over the past few days. I think I may have misrepresented the main point of my article (I shouldn't reply when I'm tired...). I'll be brief:
I think what most of us (not all, but most) as software engineers really want to be doing is designing and implementing meaningful software. We generally would prefer to work on new features rather than working on bugs (though we understand the value of bugs and work on them as well). All things being equal, given the choice between working on a bug and working on a new feature, we'd take the new feature.
With that in mind, some bugs in ill-designed code can take days to get to the root cause. This is a pretty big waste. This post is to encourage us as software engineers to take the time we need to do it right the first time to avoid these sorts of complex bugs down the road. The fewer and smaller the bugs, the more time we get to spend on the activities we prefer working with.
I hope that helps clarify my points.
I'm going to share an experience I've had that I think is applicable: A few years ago, I was tasked with rewriting a number of "packages" (they were essentially HTML forms in a pretty specific domain). The code was really messy and often left me face palming that anyone would ever think to do it that way. I think I even kept a few code snippets because they were so unfathomably backwards I laughed out loud once I understood what it was doing. Needless to say, there were in dire need of being rewritten.
Over the course of approximately a year, my team and I were able to rewrite all of the ones the product owner cared about. We went from having bugs that took hours to troubleshoot to having bugs that generally took minutes to troubleshoot. The general complexity of the bugs we encountered was significantly reduced.
While I totally admit that designing the new packages and figuring out how we were going to tackle this major rewrite was much more engaging and fun, the business really benefits from the significantly cleaner code. I don't claim to have done it perfectly. There are tons of things I never had time to do and many bugs logged against these new packages, but the time it takes to fix these bugs (and thus the money the business spends on these packages) is the big win here.
In light of that, I will say that I do agree with you that the more challenging problems are more engaging and (sometimes) more fun. But if that's what the majority of the bugs you encounter are, there might be larger issues to address that could save you significant time in the long run. But my view on this is likely biased by my experience. I've never done contract work. I've only worked for businesses that already have large software offerings that have been around for years. Perhaps my experience has narrowed my view on this.
Also, thanks for commenting!
At work (I'm an ops person) we have similar "bugs".
If for example a system runs out of RAM and the OOM-Killer is starting to semi-randomly kill processes.
It's similarly easy to fix (start the processes again), doesn't involve any "figuring things out" and so on.
However I strongly agree with the philosophy prevailing at work.
We don't want to fix such tasks, especially if they are repetitive.
Much more would we like to get rid of these tasks entirely to spend time with more challenging, meaningful things.
We would like to spend our time with the issues you "don't like":
(not so much the dirty code though, unless it's about getting rid of it, or replacing it)
We'd love to fix architectural issues or design and build systems.
Thank you for sharing your comments!
I agree especially with the repetitive part. An old professor of mine said, "if it feels like a computer could be doing this, it should be doing this." Meaning that if you found yourself doing some menial task over and over again, you're doing it wrong. Get the computer to do it for you.
These are definitely the more exciting and engaging things to work on. They're also the most expensive things to work on from a business perspective. Fixing a broken architecture can take years depending on the software in question. I'm not saying it's not fun to do. I'm mainly saying that, if we design clean architecture and write clean code, the issues we'll have as we maintain and continue to grow our software projects will be much simpler to solve.
This (although vulgar) is probably my favorite commit I've ever made in a project, just because it sums up what it's like to find a simple error like that: github.com/MiffOttah/fuckfuck/comm...