Live data from Hacker News

In praise of “normal” engineers

charity.wtf

1–10 of 120 posts

Re: In praise of “normal” engineers

#2
This is how you maintain/nurture a mature service/product.

It also works when building something new with a captive audience (banking, insurance, etc.)

Everything doesn’t need to be world-class. Sometimes long term development stability/resiliency is what matters.

Re: In praise of “normal” engineers

#3
> The best engineering orgs are the ones where normal engineers can do great work

I quite like this. It is absolutely true as well, not all teams can be 100% rockstars. How well do you enable the average dev to be good, maybe not GREAT but good and reliable.

Re: In praise of “normal” engineers

#4
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 quantify things that never happen, or communicate the value in avoiding them in terms that don't sound wildly hyperbolic.

Re: In praise of “normal” engineers

#5

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…

“Impact on the business” isn’t inherently a short term viewpoint.

Maximum impact is a long term proposition.

Re: In praise of “normal” engineers

#6
I’ve thought a lot about this my whole life. How do you build a good team? People simply don’t like each other so the natural sorting that happens is that teams hire for who they like and likes them in return (or at least in mating terms, will certainly appear as likable as can be). By definition, this can never be the most optimal team.

There may have to be a different way to think about this. How can you have things that hate each other but still run an amazing operation? The best operation I can think of is a zoo. You have your tigers over here, and your penguins over there. The operation as a whole is amazing.

A company of just tigers will destroy everything and a company of just penguins need too much caretaking.

Most armed forces are not a “team”, they are an operation. If you constantly try to fit an operation into a team framework, that’s when you’ll try to turn penguins into tigers (how do you turn someone into a 100x engineer?). Or worse, you tell a tiger to chill out and relax with the penguins (you’re asking for trouble). If you need a 100x engineer, make sure the engineer is a thousand miles away and gets paid like it and far away from the normal engineers lest they start believing the tiger cage is suitable for penguins or vice versa. It’s a big operation, no teams.

If you MUST build a team, then just be yourself. You probably are building something small dogs like, so hire a few street dogs and you won’t even need to worry about zoo-scale decisions and operations. You won’t need to go through the mistake of jamming 4 different species into the same enclosure to finally learn how things live separately but together.

Re: In praise of “normal” engineers

#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 asshole" can build orgs like that, why don't they? I know of only a handful of orgs that actually manage to build strong teams of really strong engineers, and they're almost exclusively either trading firms or specialized/research-oriented teams. What's stopping everyone else?

I guess this comes down to the initial point in the article: what do we even mean by "productivity"? (Or, the word I'd prefer: "effectiveness"?) There are lots of orgs where only experienced folks can succeed because they're the best at working around and tolerating disfunction. I've seen performance review processes that—intentionally or unintentionally—selected not for some general technical strength/taste/etc, but for the willingness, ability and stamina to put up with management dysfunction. But, to me, that is very much not what I have in mind when I think "top engineer".

Re: In praise of “normal” engineers

#8
post #3

> The best engineering orgs are the ones where normal engineers can do great work I quite like this. It is absolutely true as well, not all teams can be 100% rockstars. How well do you enable the average dev to be good, maybe not GREAT but good and reliable.

Most great engineers were once good engineers. A healthy engineering organization helps its engineers on this path.

Re: In praise of “normal” engineers

#9

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…

100%. I've taken to using intentionally fuzzy phrases to describe productivity/impact/effectiveness/whatever. Like, "in a holistic accounting, person X did a great job". It's not necessarily—in fact, necessarily not—easily quantifiable or legible, it requires some human insight and judgement, but so does any complex, creative endeavor. Trying to reduce management to metrics is inherently short-sighted.
Post reply on HN