Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

Post reply on HN
Print view View original

401–410 of 543 posts

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

#401

Post by magicmicah85 »

I appreciate the overall point of the article, but have a gripe. The author (and others) gets it wrong on the original meaning of 10x. A 10x engineer isn't someone who is 10x as productive as their peers, they are 10x as productive as their worst performing peer. The original study the author links to compares the difference of work between the fastest code and the slowest code. The fast debugger and the slow debugger.

When we talk about 10X, it should be about comparing it to the least productive team member - the 1X. There is always going to be a 1X person on the team. That's not bad if the team average is 1.5-2X, but if the average and discrepancy gets large enough, you're going to have the 10-100X team member who gets a lot done.

Also, not all work is equal. The 10X engineer who is only 10X in programming may be a 1X in collaboration or documentation. That's not a good dynamic, either. Again, appreciate the point of the article, "build great teams", but we need the 10X person in each task to do that. If the build pipeline is slow and costing us money, I need the best people on the team to go figure that out. And, I need our worst engineer who is still learning to be involved so that they can grow their skills. Become a 1.1x, 1.2x, etc.

Hat tip to these articles on 10x engineer studies: https://jasoncrawford.org/10x-engineers https://www.construx.com/blog/productivity-variations-among-...

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

#402

Post by deadfoxygrandpa »

noosphr wrote: post #51
jaggederest wrote: post #5

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…

Software is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral fo…

actually, if you really think about it, my source code is only laid out in 2 dimensions. thats even fewer than mechanical engineers have to work with!

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

#403

Post by whatnow37373 »

grandempire wrote: post #141
NalNezumi wrote: post #140

Earlier quoted context omitted.

so in every key project you've worked on, a one single person took care of the coding from DevOps to frontend/backend, deployment, testing, and all other coding required beyond "key functionality"? I think it says more about the size of the project and the complexity of the task that you've worked on, rather than "10x engineer vs normal engineer". Not even at a 10 person startup have I seen "one" person done everythi…

> one single person took care of the coding from DevOps to frontend/backend, deployment, testing, and all other coding required beyond "key functionality"? I didn’t say that. Read it again. It’s not even the same person every time, people trade off being that key person. > I think it says more about the size of the project and the complexity of the task You have no idea. Please address the ideas rather than making pe…

Humans tend to have pyramidal power structures, because of [reasons]. I don't see how this relates to the topic?

> It’s not even the same person every time, people trade off being that key person.

So it's the role that delivers software? I think I agree with that. Even so, that role cannot function without its support system (the team).

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

#404

Post by matthewmacleod »

Dracophoenix wrote: post #314
gilbetron wrote: post #192

Earlier quoted context omitted.

In my 40 years of professional software development, rarely have I seen such an uninformed post. And ignorant. Did I mention ignorant? I've been the "10x" developer, multiple times. And there certainly are poor performers and exceptional performers, but great teams makes great software, not great individuals. The analogies are numerous. You can look at a great (american) football team and see the Quarterback as the 1…

> but great teams makes great software, not great individuals. For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals a…

This example proves the exact opposite of the point you intended to make.

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

#405

Post by vacuity »

bigtunacan wrote: post #299
callc wrote: post #291

Earlier quoted context omitted.

How are you reading noosphr’s comments? I read it as: “software is special because its design space is high dimensional, compared to all other engineering disciplines which are limited to 3 spatial dimensions. Large design space leads to ability to mess things up.” I wholeheartedly agree with you: “real” engineering (where lives are on the line) is hard . Most software that is made is not to control pace makers, air…

Software "design space is high dimensional" is true in that storage, latencies, processors, memory we just keep growing and growing. Given that, software should be faster and better than ever because the dimension where software lives has gotten exponentially larger and more performant. Rather than use that like responsible engineers we all started writing bloatware because it was easy and we could get away with it.…

The power of software is not tied to processing power or memory, although those help a lot. Code is the deciding factor, not quite because it can be laid out wherever and have far reaching effects, but for the underlying basis for code. Software is all about leaky abstractions. It's not quite math or any sort of empirical engineering. Software models entire worlds. Excel is "just" people churning out calculations from paper spreadsheets, except now you just see the results on a screen. Pong is a ping-pong game. But I used the word "leaky" before. "All models are wrong, but some are useful."

We could always talk about stacks, AVL trees, or NLP before any meaningful conception of computers, and indeed a lot of computer science research happened when computers were still fairly primitive. Computer science and its applied form, software engineering, are about computation (data and code) and abstraction. Even computation is just a distraction at some level. There's some world with the ideal behavior that a program should abstract from, but an ideal is an ideal, so programming is often floundering to figure out what ad-hoc world the program mirrors and tweaking haphazardly. Software engineering isn't engineering not because it can't be, due to the (very real) differences of software from the physical world. It isn't engineering currently because we aren't taking control of our actions and their consequences, in all senses.

Intellectual superiority is not relevant here. Everyone has hard tasks. If you're a civil engineer, then design and build infrastructure well. If you're a programmer, then design and build programs well. Any discipline demands honesty and forthrightness in evaluating its work.

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

#406

Post by breadwinner »

The flaw in this article is the assumption that 10x engineers are just more productive, and several "normal engineers" can do the work of a 10x engineer. This may be true if you're building "normal software".

But for certain kinds of software development, a team of "normal engineers" can't do what a single 10x engineer can do. For example, how many "normal engineers" would you need to replace an Ilya Sutskever? The answer is you can't. Because intelligence is not stackable.

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

#407

Post by earthnail »

dinobones wrote: post #394
earthnail wrote: post #392

The thing that bugs me with this article is that a lot of regular software engineering is plagued by a lack of ambition. 10x engineers bring that ambition (I hate the term 10x, but let's just stick with it). Because of the scaling effects in software, if you work on the right project, that ambition can significantly increase your impact on the market/world/field you're working in. The costs associated to managing tea…

Yeah maybe if my employer has the ambition to pay. Am I working hard at Meta? You bet I am. For median SWE salary and 0.001% in “options” that will likely never have a liquidity opportunity? I’m not so sure…

Agree with that, but for employers to understand that it’s worth paying it’s necessary to understand that you would actually get more value in return as an employer than the extra you have to spend on a great engineer.

Again, depends on whether your product has that much upside. Many products don’t. But as an example: German car makers have long ignored that great software engineers have a vastly bigger impact in a team than great mechanical engineers. As a result, they for a long time failed to build great software engineering orgs.

Volkswagen gave in eventually and is now licensing from Rivian. Their failure was caused by a structural problem of not seeing how SW works at scale, and how that should influence your hiring.

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

#408

Post by mmcromp »

magicmicah85 wrote: post #401

I appreciate the overall point of the article, but have a gripe. The author (and others) gets it wrong on the original meaning of 10x. A 10x engineer isn't someone who is 10x as productive as their peers, they are 10x as productive as their worst performing peer. The original study the author links to compares the difference of work between the fastest code and the slowest code. The fast debugger and the slow debugge…

Who cares if the term "10X dev" was derived from a misunderstanding of actual studies (that may or may not be legitimate), the term itself is very clearly about superhuman rock stars.

If you want to move the discussion of 10X devs away from the 10X dev then stop using the term "10X dev".

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

#409

Post by nashashmi »

This article adds to the conversation of the 10x engineer. They are only 10x because 1x engineers exist.

They are only proud 10x because their narcissistic self looks proudly at 1x engineer in smudge fashion that they are better than someone else.

They are 10x because the system is stable enough and beautiful enough to allow for them to be 10x, and also allow for the 1x engineers to be good enough.

So lets champion the system and the normal engineers out there.

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

#410

Post by jghn »

swatcoder wrote: post #147
ambicapter wrote: post #111

Earlier quoted context omitted.

I don't think it "attracted" a certain kind of people, I think the people who were already in tech just became more wealthy and powerful, and that, predictably, brought out the worst in some. The worst qualities of "tech" people can be conflated but I think have a different flavor than the worst qualities of "finance" people. It's really just the same obnoxious behavior you can spot in young tech people. Some people…

No, the field grew tremendously and you can see a clear generational bias -- by years of experience, not age -- where the cohort from the last 10-15 years has a completely different understanding of what the craft is [software engineering vs business development] and how to approach it [optimal solution vs soonest deliverable]. You can also trace personal backgrounds and you'll see a much higher representation in the…

You're not wrong but this is overly reductive. In other words this is more of a sliding scale and not a step function centered on 10-15 years ago.

For instance I was a CS undergrad in the mid/late-90s. There was an enormous difference demographically between my incoming freshman class and the incoming freshman class by the time I graduated. And the talking points were exactly the same ones we see in this thread.

Post reply on HN