I’d like to think that one of the struggles many developers feel when shipping code is a sense of “this could be better” before they push whatever button to send their code out into the world.
Yeah, okay, code review this.
It doesn’t necessarily matter if this is a hobby project, if this is a project for a corporate job, a freelance job, or if this is something that’s for an open source project. I say that because I think this is something that many of us feel with whatever it is that we release.
It’s a feeling of something is “not quite done” or “if I could just refine this a little bit more.” I know: This isn’t the first time I’ve talked about this before, and it’s likely not going to be the last.
And the feeling is not without merit. Other developers can make us feel like we’re doing something wrong (sometimes we are, sometimes we aren’t). But in our industry, I think there’s more of a spectrum of optimal-to-suboptimal. Though some may not agree, a friend of mine recently said it best:
The software industry is too vast and too fast to keep up with it all. But because it’s now that way, people find their niches and think that it’s the “best” or “only” way to get something done.
The further I get into my career, the more I feel this sense of obligation to make things as pristine as possible before sending it to a client, user, or just out for the world to use.
And though I think this is important, it’s important to make sure that I (and we) are doing this for the right reasons.
An example of a wrong reason might go something like this:
It’s not because it doesn’t meet requirements and it’s not because it doesn’t fulfill what was requested by the client. It’s because how others might perceive the work when they do not have the proper context.
So of course, I don’t think there’s anything wrong with wanting to make your code base or your architecture as robust as possible. We should all strive for that. But I believe that it’s important to contextualize appropriately and adequately scope your sprints, milestones, work or however you group your tasks together.
