Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

361–370 of 543 posts

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

#361
Having worked in "traditional engineering" and software dev / tech, I've always found it fascinating how much tech people obsess over the 10x engineer, and how polarized their view is - there's certainly a strong polarized view that you're either a 10x engineer that's carrying the whole product, or a mediocre (to poor) engineer that's holding back the rest - seemingly nothing between.

Hell, even by engineering standards, tech has a lot more extremely opinionated people - with more extreme views on pretty much everything. I've always wondered why it is like that.

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

#362

Earlier quoted context omitted.

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…

> I would work all night. This is not a 10X programmer. A 10X programmer delivers the same amount of functionality in 1/10 the time. For me the first 10x programmer that comes to mind is Peter Norvig. This spell checker he wrote in a single flight remains a work of art: https://norvig.com/spell-correct.html Very few programmers would come up with something so concise and elegant yet powerful in such a short amount of…

Egads, that spell checker is absolutely beautiful.

I guess it’s worth pointing out that he does support one of the arguments the article makes:

> But they didn't, and come to think of it, why should they know about something so far outisde their specialty?

So yeah, he’s implicitly saying, “I have a lot of domain knowledge here.”

But that said: wow, that code is so concise and elegant, it gives me tingles. If anyone IS a 10x engineer, it’d surely have to be Norvig.

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

#363

Earlier quoted context omitted.

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…

> I would work all night. This is not a 10X programmer. A 10X programmer delivers the same amount of functionality in 1/10 the time. For me the first 10x programmer that comes to mind is Peter Norvig. This spell checker he wrote in a single flight remains a work of art: https://norvig.com/spell-correct.html Very few programmers would come up with something so concise and elegant yet powerful in such a short amount of…

Tbh this seems to be implementing a demo of something he had complete understanding of prior.

Yeah, he was at Google at the time (https://norvig.com/resume.html) so he was probably involved in the original development of the thing he was making a demo of.

He's definitely smarter than me with that CV but this particular project doesn't seem like some insane productivity achievement.

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

#364

Do people really question the existence of "10x engineers". It follows from Pareto distribution that some people are just exceptionally productive. That doesn't mean that its good or beneficial (depending on what the scope is). That also doesn't mean that its good to only have them, because they often carry their own baggage.

It is worth noting that the original 10x was a reference to the best engineer being 10x more productive than the worst engineer. Not 10x more productive than the average engineer, no the median engineer.

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

#365
I have had many colleagues who produce more code and functionality at a constant rate than me. But I have also had that the experience that some of those colleagues were trying to reproduce a certain customer bug for weeks and not being able to reproduce it and that when I finally decided to also have a look at the code, within half a day found the bug and a two click way to reproduce it. When I told them about this two click way to reproduce it, they at first did not believe me that it was that simple to reproduce it. They had so see it several times with their own eyes before they believed it.

I also have had the experience that some colleagues had worked on optimizing an algorithm for months and months. I too had looked at the algorithm and one day, almost out of the blue, I came up with a short cut that totally avoided said algorithm and implemented the required functionality with some calls to a function in standard library we were already using. Again, I was met with disbelieve when I presented the solution.

I feel that I am the guy who about once per year comes up with an idea that no one else had thought about and that most of the time I am just not very productive and often find myself daydreaming and not being very productive.

I also feel that often I am far ahead of other with respect to ideas and that I fail to convince others about a my '(too) advanced' approach. I several times have been in the situation that I proposed a solution to a problem and that some kind of manager decided to go for a simpler solution and that after months of develop time, it came to be that certain functionality did not work and that it was simply decided that that functionality was not going to be supported anymore.

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

#366
post #291

Earlier quoted context omitted.

Not op, but I'm clearly reading their message differently than you. Any type of physical engineering is based on hard facts, data, and well established historical research, mathematics, and more. I've seen many an electrical engineer say, "fuck it, this is too hard and pays too little" and so they pivoted into software engineering quite easily. On the other hand I've never seen the opposite. Real engineering is hard…

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…

I graduated in Electrical Engineering but have worked as a Software Engineer for the last 20 years.

I totally agree with their post and get what they're saying.

Within circuits (big or small) it is possible to do some crazy stupid shit, but reality kicks in much sooner. Either because of physics or price.

Analog circuits (my specialty) are a perfect example of this. Sure I can try to cut corners and interconnect two distant parts of the circuit together in weird ways ("tight coupling" in software), but the options I will reach for are limited, and "nature" forces me to "decouple" them. With software I can just set a distant variable...

I have a Building Engineer on my team, who also moved to Software Engineering. I can ask for examples in his field too.

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

#367

I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…

As a 10x engineer, hard disagree. The modern stack is just too large. Sure, building out an MVP can be done by one 10x engineer, because basically any prototype can be built by a single engineer. But making the UX aesthetically beautiful, adding a test suite (at least for automatic dependency updating), adding observability and alerting, performance optimization, persistence optimization, cost/deployment optimization, day-to-day maintenance automations, architecture and network diagrams, tutorial/how-to/explanation/reference documentation.... you are delusional if you think that can all be delivered, at consistently high quality, by a single engineer.

You can have a single genuinely senior 10x engineer oversee all those efforts, executed by "normal" engineers. But no, not execute them all by the 10x engineer's self.

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

#368
There definitely are 10x engineers and they're invaluable, but they're not (necessarily) those who write 10x more good code, but those who understand the requirements and write the right code. And directs others to write the right code.

Most time is wasted when you throw away and rewrite what you did.

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

#369

One more empty reaction epiphany rambling of another random-god-knows-who.

I'm seeing more reactions like this. I wonder if it's a consequence of reading AI generated drivel and not being able to tell content apart. Or perhaps people is asking for more action and less reaction. I don't know.

My reaction is due to influx of empty shower thoughts about generalizing large swaths of people and putting them into “normal”, “10x” or whatever bullshit author wants to identify themselves with. For some reason those articles attract a lot of discussion online, but thankfully they don’t leak into real life.

I find them very counterproductive, because instead of discussing actual issues and problems, people spend time justifying by all means that they’re in the “right camp”. Go outside, touch grass and actually talk to people you work in your org. Though I suspect most of those are written by ”influencers”(barf) that easier never worked with real people or don’t work anymore and want to sell their snake oil as ultimate truth.

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

#370
post #288

Earlier quoted context omitted.

Yes, exactly this. I never bought into TDD, but I can understand that it brings comfort for many normie enterprise CRUD developers... of which I am one myself!

I despise it because I've seen some absolutely HORRIBLE designs that excessively separate concerns (that are actually linked and shouldn't be) in the name of "testability". I would rather maintain 50 lines of clear idiomatic code than 1000 lines of TDD code salad full of 3 line functions that each take a bunch of fragile mocks. It's also my experience that a few well written integration tests are more useful and catc…

> excessively separate concerns (that are actually linked and shouldn't be)

you mean concerns that should be seperated but they did it in a wrong way?

Post reply on HN