Live data from Hacker News

In praise of “normal” engineers

charity.wtf

31–40 of 120 posts

Re: In praise of “normal” engineers

#31
post #7

I definitely agree that the best teams have cultures that make even normal engineers incredibly effective compared to the status quo. Managers definitely put too much stock in hiring and "engineering quality" compared to culture, trust, systems and processes. > Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. But I have to wonder: if "any a…

> if "any asshole" can build orgs like that, why don't they?

The biggest reason, is that most first-line and middle managers suck. They can't create and maintain a productive environment.

The cure is/was to pay heaps of money. People will put up with almost any kind of hell, for good pay.

Re: In praise of “normal” engineers

#32

There 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…

I'm not sure I totally agree with measuring value by avoiding landmines or anything at all related to project management, but it definitely bugs me to see everything reduced to business impact. There are plenty of things in life that matter to individuals, to humanity, to the entire world at large, that have nothing to do with selling products for money. When I think of the engineers I revere the most, I don't think of titans of post-2001 Silicon Valley so much as John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo DaVinci, whoever the hell built the Roman aqueducts and Egyptian pyramids, Babylonians and Mesoamericans who figured out how to predict eclipses.

Did these people have a business impact? I guess Tesla made Westinghouse a lot of money at one point, but that seems far from the most distinguishing thing that made him great at what he did. If anything, he was mediocre at business.

Even if we want to look at current titans of the computing industry, I admire the work done by orgs like Nvidia or humans like Geoff Hinton, but they also just got lucky that what they were doing for completely different reasons ended up benefiting so tremendously from the galaxy-scale data harvesting that has been going on due to the Internet becoming primarily ad-monetized, which they didn't know was going to happen. How many equally great engineers toiled in obscurity on dead ends but did equally great work? Doug Lenat was just as great an AI engineer, if not better, than Geoff Hinton. History just went one way and not the other, due to factors completely outside of the control of either of them.

Re: In praise of “normal” engineers

#33
post #30
post #14

> 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…

i'm struggling to see how what you are saying you value is any different from what i am saying i value (author here).

possibly we're saying the same things in different ways, or maybe it's just hard to pin the difference down in a words

what do you mean by "the smallest unit of software ownership and delivery is the engineering team" in practice?

what's the largest scope of work some engineer can do entirely on their own recognizance?

Re: In praise of “normal” engineers

#34
Some good points, bad logic. The fact that you can't effectively measure something doesn't mean that something doesn't exist.

Individual productivity exists.

Maybe it's easier to measure groups' productivity? Probably.

"Business impact"? I don't think so, that later concept seems much more arbitrary. But feel free to look for the keys under the lamplight. If you choose that metrics, you're not going to retain many extra productive people anyway.

The old problem: judging the work of an expert is very difficult if you lack comparable expertise. I can give you advice, but I can't make you smart to accept it. How could you tell if I'm a genius or an overconfident asshole?

Re: In praise of “normal” engineers

#35
post #7

I definitely agree that the best teams have cultures that make even normal engineers incredibly effective compared to the status quo. Managers definitely put too much stock in hiring and "engineering quality" compared to culture, trust, systems and processes. > Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. But I have to wonder: if "any a…

because there is, by definition, an extremely limited supply of the "best engineers in the world". if you can afford to pay top-10% salaries, and attract and retain top-10% engineers, more power to you.

maybe not literally "any asshole" can do it -- but it certainly asks more of your leaders to craft sociotechnical systems oriented towards learning and enablement. and i don't think that's a bad thing.

Re: In praise of “normal” engineers

#36
I saw a post like this some time earlier this year and my first reaction is the same…

Normal? Seriously?

The article attempts to address this in an incredibly clumsy way by saying, well, everyone is normal in some way! It totally misses the mark and basically pays lip service to the issue after it set the stage, switching over to bigger picture diversity.

Benefit of the doubt, the intention is to say ‘average’. The people in the middle of the bell curve.

‘Normal’ suggests that, outside of that range, you are abnormal if you are terrible and abnormal if you’re talented above or below the median.

There’s a non-zero overlap between abnormal and neurodivergent, both ways.

Given the number of occurrences of ‘10x engineer’ they should have gone with that and not ‘normal’.

Re: In praise of “normal” engineers

#37

There 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…

idk, avoiding landmines seems like pretty significant business impact

Re: In praise of “normal” engineers

#38
post #25

I tend to think that much of the difference between great and mediocre engineers comes down to mindset. The great engineers I've encountered have a commitment to making everything they touch better. They are adaptable and persevere. They believe they will either succeed at the task at hand or conclusively determine that it isn't possible given the current constraints. They recognize that failure will happen and do no…

many fair points here <3

Re: In praise of “normal” engineers

#39
post #14

> 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…

I think that rewrites are an important part of how software is written, and it's an important part of being "agile", in the sense that you can go in and write a prototype that's coded very simply without much regard for long-term architecture, knowing that requirements likely will change and that you likely won't get the design right on the first go anyways.

Coding is like writing, in the sense that it's often faster to write a sloppy first draft followed by a better second draft than it is to agonize over getting the first draft right on the first go. The first draft is generative. Its purpose is not to be good but instead to let you get something built quickly and to let you explore the problem, so that you know what edge cases you'll need to account for in your final architecture.

But this still of working will never get through management because the moment you show them a working product, they'll tell you to ship it and won't give you a chance to rewrite.

I think the best way to solve this is to flatten the hierarchy. Get rid of the notion of managers who rule over engineers and give ownership of the code back to the engineers. Have the engineers and product "owners" make decisions together in a democratic fashion.

Re: In praise of “normal” engineers

#40
> Build sociotechnical systems with “normal people” in mind

From the perspective of the composition of software engineering teams: Most of us have to make due with the average, we strive to find the above average and avoid the mediocre, but mostly we are teams composed of "normal" people. The article has some good advice for making the best out of a group of normal people. It particularly relevant because it's unlikely that you'll see anything else.

Post reply on HN