I’ve had this article bookmarked for some time now and I agree with what the author says. Too often in this field I’ve heard developers complain about another developer’s code because it doesn’t fit into their standard. I’ve definitely looked at code and scoffed at it both vocally and in my head.
Over time though I’ve learned there can be good reason for why something was built a certain way. It could absolutely be a budget reason where they had to cut corners a bit. It could also be that the developer honestly didn’t see a better way at the time, we all have old code we’re embarrassed to look back at. Even at Automattic we have code that’s difficult to work with and other parts that are a joy with great inline comments and unit tests.
Why is this? Expediency.
A good engineer is not the one who knows how to build the most advanced system, but the one who knows when not to build that system.
Sometimes the expedient way is, at the time, the best way. It’s how we hit internal deadlines and/or how we redirect our focus to a portion of code that could benefit most from the time spent making it elegant.
Very often I’ve noticed it’s a lot easier to see how a part of code could have been written better (DRY) after you’ve written what’s in your head. It can be difficult to see the bigger picture on how different parts of the architecture communicates with each other without first building what’s initially in your head. Iterating on the initial idea is key.
Get over yourself, be understanding, and remember that we’ve all been there. If you’re working with someone who always goes the expedient way, maybe they need some help. Talk to them, be open to educate each other and learn together. Complaining doesn’t move anyone forward.
As software developers, we often think our job is to develop software, but, really, that is just the means to an end, and the end is to empower business to reach their goals. Your code may be elegant, but if it doesn’t meet the objectives (be they time or business) it doesn’t f***ing work.