[hot_gril]

I'm a young guy working with way more tenured and experienced programmers who didn't want management positions, preferring to code. Respectfully to them, I can't stand what they do. They obsess over details that do NOT matter to the business, and our whole department is paralyzed like this. Meanwhile big-picture things like internal APIs are either neglected or too big-brained for anyone to understand. I think they're just too skilled, and we need some worse coders with smaller egos to get the job done.

For example, they swear by writing low-volume web backends in C++ "for performance" and object to any kind of framework. Ironically, having to move more slowly and carefully as a result has led to big compute inefficiencies, on top of the more important hit to dev productivity.

[seymourhersh]

How do you know the details don’t matter? Often, not paying attention to the details leads to technical debt.

[hot_gril]

I know they don't matter when I end up being the guy to rewrite and own it, as has been my main job the past 4 (edit: 5 now) years.

[seymourhersh]

That’s fair.

[SlickNik]

These might be evident in retrospect, but it's usually tricky to predict what will matter and what won't during design time. (Someone smarter than me said something about premature optimization once.)

This is also usually where experience can make a big difference.

[hot_gril]

When in doubt, best to start with something quick n' dirty and not worry too much about what happens when it becomes inadequate. Just make sure it can be easily replaced when needed, which means treating everything you write as disposable. When using hindsight, you can build something better.

There's a big back-and-forth thread about this where I explain why well-written code on our team ends up being deleted within 1-2 years, and the author's only mistake was spending so much time deliberating over the code.

[seymourhersh]

“Just make sure it can be easily replaced when needed”, implies a clean architecture of some kind - which implies experience.

Perhaps you’re just better than you realize.

[JohnFen]

A good engineer creates solutions to the problem before them. That problem always includes constraints such as budget, deadlines, maintainability, etc.

Very often, the mathematically or logically "best" approach is not the correct engineering approach because it doesn't meet those practical requirements.

Engineers who insist on a sort of purity are, in my opinion, not the best engineers even if they are genius at writing code.