Press enter or click to view image in full size
Let me start with the core truth and spend the rest of the time juggling with words.
The truth is that our whole industry doesn’t know the best way to build software. (Yeah… Yeah… you can throw a rotten tomato at me for saying this). All we do is try to use our existing (imperfect) knowledge and guesses (even less perfect) about the future to build it as best as we can.
We can argue tooth and nail whether “the best way” applicable to a wide range of software exists at all. We can probably argue whether “the best way” exists even for some tiny specific niche. There are always tons of arguments about whether some accepted best practices are good or counterproductive.
So, all of us are constantly trying to figure out how to build software, and there is a never-ending battle of wills to find and prove to others that our way is better than other ways.
Lately, I often come back to a discussion about a pragmatic<->idealist spectrum. I find it’s incredibly important to understand where engineers are on this spectrum (because it governs tons of their decision-making).
The core value of a pragmatic developer is “Does it work?”. And the further you go in the direction, the more pragmatic developers are willing to sacrifice for “it works”.
On another side of the spectrum are idealistic developers, whose main value is “Is it done the best way?” And again, the further on the idealistic spectrum you are, the more you are willing to sacrifice to do it “the best way”.
Both ends (if you go too far) of this spectrum are deeply dysfunctional.
Extreme pragmatism becomes unbelievably mioptic (with an incredibly heavy concentration on today's needs, ignoring and sacrificing anything future-looking). If you go far enough, people will start dropping know best practices in favor of completing the task faster. And again, if you go to the absolute extreme, usually, such developers end up being amazing prototypers ( concentration purely on getting only a positive path working) and terrible production engineers (where the code needs to live longer than a prototype).
A small side note. It’s probably even hard to call them “pragmatic” at this point. However, I think it’s an application for any spectrum. If you go to extremes quite often, the names become pretty meaningless.
The opposite side extreme of the spectrum is probably even more problematic. People who are too idealistic get wrapped around the axle to find perfect solutions for even trivial and mundane problems. Often they have problems producing any deliverables, or they got stuck in a never-ending polish cycle. Again, you go far enough on the spectrum, and you get to an analysis paralysis state.
It’s important to understand where people in your team are on this scale.
On the one hand, having a bit of diversity is great. It’s nice to be reminded sometimes that the product needs to be delivered (even if the solution won’t win the Webby Awards). And it’s nice to be reminded by another side that there are sometimes better solutions than ducktape and WD-40.
Unfortunately, if people on the team are too far apart, it will create tension. Both parties' hearts may be in the right place (believing that they are trying to do good by the company). However, their approach may be so different that it will create an unhealthy amount of tension.
I was trying to write a wise summary/recommendation here but realized that I am falling asleep already. So, this time around, it’s on your to figure out what to do.
The only thing that I would say is that being open, explicit, and respectful (about where you stand) helps immensely. It doesn’t solve the problem, but at least it clarifies your position.