The title of this post is extreme, and maybe clickbait-y, but I’ve come to agree with the sentiment. I think it’s made me a better developer.
A manager I know likes to describe software engineers on a spectrum, between “cowboy” and “astronaut.” Cowboys commit to master frequently, leaving a trail of bugs and TODOs. Astronauts ruminate on open PRs for weeks and over-architect for every possible (unnecessary) scenario. Good developers are somewhere in the middle. I’d say the best are the ones who can play both roles, depending on the requirements at hand.
Sometimes you just need to cowboy 🤠 some code to spike an experiment, other times you need to astronaut 🧑🚀 a foundational solution. The extremes are never the answer, but knowing which hat (helmet?) to wear and when is an invaluable skill.
I’d call myself astronaut-leaning, and learning to become more of a cowboy has made me a better developer, which is the sentiment of this post’s title.
Caring less about code doesn’t mean caring less about its outcome. In fact, putting the outcome before the implementation can really unlock you to think about the problems that “matter.” The value your software delivers, not the software itself.
It’s similar to the trap of building what you think your users care about vs what they actually want. No one cares about the abstractions or elegance of the code beneath your product, they care about the product.
Good abstractions, maintainability, elegance, reliability, the “behind the scenes” features of code astronauts like to overthink, can also be the outcome, if that’s what the problem calls for. They just don’t always need to be part of a particular solution.
Learning to care less about code can make you a better developer. It will make you more willing to throw code out to try new ideas, and less likely to get caught up in minutia (though, often it’s the minutia that makes our jobs fun!).