Great products are not build by normal engineers.
They are built by Linus Torvalds, Steve Wozniak, Larry/Sergey, Greg Brockman.
In praise of “normal” engineers
101–110 of 120 posts
Re: In praise of “normal” engineers
#102There are large parts of this I really like, but it's hard to overstate just how much I disagree with the idea that "The only meaningful measure of productivity is impact to the business". The natural result of this view is a focus on quantifiable changes and short term thinking. The greatest value of experienced engineers is in avoiding landmines that will destroy a project or even a company. It's difficult to quant…
ooh, good point.
You can build systems for efficiency, or build them to minimize disaster. It's really hard to see the negative impact on the business that was prevented.
Re: In praise of “normal” engineers
#103Earlier quoted context omitted.
>With engineers left behind to fix the mess. There would be much less demand for jobs if there were no messes to fix.
Oh, certainly. In a world with far fewer failed software projects, it trivially follows that people would want far less software.
Not sure, what you're saying follows broken windows fallacy.
Good software might begat the need for more good and useful software.
Re: In praise of “normal” engineers
#104Earlier quoted context omitted.
> They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.
Honestly, I don't even think that does the trick anymore. Once you're on the management track, you get infected with the same MBA bullshit as the rest of management, and your brain rewires itself around that culture and those incentives. I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down c…
> Once you're on the management track, you get infected with the same MBA bullshit as the rest of management, and your brain rewires itself around that culture and those incentives.
Not necessarily. The problems rather are:
- Those who are mostly immune to this will hardly ever be put on a management track.
- Those who are resistent regarding this kind of infection won't make any further career in management (incentives matter).
Re: In praise of “normal” engineers
#105Earlier quoted context omitted.
Beyond budget constraints, those brilliant engineers may not be good team players. Their brilliance may be in the way of finding the necessary compromises and doing the required but not intellectually challenging work.
I dunno, almost all the brilliant engineers I've known have also been great team players and mentors. Not all, but I'd say it's pretty correlated. The reason brilliant assholes stand out is one of those statistical paradoxes whose name I've forgotten: somebody who's an asshole has to be brilliant to succeed, while team players can get pretty far with a wide range of skill levels.
I’ve seen plenty of assholes build long successful careers in tech without the brilliance.
Re: In praise of “normal” engineers
#106Earlier quoted context omitted.
Honestly, I don't even think that does the trick anymore. Once you're on the management track, you get infected with the same MBA bullshit as the rest of management, and your brain rewires itself around that culture and those incentives. I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down c…
> they eventually lost their appreciation for the artistic side of the discipline It's easy to obsess with the artistic side of the discipline when you're doing it on someone else's money and assume it's coming from an infinite bag. Once you are a manager and given limited resources to get a job done by a certain date, art goes out the window and it's all about efficiency, you get paid to get the job done, not have p…
I said they lost their appreciation, not their obsession.
Furthermore, the art of the trade is not "pretty code"; it's a design and implementation that can last decades and not require a rewrite to accommodate new feature demands. There is a balance to be struck between business interests and legitimate engineering concerns around technical debt. And as we've gotten more of these MBA wunderkinds at software companies, the balance has swung very far toward the "Just get it out the door, engineers are just spoiled brats who are never happy with anything" end of the pendulum. Pretty much the entire attitude you espouse in your second paragraph.
You're not wrong that it's not the engineer's dime in terms of money. But it's also not the manager's dime on the technical debt credit card. Engineers have to make the trash solutions forced by their management work and scale for years. That doesn't show up on a quarterly report, but that doesn't mean it's free.
Re: In praise of “normal” engineers
#107Earlier quoted context omitted.
Writing high-quality code lets you get more done faster, with less people. It's not just art for art's sake! That's what drives me crazy about this: you can just be better, it isn't even a tradeoff, but most managers choose to be worse instead. It's been a frustrating thing to talk about. The people who've seen high quality work in action just say "well, obviously it will be faster and more effective", and the people…
>Writing high-quality code Who defines what "high quality code" is and who enforces it in a team? Because what's high quality to you might not scan to other members of the team, and if you want to your standards across the team then you have to spend time and effort educating the people and enforcing the standards. And now you're wasting time obsessing over standards and guidelines while your efficiency doesn't incre…
> Who defines what "high quality code" is and who enforces it in a team?
An engineer who has appreciation for the art of the discipline. But since you don't value that and think that engineer is a spoiled brat, you won't hire him.
Re: In praise of “normal” engineers
#108> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in d…
It's extremely simple. Stop hiring/promoting into management who don't know the job. This is extremely common in every other industry, and I and legion of people will keep saying this.
It only seems like not a big deal while "good enough" is a really low bar.
Re: In praise of “normal” engineers
#109Earlier quoted context omitted.
In my experience this is mostly big-company vs. small company cultural differences due almost strictly to size and scaling. Small companies work best when individuals have ownership and large companies with team based ownership. They attract culturally like-minded people.
The highest-agency, highest-ownership team I worked on was at Target of all places. (To be fair, it was not a typical team for the company!) The VP who made that work learned that style of leadership from a decade in Strats at Goldman. Both are pretty big as companies go! On the flip side, I've seen early-stage startups and scale-ups where engineers did not have real ownership. It's easy to get into a situation where…
I think the cultures naturally change with scale. Is isn't a requirement, just a tendency. At least from my personal experiences, friends and read over the years this seems like a good general heuristic. I personally use it as a primary rule for job seeking, I ignore any company over ~500 people. Once they are bigger than that and their culture seems to start naturally evolving to the same stance of people being interchangeable cogs that have no worth as an individual. This naturally leads to team ownership as there is no one else.
Re: In praise of “normal” engineers
#110> When your teams are used to operating with a mix of genders, racial backgrounds, identities, age ranges, family statuses, geographical locations, skill sets, etc — when this is just table stakes, standard operating procedure — you’re better equipped to roll with it when life happens. Resilience doesn’t come from having a “diverse” team on its own. What a shallow take. True resilience comes from mature teams with st…
[dead]