Live data from Hacker News

High Performance Individuals and Teams

pablasso.com

51–60 of 76 posts

Re: High Performance Individuals and Teams

#51

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

I can't imagine a situation where I couldn't tell the difference between either of them and a bad engineer. I'd either be pair programming with them and learning a lot or be pairing with a "bad engineer" and suffering.

Re: High Performance Individuals and Teams

#52
post #8

"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…

> It's job security and furthermore if it's a valuable piece of the product then it can keep praise and rewards centered on you. That's part of it, but training people is also very difficult. If you know a system well it takes a day to add some feature, but it takes a few days of frustration to train someone else.

If those are actual numbers (a day versus a few days) then that should be an incredibly easy decision. A few extra days is nothing compared to doubling your capacity to deal with problems in that system!

Re: High Performance Individuals and Teams

#53

> 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…

I felt similarly as an IC, but my perspective changed as I shifted into management. I didn’t believe that “negative value” engineers existed when I was working on the front lines alongside other good engineers. In reality, I was seeing the end result of competent management teams who effectively filtered out negative employees in the hiring process or quickly dealt with anyone who became problematic after being hired…

Exactly, to use the framing of "Speed of Trust" by Covey, trust has multiple dimensions, if you only focus on the skills and results dimension you end up with toxic employees with malicious intent or who have a profound lack of integrity and leave a trail of carnage throughout the organization. Whether you need to have a hierarchical managerial system to rectify this is another question, high functioning teams are perfectly capable of making this assessment themselves.

Another underappreciated factor are mental health issues. The chances are high that you will run into people that have undiagnosed ADHD, OCD, Aspergers, autism, bipolar, anti-social disorder in software engineering, or even that you might have a mental health problem yourself without knowing it.

Re: High Performance Individuals and Teams

#54

> 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…

Unfortunately it was only my second or third job, but I’d met a number of people in school for whom it seemed obvious they would not be able to cut it in the real world.

But the line you quoted reminds me of a supposedly apocryphal story involving Dustin Hoffman staying up all night to play a scene where his character is exhausted, and Laurence Olivier asked him, “my dear boy, have you simply tried acting?”

Bad coders have a large blast radius on poorly managed teams. No amount of culling people will make up for a complete lack of leadership skills in the organization. If you are leading, some people will not like where you’re headed and find someplace else to be. Others will rise to the challenge.

My dear boy, have you simply tried managing?

Re: High Performance Individuals and Teams

#55

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.

From my own experience, I can tell you that programmers can even go negative with their productivity.

I've had one employee on my team who ignored my instructions, ported a critical tool to a new execution environment, added 20 additional dependencies, and then pushed the broken mess onto GitHub. After sinking some days into trying to get anything useful out of the source code, we eventuality just deleted it.

Re: High Performance Individuals and Teams

#56
post #16

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

One framing that I found useful (by Covey Jr I think): Capabilities, results, integrity, intent. A bad engineer is so deficient in one or more of those areas that it leads to issues of trust from which a snowball starts to roll downhill. The team will have performance issues or might to start losing people and so on.

A well intended, stand up person who can't code will have a negative impact because their team mates will have to carry their water.

A person with high technical chops who delivers great technical implementations but publicly berates people and has temper issues and throws their team mates under the bus in order to get ahead will also have a negative impact on the performance of the team as a whole.

Re: High Performance Individuals and Teams

#57

"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…

Bus-factors are usually an organizational smell. What I mean by that, even if the individual is doing it on purpose (in order to control people in their gate keeper role or to have heroic tales to tell) the failure is the organizational structure and culture who allows empire building to happen in the first place.

Re: High Performance Individuals and Teams

#58

> 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…

It's a testament to where you work. If you worked in sweatshops firms, who effectively hire anybody who is willing to work without any sort of coding test, there is an amount of developers there who are incapable of developing anything.

If you worked in startups in the valley, there's usually a pretty decent high technical bar to hiring.

Re: High Performance Individuals and Teams

#59

> 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…

I felt similarly as an IC, but my perspective changed as I shifted into management. I didn’t believe that “negative value” engineers existed when I was working on the front lines alongside other good engineers. In reality, I was seeing the end result of competent management teams who effectively filtered out negative employees in the hiring process or quickly dealt with anyone who became problematic after being hired…

I’ve gotten rid of the engineer you describe.

He was technically proficient but lacking in literally every single other ancillary skill for an engineer or a human being.

He could write complex code but it was overengineered and overcomplicated imposing a huge maintenance burden and making it brittle. His whole team was “Wow, he must be so smart!” but when asked on what basis he’d chosen the approach he’d taken instead of the naive solution he got rude and defensive. Nobody else on the team could maintain his code. (It wasn’t bad in isolation, just inappropriate in context.)

Presented with a problem to solve, he would not write something that made sense for the business, designing around requirements that did not match what a reasonable person would assume. When more explicit requirements were included, he complained he was being too restricted.

When presented with a problem to solve, he would not solve it in a way that made sense in the overall technical landscape (I need to serve some absurd number of requests, should I write the most efficient program possible but restrict it to a single instance, or write something less efficient that’s horizontally scalable?).

He was not interested in learning new things. When presented with different technologies, he instead began a solo rewrite of core company systems to ones he was more familiar with because “that’s what I’m more familiar with”. When it was explained that we’d moved away from those systems because of certain problems, he powered ahead with “Yeah, but that’s what I’m more familiar with.” When the foot was finally put down, the answer was “Fine, I’ll use the tech you use but if I have any problems I won’t fix it someone else will have to figure it out.”

He sat idle for weeks because one of our internal company tools was poorly documented that he needed it to do his job (no one thought to document it beyond the inline help because that had been sufficient thus far...). Seeing this tool used daily for two weeks, he did not try it, did not ask his teammates he saw using it, his supervisor, or anyone else for help. He checked the internal wiki and when he failed to find a clear explanation he just... did nothing. Until he got fed up with not knowing what he was doing and scheduled a meeting with the CTO, his supervisor, and ops to walk through every wiki page one-by-one and demonstrate that it was not documented on that page. That meeting was cut very short but probably still easily cost $600.

In every meeting everyone he dealt with walked away with a bad taste because he was rude and interrupted people constantly. He did not bring ideas on technical merit but instead “well I always...”. The biggest thing we emphasize with all our engineers is “data”. Decisions are based on data and documentation, not feelings and opinions. He pushed things through on sheer stubbornness and got upset when he ran up against people that refused to accept that.

His supervisor was not a strong, confident type and within about three days of being hired he’d steamrolled him and started completely overhauling how the team works causing deadlines to be missed as everyone on the team became confused about how to do their job.

And when all of these things were repeatedly discussed with him, explaining what the problem was, why it was a problem, and how we expected an employee to behave... he disagreed there was an issue and carried on as he was.

I did not do the hiring in this case, but I resolved the issue. For that team it was a brief couple week interlude where some guy showed up, wrote some “really smart” code and tried to do some other really smart stuff, then was gone before any of it really got implemented and life went on as usual.

Which is all to say I agree...

Awful engineers don’t have to be technically incompetent, there are a lot more skills involved to being an engineer than just writing code. And if you’re not actively opposed to it, a good manager can smooth over deficiencies in some areas so nobody ever notices.

And if you’ve never worked with an awful engineer, that’s likely a result of a lot of other systems doing their job. If you hired everyone that applied to our company you’d end up with mostly unqualified engineers... and a couple of drywallers. Every improvement past there came from a deliberate action by somebody.

Re: High Performance Individuals and Teams

#60
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. 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…

Honestly I don't know if there's any case where a team of 10 on a project would outperform a (good) engineer or two.

Half of the 10 engineers will do nothing, the other half will have different views of what to develop and will face off one another heading into opposite directions.

Usual development work in a company does not require 10+ workers and couldn't be split over 10 workers even if you had that many.

Post reply on HN