Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

381–390 of 543 posts

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

#381

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…

About 15000 engineers have contributed to the Linux kernel. You should be more mindful of how facts line up with your feelings.

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

#382
post #298
post #151

Earlier quoted context omitted.

Speaking as an old school basement nerd (coding since middle school, 90’s): If I can do cool things with code _and_ get paid, I’m gonna go do that. Business constraints make it feel much more interesting than writing code in a vacuum. Also money is nice.

> Business constraints make it feel much more interesting than writing code in a vacuum. You never write code in a vacuum do you? You always have some kind of goal.

I should hope not. Even if your body could withstand the low pressure, you'd suffocate very quickly.

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

#383

Earlier quoted context omitted.

Have you ever worked on large projects? I'm talking about projects which involve hundreds of people, thousands even, and those that stretch over many years. In the grand scheme of things, the 10x-100x engineers work gets attenuated - think of it as some kind of averaging filter. Do you think some 10x engineer carried the moon landing? or the Large Hadron Collider? Sure, if you work on some dinky team single-digit num…

10x is not about the number of lines produced. It is about programming languages and tools, about database design/schemas. Choose the wrong language/tool for the job and the amount of work needed to solve the job easily expands 10x. Guido van Rossum and James Gosling and Anders Hejlsberg likely have reduced the amount of work by 10x for a lot of projects compared to implementing them in a lower level programming lang…

10x is not literal - the origins is from the 60s, and stem from some study where the best engineer was found to be 10x more productive than the worst engineer.

Average, is of course relative to the sample. If some "elite" company only hires 10x engineers, there's likely not going to be any 10x engineers there. The most productive engineer will probably only be slightly more productive than the worst.

If some other company has zero standards for hiring, to a degree where you can basically pick anyone off the streets and put them to code, the best will probably Nx (where N is very large) more productive than the worst.

But even then, there are so many dimensions and aspects to this.

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

#384
post #257

Earlier quoted context omitted.

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…

This is what happens anytime a field gets large in terms of job applications. Replace software engineer with anything else to that measure and you see the same things with wealthy families being overrepresented in the cohort because they always have an edge in getting the best credentials due to not having to work any part time jobs and having mom and dad (or even a paid advisor) actively working on your behalf to ve…

I doubt that has anything to do with getting "large in terms of job applications" alone. It's a correlation, alright, because wealthy families have it easier to get high-status and high-paying jobs for their kids, and if such a field grows, wealthy people flock to it like everyone else. But I sincerely doubt you'll find the wealthy over-represented in physical labor / blue collar jobs, regardless of how the ups and downs in the labor market for those occupations.

The way I see it, it's like 'swatcoder and 'lovich said upthread: the field became a money printer, and attracted - not revealed, attracted - a different kind of people, with a different mindset. I too saw this change happening. Applicant pool size? That's a spurious correlation - it's just driven by the same factors that make software industry a money printer.

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

#385
The closest to "10x" engineer that I knew wasn't necessarily the best or fastest programmer but he would see what we needed before we needed it and already have it done. A manager would say we will need something to which they would reply they've already done it.

They would read the play like Gretzky to know where they had to be ahead of time.

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

#386

Earlier quoted context omitted.

"There exist exceptions to a trend" does not mean the trend is not a valid proxy (see [1]), and "refuses to do fizzbuzz" is different from " can't do fizzbuzz". I run a technical recruiting company, and we ask candidates a question like [2] on our interview (EDIT: we ask other stuff too, this is only part of it). It's not exactly fizzbuzz, but it's really not far beyond it. A candidate we interviewed just a couple da…

Fine with you for your tech candidate question, if that works for you. Maybe I never encountered your perspective; in 20 years in the industry, in about 10 significant software prod/consulting companies, we never outsourced hiring or pre-hiring. From my experience and perception, minor coding tests are a hiring filter than does not gives good results, for both sides of the interview. You want to hire junior candidate…

> You want to hire experienced (or even senior) candidates and filter for domain knowledge? 1. Filter on experience & referrals. 2. Conversations: same approach as with the juniors, but much deeper and wider, relevant to your domain. 3. Call at least one reference to counter-check.

The reason I don't believe in (1) is that the candidate I described in my previous post claims nearly fifteen years of experience, some of it as a lead, and completely bombed our entire interview. Referrals are another matter (and they are indeed an excellent channel when you can get them), but they tend to be pretty low-volume - if you're hiring from the general public at all, presumably referrals didn't get you what you wanted.

By the same token, the majority of people we've placed so far were people whose resumes didn't particularly shine - but who turned out to be very good engineers when given an opportunity to actually work on a problem. (That isn't just my opinion, it's the opinions of the companies that hired them.)

For (2), I agree. We do do that as well (coding's one of three parts of our interview, not the whole thing).

For (3), have you ever had a reference give a negative review? A lot of companies make it outright policy to do so, and iirc there are legal restrictions on employers doing so in a lot of places. I wouldn't trust that with any reliability (although it's still good practice 'cause it's cheap).

> I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.

Of course soft-skills matter! I never meant to imply otherwise. But soft skills will only get you so far if you don't know how to do the fundamental responsibilities of your job.

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

#387

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…

If you work twice as long as most, make code which is dubious/broken, take initiative out of sheer personal opinions and have to spend time the next day fixing your mess, that would be the definition of a 0.25X programmer.

It took you 4 times as long to bring value to the company, you had lot of enthusiasm but were not using it right.

Being a kX (k > 1) means that you need to work fewer hours to accomplish the same amount as an average developer. If you then got to spend more time to fix your stuff, that counts against your time budget.

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

#388

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…

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…

[deleted]

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

#389

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.

So only if you're hating your job then you are a bastion of free will and free thinking among us mortal capitalist slaves?

What about truly enjoying your job and getting paid handsomely for it (compared to almost all other jobs) being sufficient to one's happiness?

Also, if you don't realise that being the one running the show is orders of magnitude harder than following the lead and doing your stuff then you never really done it before. Having ALL the control has advantages and many less obvious disadvantages.

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

#390
post #237

I feel like this article completely misunderstands the point. Their two big arguments are that 1) people aren't 10X at everything, they are at most 10X at specific things and 2) what good is a 10X engineer if they are on a team that can't perform at that level? There isn't something magical about 10X engineers, but the fact is there are engineers who have developed the skills to greatly exceed their peers and work in…

The orchestra analogy is actually pretty good. An orchestra with a few great instrumentalists will perform so much better than one without them, even if most instrumentalists are very mediocre. Anyone who's ever played in an orchestra will know that experience.
Post reply on HN