Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

321–330 of 543 posts

Re: “Normal” engineers are the key to great teams

#321
OT: funny quirk in the article mark up ...

> Individual engineers don’t own software; engineering teams own software.

the portion "software; engineering" -- just because the words are adjacent here, even though they belong to separate phrases, are treated as one term and hyper-linked to articles tagged with "software engineering" :

https://spectrum.ieee.org/tag/software-engineering

Re: “Normal” engineers are the key to great teams

#322

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

You are so wrong.

Complex multiyear things are so unique that there is next to 0 chance to find another competent engineer as replacement. Some companies do that, and the only result is the extreme lack of quality and consequently reputation degradation. I witnessed this myself many, many times - great products turning into non-efficient and hard to use BS.

Complex things posses such a big number of moving components that simply iterating over them placing them into context is impossible for anyone except the one that was deep into it for years. Its not possible to "fill in" such person, particularly if that person was lacking in some domains like proper documentation (typical case).

As an example, I am leading a project that creates a government bank from 0. Just in last 2 years I wrote 1000+ pages of compressed documentation on it besides programming and management. Please replace me. My company and I are trying to do that for last 5 years.

Re: “Normal” engineers are the key to great teams

#323
There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who understand what they are doing. And then... the 100xers like Linus. It's pyramid-shaped. If the author is referring to people who understand what they are doing as "normal" engineers, granted, you can make a great team out of these... but how do you find many of them in the first place without bumping into the others?

Re: “Normal” engineers are the key to great teams

#324
post #67

Earlier quoted context omitted.

Anyone that has been doing this job knows that the majority of average developers in any workplace will also cut corners every once in a while and leave a lot of tech debt to others, with very few exceptions. This myth that more productive developers are somehow worse and will ruin projects is just rationalization without any ground in reality.

Except it’s not a myth. Many of us have encountered the perceived more productive developers that ship barely passable garbage.

The myth I’m criticizing is that sloppiness has a stronger correlation with being productive. It doesn’t. Plenty of slow developers who suck.

This is just rationalization.

Re: “Normal” engineers are the key to great teams

#325

Earlier quoted context omitted.

I think one thing that is very different about software engineering is that it's the only form of engineering I'm aware of where a very substantial fraction of the people employed to do it lack basic fundamentals like "being able to do it". Most software engineers can't write a program without google. They can't remember basic facts about the language they use every day. They don't have a sense of what makes sense an…

I don't think, excluding some scenarios at well-disciplined firms that anything like "engineering" exists in programming. The processes surrounding development often strike me as haphazard, cargo-cult like behavior, and entirely subjective. Regarding people not remembering stuff--yeah that's probably true, but there's a lot a typical developer has to jump between--do people really get to "specialize" in JUST like wri…

I've worked mostly in Silicon Valley. At bigger tech companies I found that the minimum level of competence is a bit higher, maybe because of the aggressive stack ranking and PIP/firing pressure. At small companies either low bar is very high, or it's nonexistent, I've seen both.

The weird thing is, at a high performing organization it's relatively straight forward to get a job: be very good at what you do and practice for their hiring process.

At a dysfunctional organization there's not really a way to get hired (apart from an internal recommendation). This is almost by definition, as their hiring process doesn't measure anything reliably. Being physically attractive or charismatic helps a lot.

Actually this gives me an interesting idea, can you measure the quality of an engineering team purely by how ugly they are? My hypothesis is that a dysfunctional team has a low ability to measure aptitude, and so things like physical attractiveness will have a higher impact on hiring decisions.

I don't blame you for wanting a nice stint in one of these dysfunctional companies, I think I could have worked an hour a week and been praised as a top performer at the ones I unfortunately spent time at. I think if you do go this direction you should get 2 or 3 such jobs. It's only a tiny bit more work, and these companies tend to just stop existing some random Tuesday.

Re: “Normal” engineers are the key to great teams

#326
Those were quite some claims about 10x engineers, made with zero evidence.

We also need to decide what we mean by a “10x engineer”. Many people here are describing engineers who “appear to be productive, spewing out shitty code that makes things worse”. The infamous industrious incompetent. This is not a useful definition of a 10x engineer. There is a reasonable definition of a 10x engineer: a 10x engineer creates 10x the value of a 1x engineer over the same period of time. This is the only meaningfully useful definition. Anyone who wants to understand 10x as “damaging spew” is choosing an unproductive definition. I assume such people are 1x engineers. To be a 10x engineer is to be the kind of person who believes that some engineers can be 10x, and then goes about find out how to be that themselves. 1x engineers get caught up misidentifying bad engineers as “10x engineers who are shit” so they can continue to be mediocre.

Re: “Normal” engineers are the key to great teams

#327

There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who understand what they are doing. And then... the 100xers like Linus. It's pyramid-shaped. If the author is referring to people who understand what they are doing as "normal" engineers, granted, you can make a great team out of these... but how do you find many of them…

Agree. The required abilities multiply rather than add so the right tail extends much further than a normal distribution. The gap between median and top performers is extremely large.

Re: “Normal” engineers are the key to great teams

#328

There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who understand what they are doing. And then... the 100xers like Linus. It's pyramid-shaped. If the author is referring to people who understand what they are doing as "normal" engineers, granted, you can make a great team out of these... but how do you find many of them…

To start with, there are engineers who deserve the title engineer. You are probably better of to hire a former civil/electrical engineer that can fizz-buzz than someone that can just fizz-buzz.

Coding and productivity are one thing, but engineering in the end is a lot about having a certain awareness of the impact your technological choices have on a project both in the short and long term. I'd rather take someone who has this awareness, than someone who hasn't, even if the person in the latter category would be slightly better at coding.

Re: “Normal” engineers are the key to great teams

#329
post #20

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

>These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. Didn't we pass the rubicon on that in the early 2010s? I personally don't feel that its "like" finance but that its the exact same behaviors from the exact same set of people. Once tech stopped being a bunch of nerds in a basement and started being a source of wealth and power, it…

Oh stop narrating like nerds in a basement are cuddly lovable bunch.

Amount of toxic behavior in nerdy groups is just as high as finance.

Every single one just thinks how smart he is and how to one up the other.

Technical interviews were always bad even before 2010 as there was loads of gatekeeping anyway.

Re: “Normal” engineers are the key to great teams

#330

Earlier quoted context omitted.

Someone imagining they are brilliant doesn’t make them brilliant. More so if in the light of day their work sucks. Discussions about 10x engineers are not about “wannabe 10x engineers”. — I have yet to come across an intellectual area where there isn’t a long tail of higher talent. As the “x” goes up they just get more rare in reality, and even rarer to see. Because they are not always being optimally challenged. Mos…

You really can over-hire and I've seen it happen in many shops If a "10x engineer" is not given 10x problems, they will.. create some.

If by “create some” you mean “Identify a major new revenue stream” or “Investigate something everyone else considers great, improve it 10x and save hundreds of millions of dollars”, then yeah, that’s what I do.
Post reply on HN