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…
“Normal” engineers are the key to great teams
381–390 of 543 posts
Re: “Normal” engineers are the key to great teams
#382Earlier 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.
Re: “Normal” engineers are the key to great teams
#383Earlier 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…
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
#384Earlier 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…
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
#385They 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
#386Earlier 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…
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
#387I 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…
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
#388I 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…
Re: “Normal” engineers are the key to great teams
#389Earlier 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.
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
#390I 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…