Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

51–60 of 543 posts

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

#51

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 folder holding source code called all over the code base and the near impossibility of moving it in a location that makes sense for it without having to refactor the whole code base.

People, including myself, have a seriously bad intuition just how much volume there is in a space which grows at least exponentially.

The closest discipline to software engineering is mathematics and that has an even worse track record. There's the folklore about half of all math papers giving the wrong proof for the right conclusion. By comparison software engineering only gets catastrophic bugs less than every other time a program is run.

[0] All trees are natively embedded in some hyperbolic space of whatever curvature matches the average number of children per node, and all code can be ultimately represented as a tree.

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

#52
post #9

"Measuring productivity is fraught and imperfect" For the moment, but it's better than it's ever been, and it's getting better.

Not really. How do you quantify tech debt? How do you quantify the tradeoffs that someone made to add new functionality? This is always going to have a critical subjective element to it. The moment you start treating engineers like factory floor workers, that's what you get.

>Not really. How do you quantify tech debt? How do you quantify the tradeoffs that someone made to add new functionality?

Time is quantifiable and comparable. Time spent on making things happen and then dealing with the consequences. The percentage of people leaving the organization in their first year is quantifiable.

Tech debt and tradeoffs from the previous feature will show up either as time spent on adding the next one or time spent on fixing bugs. Estimating is difficult, but measuring and figuring out post factum what amount of time was spent on yak shaving isn't exactly impossible. It maybe be uncomfortable and self incriminating, but that's a culture problem.

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

#53
post #29

An average engineer with solid problem-solving skills and a good manager is like a ~3x engineer. It's way easier to hire a few of those than a 10x engineer. But you need to match them up with a good manager, and that isn't easy.

When people say "average" they're trying to reach for a concept of 1x engineer, not 3x engineer.

When I think of a 1x engineer, I think of all the guys I've worked with that had a decade plus of experience but were advanced beginners at best. If you don't work for a FAANG company, you will be surrounded by those types. They make the same mistakes over and over and write the same unreadable code, year after year.

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

#54
As a manager, you want a report who does not require handholding, cajoling, or close supervision. You want someone who makes problems disappear. It's fine if they're 1x engineer. It's fine if they pick up their shit at 5PM no matter what and leave for dinner. Just do what you're supposed to do, at a predictable cadence. That's all that's really required in 90% of the teams.

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

#55

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…

I was once considered a 10X. I would work all night. Rewrite code simply because I found it objectionable - lots of things I'd never do now. Mostly after working those long hours I return after a long rest and spend most of my time fixing all the new and ridiculous problems I created while working tired. Things may have gotten done a little faster. Never once did it even matter - there was no material benefit to the…

> Never once did it even matter - there was no material benefit to the company.

I think that the idea of having people (at startups) working at a frenetic pace is because

1. The VC money is running low 2. Being first to market used to be a major determining factor on whether the product would succeed or fail

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

#56

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…

I was once considered a 10X. I would work all night. Rewrite code simply because I found it objectionable - lots of things I'd never do now. Mostly after working those long hours I return after a long rest and spend most of my time fixing all the new and ridiculous problems I created while working tired. Things may have gotten done a little faster. Never once did it even matter - there was no material benefit to the…

So you 10x'd in wrong direction. Doesn't mean something else can't 10x in the right direction.

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

#57

Earlier quoted context omitted.

> completely obsessed with the project, like it’s their main hobby/purpose I think you figured it out.

If your main hobby or purpose is to make someone else rich you're a slave.

I worked like this. You could have phrased it better.

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

#58

Earlier quoted context omitted.

> completely obsessed with the project, like it’s their main hobby/purpose I think you figured it out.

If your main hobby or purpose is to make someone else rich you're a slave.

That honestly doesn't matter if you (no longer) pursue riches yourself, have enough already and enjoy your hobbies. Besides, not everyone working in IT is working in a chique billionarie mill. A lot of IT is just plumbing. Majority even.

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

#59
post #50
post #36

> 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers If you think a great (10x) engineer has bad social skills, isn’t a good mentor, and isn’t a strong teammate… you’ve never actually worked with one. What truly makes someone a great engineer is being technically impeccable and having next-level soft skills.

Exactly. While 10x (or whatever) is possible on pure technical ability, I would argue that the majority of engineers who provide outsized value do so through enabling others to do their best work and unblocking the wave that raises all the boats, rather than coding by themselves in a dark room.

Exactly. The way a 10x engineer really 10x’s is by leveling up the entire team.

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

#60
post #36

> 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers If you think a great (10x) engineer has bad social skills, isn’t a good mentor, and isn’t a strong teammate… you’ve never actually worked with one. What truly makes someone a great engineer is being technically impeccable and having next-level soft skills.

Not sure if this was your intention, but you’ve pulled these words out of context, making it seem like the author is making this claim, when in fact the author writes that to describe what others claim.

> Most of us have encountered a few software engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to nonobvious yet elegant solutions, or emit waves of high-quality code at unreal velocity.

> I have run into many of these incredible beings over the course of my career. I think their existence is what explains the curious durability of the notion of a “10x engineer,” someone who is 10 times as productive or skilled as their peers. The idea—which has become a meme—is based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (for example, 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers) or blatantly double down on stereotypes (“we look for young dudes in hoodies who remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true.

> I don’t have a problem with the idea that there are engineers who are 10 times as productive as other engineers. The problems I do have are twofold….

Post reply on HN