Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

371–380 of 543 posts

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

#371

There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who understand what they are doing. And then... the 100xers like Linus. It's pyramid-shaped. If the author is referring to people who understand what they are doing as "normal" engineers, granted, you can make a great team out of these... but how do you find many of them…

Not of that opinion. I met great engineers or developers who won't even care to answer a fizzbuzz-type question. I met terrible ones who had top technical and math capabilities but little agency at pointing what is relevant or not in their work. Even considering it's pyramid-shaped is excluding all the externalities that make one person thrive in some contexts, and just flat or negative in others. Take a top performe…

"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 days ago took that problem and couldn't even complete the first step. This is the equivalent of asking someone applying for a job as a statistician what the distribution of the sum of two normals is, or asking someone applying for a job as a con-law lawyer what the fifth amendment is, and having them go totally blank.

Is it conceivable that they were just having a rough day and their brain hiccuped really badly? Sure, I suppose. If we did ten thousand interviews, we'd probably have at least one person who is objectively great perform that way.

But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.

-----

[1] https://news.ycombinator.com/item?id=43006330 [2] https://www.otherbranch.com/shared/practice-coding-problem

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

#372
post #275

Earlier quoted context omitted.

>As a leader and teacher with more grey hair every day, I feel this responsibility You should probably do less of that since: 1). That's not what any of my posts said. 2). My degree says mathematical physics and not computer science or software engineering. 3). A field where you're tone policed by the tone deaf is the opposite of welcoming and inclusive.

Since I’m already in the thread defending you against the other poster, I’ll add here U/callc appears to be reacting to the public perception of how this thread would read externally, you appear to be reacting based on hard logic, which is unpalatable to most of the public. I think you two are talking past each other

> I think you two are talking past each other

This is why steelmanning a comment before arguing against it should be a rule.

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

#373

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…

Your post is super offsensive. And true. The number of times I've reviewed someone's code that's been "in progress" for 3 weeks, to see it's 200 lines of simple python code... ugh " oh, but it was really actually complex and you just don't get it " --> Incorrect

Or maybe they aren't pushing flaky shit into prod and actually thinking about their work. Maybe they did 1k lines (counting lines LOL!) of code reviews, fixed some bugs, helped on an outage etc. Fuck. This one dimensional view of things. Look how any company makes money. Let's say Google. It is not by the number of lines of code.

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

#374

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…

>Nothing that we do is so unique that another competent engineer shouldn't be able to fill in for you when you are having an off day.

There is a big difference between filling in someone on an off day, and actually taking over their job. It's only felt over weeks and months.

"Consistent, careful, workmanlike": this does not describe the kind of software built by most teams, but it does describe the work of good individuals.

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

#375

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 think one thing that is very different about software engineering is that it's the only form of engineering I'm aware of where a very substantial fraction of the people employed to do it lack basic fundamentals like "being able to do it". Most software engineers can't write a program without google. They can't remember basic facts about the language they use every day. They don't have a sense of what makes sense an…

>Most software engineers can't write a program without google. They can't remember basic facts about the language they use every day.

How many years of experience do you have? and how many languages have you written code in? Include all languages where you tweaked or wrote even a single line of code.

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

#376

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 was once considered a 10X. I would work all night. You are part of the toxic culture until you realized that was that it is overall counterproductive. Collectively we software developers are to blame and no one else.

Not just toxic, he's simply wrong. A 10X is someone who supposedly completes 10 hours' worth of work in one hour. If anything he was a -10X lol...

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

#377

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…

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 language.

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

#378

Earlier quoted context omitted.

Not of that opinion. I met great engineers or developers who won't even care to answer a fizzbuzz-type question. I met terrible ones who had top technical and math capabilities but little agency at pointing what is relevant or not in their work. Even considering it's pyramid-shaped is excluding all the externalities that make one person thrive in some contexts, and just flat or negative in others. Take a top performe…

"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 candidates? that test is fun and maybe ok an indicator. Having them live comment/describe/solve existing pieces of code is much more effective and fast. They will still demonstrate ability once on the job, that's what juniors are for.

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.

A generic fizzbuzz/minesweeper (remember also "code a functional basic blog engine with comments in 30min" back in 2006) coding test demonstrates (in my very subjective and limited opinion) laziness and kind of a lack of interest in the candidate from the hiring person/company.

I understand that when you screen 1000s of people, it gets massive and more basic filters may apply, at least at first contact, though.

> But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.

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.

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

#379

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…

> 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

3. There's always that one person whose only ability to contribute is to cheerlead the others... and some nerdy types take a long time to figure out you don't need to listen to them or tie your fate to them.

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

#380
IMO the problem isn't 10x engineers. The problem is that the workplace is flooded with 0.1x "engineers" that we have to tiptoe around. These people can barely implement Fizzbuzz, and if we write any code that they find complicated then we're not "team players". Well guess what, if we want to be ahead of the competition then we sometimes have to use quicksort instead of bubble sort and if you hire people who don't get that then you're part of the problem.
Post reply on HN