Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

521–530 of 543 posts

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

#521

Earlier quoted context omitted.

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.

I've seen more of what someone called "wannabe 10x" making a career of turning non-10x problems into a series of 2 year Greenfield project pitches and failures to launch across multiple firms. You can actually see people pull this off for 6-10 years before they need to do something more productive.

Oh for sure. I’ve seen people get promoted based off the possibility of the bullshit idea they’ve come up with, and then move on before reality kicks in.

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

#522
post #438

Earlier quoted context omitted.

A great engineer isn't the one writing the most "brilliant" code; it's the one who understands the problem, picks the simplest solution that works, and makes life easier for the next person who touches it.

In my experience, the person you're describing is hardly ever the one perceived as having "5-10x business impact". Specifically, "making life easier for the next person who touches it" is unproductive use of company time. Which is why I have learned to stay away from people who use that metric.

Yeah, “business impact” is measured entirely on a short-term basis.

In 3-4 years when you need to make a drastic change, that’s when the actual business impact comes into play, but this is never measured.

In my experience with some groups, waiting another 2-3 months to do things correctly would have saved years in future work.

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

#523

Earlier quoted context omitted.

Yes - Dr Norvig is exactly the type of expert I would often engage to figure out difficult problems. Ask him how to configure a Nomad cluster and he would likely say "What is a Nomad cluster do?" Writing and debugging production code is a different skill set. Finding the optimal algorithm is useful but not the same as releasing it into the wild which may require maintaining backwards compatibility, work arounds for b…

Just because he's brilliant at writing green field code to solve problems like this one, doesn't imply he's incapable of producing production code when required.

Never meant to imply that he could not. He is a far more accomplished programmer than myself. Simply pointing out that he is an expert and his skill set is unique and in someways quite specialized. He may be considered 10X in his domain - maybe not so much outside of it. Programmer/Software Engineer are broad terms.

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

#524
post #316

Earlier quoted context omitted.

See also The Worst Kind of Programmer [1] which talks about how detrimental the work of high performers often is. [1] http://mikhailian.mova.org/node/284

The real 10x devs are the ones that just do ten times less work than the rest but you cannot tell from their output.

Haha. That made me laugh. I will now go looking for “The Mythical 1/10th Programmer”.

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

#525

Earlier quoted context omitted.

Systems thinking isn't a political belief, it's a model for the world that is incredibly useful in a lot of contexts. Some political factions may be more likely to engage in systems thinking than others, but that doesn't make it a political topic.

I dont see much systems thinking applied here given what follows this sentence

Then I don't actually know what you meant by your original comment. What was the political ideology manifested by that sentence?

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

#526

When did IEEE become host to clickbait nonsense? This whole take feels like an editorial by a junior engineer going off vibes. It's all off-base, from the misunderstanding of how to measure productivity, to what output matters, to the idea that there is such a thing as a "normal" software engineer. It's kind of embarrassing.

Yeah, it's really a poor quality post, but these terrible arguments and affirmed my bias toward believing 10x engineers exist and there are many great reasons to want to continue hiring them.

Reasons why it's not a good idea to look for a "10x engineer":

- There is no "10x race horse", as there's different kinds of horses who win different kinds of races (and those horses don't win consistently). Similarly, "10x engineer" would imply there's only one kind of engineer, one kind of engineering, or only one way they can be productive. You can certainly find a "person who is very productive under certain circumstances". "10x engineer" is an extreme oversimplification of a generic person doing a generic job; but people aren't generic, and this job isn't generic. There just is no "10x engineer". It would be the coder equivalent of the Übermensch.

- It's not a good idea to bet the farm on one lone genius. They could get hit by a bus, be hired away somewhere else, or just not be "inspired" by your company or team and end up not producing. Instead build a team of competent and diverse individuals led by a decent leadership/management team who can create consistent results without having to find a magic wizard coder. (Personally, if I found out someone in my org was risking the business on a single person that was impossible to replace, I would be upset)

- There's just not that many super-talented people out there. The few that are, pick where they want to work; you don't hire them, they hire you, so to speak. And even when you think you've met one, it may actually just be bluster or a false reputation.

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

#527
post #490

Earlier quoted context omitted.

A slight addition to this topic. A lot of jobs also became software, even if your intention in signing up for the jobs was different to begin with. PCs were revolutionizing the world. For about a decade I worked as an engineer in a field where the expectation (at least starting) was that metal gets cut, stuff gets built, and there's physical hardware. Those existed. May have actually had more hardware interaction tha…

> decrement on anything involving capital expenditure Boy is this true. I don’t think we ever recovered. Imagine trying to start a capital intensive business like mining in 2025.

Frankly a shame. Since there's a been a lot of development in mining technologies over the years.

Even for the folks that have an ecological focus, there's quite a few methods developed with limited degradation of the landscape, and reclamation of the mining sites into alternative uses (park, forestry, entertainment, tourism). The Wieliczka saltmine in Poland's an especially impressive example [1]

[1] https://www.wieliczka-saltmine.com/individual-tourist/touris...

And these days, there's also a huge number of resources in terms of mineral identification and site mapping. The EMIT Imaging Spectrometer from NASA's a cool example that does remote satelite mineral identification from orbit. [2]

[2] https://earth.jpl.nasa.gov/emit/instrument/overview/

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

#528

Earlier quoted context omitted.

I definitely agree with the greybeards and I think we see the results of not listening to them. We have these processors, buses, networks, and all sorts that are magnitudes faster and more powerful than what they began on but many things are quite slow today. Worse, it seems to but getting slower. There is a lot of value in learning about things like caching and memory management. A lot of monetary value. It's amazin…

As the base reality of computers and the inflated reality of software have diverged more and more, education and culture has tracked the software story and led to runaway irresponsibility. Forget not optimizing for performance; I think a lot of software today straight up fails to actually serve users some way or another. And those are paying users at that!

I agree. There are just too many obvious low hanging fruits. So I'm just trying to inspire people to take action and fix stuff. Ask not for permission, just fix it. Ask for forgiveness later.

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

#529

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…

> The effect of consistent, careful, workmanlike effort over time trumps any number of crunch weeks and burnout episodes, to an almost absurd degree

This is worth remembering for basically anyone who works on anything, or manages any kind of project.

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

#530
post #268

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…

There is something toxic about calling arbitrary things toxic. >The effect of consistent, careful, workmanlike effort over time trumps any number of crunch weeks and burnout episodes, to an almost absurd degree. If you have an actual life, you know, with unexpected stuff coming up from time to time, this is just not possible. Then the only way to get stuff done is go 10x during the time you have whenever you have it.

> Then the only way to get stuff done is go 10x during the time you have whenever you have it.

I believe PP is correct: the cost of "going 10x" is greater than its benefit in the long run, and often in the short run.

Henry Ford lowered the Ford company work week from 48 hours to 40 hours to improve cars manufactured per labor-hour, and to give employees leisure time to drive places (increasing demand for cars). Wages were raised to compensate, further increasing loyalty to the company while enabling employees to buy more cars.

For software, a 40-hour week may not be optimal, I tend to think that it may be too high rather than too low.

Post reply on HN