4 ms·
I used to work with a guy who took "gets shit done" to a level I'd never seen before. It changed the way I look at programming. He was actually a pretty good en
by dionidium 4y ago
I used to work with a guy who took "gets shit done" to a level I'd never seen before. It changed the way I look at programming. He was actually a pretty good engineer. Wrote good-enough code. But he wasn't precious about anything and he didn't care all that much about finding the 100%-guaranteed-socially-approved-correct way to do things. What he had was an incredible ability to diagnose and fix problems quickly, strong intuition about how to architect greenfield projects, and the complete confidence of his bosses, with whom he very quickly earned a reputation as the person to go to when something absolutely needed to get done. He knew what to prioritize. He knew which parts of the code to plow through and which to take his time on. He knew exactly where in the code to start looking when a bug came in. And he knew which things were important to management and which weren't.
I learned way more from him than I ever have from the kind of peers who have opinions about how to structure every line of code.
- ignoramous 4y agoIf I may, you should encourage your ex team-mate to share their side of things: https://staffeng.com/stories https://staffeng.com/stories
- enraged_camel 4y agoIn my experience it is useful to have such people on the team, but if they make up most of the team then the codebase becomes a gigantic mess over time, and it negatively impacts everyone else.
- mmmpop 4y agoPerhaps but having "that programmer that management likes" is worth 10x more than whatever mess is generally being made.
- skrtskrt 4y agoYep I tend to be more on the spectrum of focusing on code & architecture quality over raw productivity, and I find the "plow through it and get it done" engineer to be the perfect foil to have on my team. Ultimately it gets done faster than it would if the whole team was my personality, but with higher quality than if the whole team was their personality.
- pablok2 4y agoIf you're lucky enough to have someone buy into a centralized code/arch strategy then this is idea, the issues arrive when the code/arch strategy isn't a hard sell for the plow engineers.
- bick_nyers 4y agoI consider myself a plow engineer, and I definitely agree with you, a team full of people like me would descend a codebase too deep into chaos. A dance between balance of order and chaos is ideal, as too much of the other has significant negative side-effects.
- alexashka 4y agoHe is almost certainly way above a pretty good engineer. Nobody can quantify 'good-enough code' but everyone can quantify meeting a deadline. How much engineering is anyone really doing anyhow - or are we calling using React to build yet another set of forms users fill out with some error handling engineering nowadays? :)
- cpeterso 4y agoFixing bad code is easier than fixing bad architecture. And if your architecture is modular and cleanly decoupled, then the bad code’s impact can be contained.
- yodsanklai 4y agoThis is a good point. Modularity is the key to managing complexity. Unfortunately, I think writing a good architecture is harder than writing good code at the local level (because most developers have less experience at writing code in the large). And projects with a good initial architecture tend to diverge as developers add new features and introduce new dependencies. They often don't understand the original design and want/need to get things done quickly.