3 ms·
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'
by hot_gril 4y ago
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 4y agoHow do you know the details don’t matter? Often, not paying attention to the details leads to technical debt.
- hot_gril 4y agoI 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 4y agoThat’s fair.
- SlickNik 4y agoThese 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 4y agoWhen 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 4y ago“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.
- hot_gril 4y agoEh, if you're given a well-separated API to deal with, the code can be pretty terrible without being hard to replace. What makes it hard to replace is when someone puts a lot of thought into it and doesn't want you to rewrite it.
- JohnFen 4y agoA 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.