Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High Performance Individuals and Teams

pablasso.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: High Performance Individuals and Teams

#41

Post by TeeMassive »

tjpnz wrote: post #16
usefulcat wrote: post #13

> Even more important than finding great engineers is to avoid bad ones. After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years. My takeaway from this is that at even with ~18 years of experience, my fo…

What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? If it's the former I've perhaps encountered only one in the last ten years. If it's the latter it's almost every month.

> What would you consider a bad engineer?

A bad engineer can have one or more of the following qualities:

* Thinks he's good.

* Think he's so bad that he never speaks out about issues or possible solutions.

* "I've been doing this for X years therefore I'm right"

* "This is X years old and therefore it's wrong"

* Focuses on "delivering", while code quality degrades

* Focuses only on code quality while nothings get delivered

* "Why upgrade and stay up to date? If it ain't broken don't fix it!"

* Makes efforts to appear cool by not being nice and courteous.

* Talks loudly.

* Argue in code reviews

You might think I'm being judgemental, but in my experience this is because the organization who rewards those behavior.

Re: High Performance Individuals and Teams

#42

Post by username90 »

AlchemistCamp wrote: post #19

> Even more important than finding great engineers is to avoid bad ones. I don't know how many Jeff Deans and John Carmacks the OP would turn away in order to avoid a bad engineer on the team, but for me the answer is zero.

If you do hire them but your process can't tell the difference between them and the bad engineer they work with they will get frustrated and quit soon. The most important part to keep good engineers is to ensure they don't have to work alongside bad engineers.

Re: High Performance Individuals and Teams

#43

Post by AmericanChopper »

NhanH wrote: post #18
usefulcat wrote: post #13

> Even more important than finding great engineers is to avoid bad ones. After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years. My takeaway from this is that at even with ~18 years of experience, my fo…

My take away from your comment is that bad engineers are genuinely so rare to meet that false positive from following the advice should heavily outweight any advantage of it.

I think that strongly depends on the environment. I’ve worked in a lot of big corporates, and negative value engineers are exceedingly common there. I’ve also seen them in quite a few early stage startups that don’t have particularly strong technical founders. In those situations the first technical hire will often become the technical leader, and if that person is useless then the technical direction of the company is doomed. Companies like that usually don’t last longer than a couple of years, but there are quite a lot of companies like that.

Startups that have survived long enough to get a product to market, and have a reasonably sized small team, would represent a survivorship bias against having negative value engineers. At which point they will have grow to the point of rotting under the weight of large-corporate inefficiency before any additional negative value engineers would be able to infiltrate their ranks undetected.

Re: High Performance Individuals and Teams

#44

Post by username90 »

BeetleB wrote: post #17
logicslave wrote: post #3

Earlier quoted context omitted.

I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Sometimes the software they produce is absolutely stunning.

> I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Food for thought: The interpretation of a 10x engineer is not consistent. Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes". That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, e…

> Can I replace 10 of my average engineers with this one person?

Yes you can in plenty of situations. 10 mediocre engineers creates a ball of mud and gets bogged down in technical debt. Beating that as a good engineer isn't hard at all. What you can't do however is tell a good engineer to maintain the ball of mud created by your 10 mediocre engineers.

Re: High Performance Individuals and Teams

#45

Post by username90 »

JimDabell wrote: post #22
BeetleB wrote: post #17

Earlier quoted context omitted.

> I feel the same way, anyone who does not believe in the 10x engineer has just never met one. Food for thought: The interpretation of a 10x engineer is not consistent. Putting my manager hat on, I ask: Can I replace 10 of my average engineers with this one person? The answer is never "yes". That's because a team does more than just technical stuff. There's documentation, dealing with customers, bureaucratic stuff, e…

> Can I replace 10 of my average engineers with this one person? The answer is never "yes". That’s because the “10x” is an order of magnitude difference between the best and the worst , not the average. https://www.construx.com/blog/productivity-variations-among-...

Note that the worst doesn't even finish so the difference is infinite. 10x is the difference between the fastest and slowest of those who could complete the project.

Re: High Performance Individuals and Teams

#46

Post by username90 »

fctorial wrote: post #32
troughway wrote: post #2

I’ve been fortunate in my career thus far, since I was about 14 or so, to have always been in the company of at least one “10x”’er on each of my teams, as the cliche goes. They’re dispersed through various companies nowadays - Stripe, Twitch, Google, FB, Discord, etc etc. But it was interesting and beneficial for me to work alongside them if only because I had decent role models to follow. This article first puts up…

Can john carmack build 10 crud apps in a week?

Pretty sure he could if he got to practice writing crud apps for a month beforehand and the apps were no more complicated than what a mediocre engineer can write in a week.

Re: High Performance Individuals and Teams

#47

Post by carlmr »

leftyted wrote: post #14

Whether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist. I know a few in that category. And it really amounts to the same thing.

I think the multipliers also conceal another issue. A lot of programmers have a net negative impact on your code base. They may be "productive" in the sense that they produce a lot of code, but then that code is riddled with bugs that drag down the whole team's velocity.

If you're 10x of a negative impact then you just produce bugs faster.

Re: High Performance Individuals and Teams

#48

Post by leghifla »

epage wrote: post #10
coderintherye wrote: post #4

"If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god." This is hard for many to grasp, but if you get the opportunity to lead enough teams it will become clear. And it makes sense, if you think about it. An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure…

Maybe I've just dealt with good cultures but I find this a bit cynical. Normally when there have been too few people who knew a section of code, it was because: - The area of code has a high ramp up, high risk, and few new work incentivizing ramping up on it. - The curse of knowledge makes it hard for the person familiar with the code to know what is needed for others to understand it. Incentives are needed to encour…

You need incentives for the maintainer helping others to learn. AND you also need incentives for the others to start learning.

I am living right now this situation where I am the maintainer of a large chunk of code, I would like to have at least a second pair of eyes looking on what I do, but the others are all busy with their own tasks and no one learn from the others.

Re: High Performance Individuals and Teams

#49

Post by gnat »

TheDong wrote: post #36
coderintherye wrote: post #4

"If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god." This is hard for many to grasp, but if you get the opportunity to lead enough teams it will become clear. And it makes sense, if you think about it. An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure…

In my experience, the far more likely explanation for a bus-factor for an area of code is not that they want it to be that way, but because the organization has stretched them and other coders thin enough that it's hard to fix that. An organization can get surprisingly far with a huge number of bus-factors, and doing a learning-by-fire session whenever someone burns out and quits. If the engineer who's a bus-factor o…

"An organization can get surprisingly far with a huge number of bus-factors". So much this.

Some managers see high bus factors as a sign of success: "we are a team of specialists: it's so much faster to give a problem to X than to have Y come up to speed on X's code base."

This, of course, sets X up for (invisible?) pressure not to take holidays or get sick. And because problems don't occur evenly across your code base, chances are that one of your devs gets far more bugs to fix than the others. And because the pressure at your org is to go fast, there WILL be bugs to fix. "Testing is too slow", etc.

Re: High Performance Individuals and Teams

#50

Post by kqr »

carlmr wrote: post #47
leftyted wrote: post #14

Whether or not "10x programmers" exist, I can say for sure that 1/10th programmers exist. I know a few in that category. And it really amounts to the same thing.

I think the multipliers also conceal another issue. A lot of programmers have a net negative impact on your code base. They may be "productive" in the sense that they produce a lot of code, but then that code is riddled with bugs that drag down the whole team's velocity. If you're 10x of a negative impact then you just produce bugs faster.

It doesn't take broken code to have a net negative impact. Any code at all is liability, so if you're writing code, it better be worth it. Figuring out what produces value is surprisingly hard, so I would bet the majority of code being written has a net negative impact.

And then don't get me started on marginal profit. Producing some value is a lot easier than producing marginal value that outweighs marginal costs. Now we're talking a smallish fraction of the code being written.

Post reply on HN