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'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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!