5 ms·

> 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

> 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 former self would probably not have appreciated the importance of this advice, as I had rarely or never encountered such a person thus far.

tjpnz 6y ago
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.
- jachee 6y ago
  Considering the Dunning-Krueger effect, my Imposter Syndrome is sure that I must either be a bad engineer, and that it's just a matter of time before I mess up in a situation because I incorrectly evaluate my skill level at evaluating my skill level... etc. or that I'm a decent engineer. I've been trying to avoid that meta-evaluation spiral for years by semi-regularly checking with third parties to confirm that I'm generally the person I believe I am. So far, so good. Edit: Almost forgot: The whole point of this introspection is to point out that the self both is and isn't a decent guidepost for evaluating others.
- usefulcat 6y ago
  > What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? Those categories aren't necessarily disjoint. There can be many aspects, many of which are described in the paper. But in my experience, one of the more pernicious combinations is the sincere belief that one already knows nearly everything worth knowing, coupled with a complete lack of curiosity (or perhaps it was merely utter laziness). When that happens, a person stagnates. In the case I saw, a person with decades of experience was effectively performing only marginally better than someone who had just begun their career. The major difference being that a person who has just started is often well aware that they have a lot to learn. Or even if they're not, if they're curious then there's at least a good chance that they will figure that out in time.
- greggman3 6y ago
  I have met plenty of bad engineers so maybe it's just luck. Engineers that can't write simple code and always over engineer. Engineers that have no concept of encapsulation and use globals all over the place. Engineers that have no concept of perf. Engineers that can't ship and noodle the same piece of code for weeks that others would have finished and moved on in a 1/10th the time. Engineers that are all talk no work. That last type sticks out where the engineer would basically walk around and stop at people's desks and talk their ears off but never actually finish any code. People complained. The boss said "they have a family so I don't want to fire them". I don't know how to answer that.
  - Viliam1234 6y ago
    I wonder what would happen if you also started walking around and stopped finishing code. Would the boss keep you too, or would you get fired despite having a family?
- TeeMassive 6y ago
  > 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.
- kitsune_ 6y ago
  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.
NhanH 6y ago
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.
- AmericanChopper 6y ago
  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.
  - cutemonster 6y ago
    > 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. It'd be interesting if there was somewhere to read about such companies. Maybe they don't realize themselves -- if the founders aren't technical enough to realize that the technical leader is the very wrong person They might never realize why things didn't go their way, and blame other things instead
- cutemonster 6y ago
  > false positive from following the advice Is that accidentally not hiring someone who would have been a good fit?
PragmaticPulp 6y ago
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. Being a negative value engineer isn’t just about writing bad code or being incompetent. Those things are trivially obvious in any technical interview. The reality is that negative value usually comes from behavioral issues. Engineers who are constantly sowing discord against the company or management can bring down entire teams. Engineers who create conflict and destroy morale are toxic for productivity and will drive away your best team members. Engineers who can’t ever ship anything on time because they can’t manage their own time or they have pathological perfectionist tendencies will sink your schedules. Ironically, negative value can often come from those with great technical chops who are unfortunately mired in personal issues. Managers can compensate to some degree with intense attention and guidance for those individuals, but at what cost? Obviously managers should make an attempt to correct behavioral problems that are dragging the team down, but at some point you need to do the inevitable and replace the problematic employee with someone who can perform without the behavioral issues. It’s not just a question of whether or not someone can write good code. It’s a question of whether or not the team and company are best served by keeping a troubled employee as opposed to reallocating that finite headcount to a new candidate.
- kitsune_ 6y ago
  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.
hinkley 6y ago
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?
user5994461 6y ago
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.
eyelidlessness 6y ago
I was probably 6-7 years into my career before I encountered such a person. It was my first formally titled “software” role, having spent the years prior making software and calling it “websites”, for a mostly brochureware design firm. I had terrible impostor syndrome. But I recognized that a member of my team was simply not up to the task. And was very well liked by the team, so no one had spoken up. But I was gaining responsibility, including (informal at the time) leadership of this individual. And it was a liability to the team, and to me, and ultimately to the person in question. So I spoke up. I felt terrible about it, I feared alienating everyone, and I feared I was putting the person in financial and career risk. But I didn’t see a way to bring them up to even a standard where their presence wouldn’t be a net negative, and I knew I wasn’t up to the challenge of carrying that weight. So I did what was best for the team. The person was ultimately let go. And they did ultimately find a role that was better suited to them. So all is well. In hindsight I don’t think I should have been so torn up about it. It actually sucks to be in over your head, knowing it or not, and it’s possible finding a more fitting role is a better place for growth into more challenging roles. I’m not sure how to conclude this, I’m not sure if there’s even any value sharing it. But I guess for anyone reading who finds themselves in my position (newish, relatively ascendant, full of self doubt but certain that a peer is in the wrong role), I would recommend trusting your gut. And I would say that there’s a lot of room in tech for a lot of people at almost any skill level. Just not always on your team. And that’s okay. They’ll very likely be okay.
- cutemonster 6y ago
  > I feared alienating everyone It seems you didn't alienate them in the end? When looking back?

tjpnz 6y ago

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.

jachee 6y ago
Considering the Dunning-Krueger effect, my Imposter Syndrome is sure that I must either be a bad engineer, and that it's just a matter of time before I mess up in a situation because I incorrectly evaluate my skill level at evaluating my skill level... etc. or that I'm a decent engineer. I've been trying to avoid that meta-evaluation spiral for years by semi-regularly checking with third parties to confirm that I'm generally the person I believe I am. So far, so good. Edit: Almost forgot: The whole point of this introspection is to point out that the self both is and isn't a decent guidepost for evaluating others.
usefulcat 6y ago
> What would you consider a bad engineer? Are we talking about the utterly hopeless or those who might only have an attitude problem? Those categories aren't necessarily disjoint. There can be many aspects, many of which are described in the paper. But in my experience, one of the more pernicious combinations is the sincere belief that one already knows nearly everything worth knowing, coupled with a complete lack of curiosity (or perhaps it was merely utter laziness). When that happens, a person stagnates. In the case I saw, a person with decades of experience was effectively performing only marginally better than someone who had just begun their career. The major difference being that a person who has just started is often well aware that they have a lot to learn. Or even if they're not, if they're curious then there's at least a good chance that they will figure that out in time.
greggman3 6y ago
I have met plenty of bad engineers so maybe it's just luck. Engineers that can't write simple code and always over engineer. Engineers that have no concept of encapsulation and use globals all over the place. Engineers that have no concept of perf. Engineers that can't ship and noodle the same piece of code for weeks that others would have finished and moved on in a 1/10th the time. Engineers that are all talk no work. That last type sticks out where the engineer would basically walk around and stop at people's desks and talk their ears off but never actually finish any code. People complained. The boss said "they have a family so I don't want to fire them". I don't know how to answer that.
- Viliam1234 6y ago
  I wonder what would happen if you also started walking around and stopped finishing code. Would the boss keep you too, or would you get fired despite having a family?
TeeMassive 6y ago
> 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.
kitsune_ 6y ago
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.

NhanH 6y ago

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.

AmericanChopper 6y ago
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.
- cutemonster 6y ago
  > 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. It'd be interesting if there was somewhere to read about such companies. Maybe they don't realize themselves -- if the founders aren't technical enough to realize that the technical leader is the very wrong person They might never realize why things didn't go their way, and blame other things instead
cutemonster 6y ago
> false positive from following the advice Is that accidentally not hiring someone who would have been a good fit?

PragmaticPulp 6y ago

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. Being a negative value engineer isn’t just about writing bad code or being incompetent. Those things are trivially obvious in any technical interview. The reality is that negative value usually comes from behavioral issues. Engineers who are constantly sowing discord against the company or management can bring down entire teams. Engineers who create conflict and destroy morale are toxic for productivity and will drive away your best team members. Engineers who can’t ever ship anything on time because they can’t manage their own time or they have pathological perfectionist tendencies will sink your schedules. Ironically, negative value can often come from those with great technical chops who are unfortunately mired in personal issues. Managers can compensate to some degree with intense attention and guidance for those individuals, but at what cost? Obviously managers should make an attempt to correct behavioral problems that are dragging the team down, but at some point you need to do the inevitable and replace the problematic employee with someone who can perform without the behavioral issues. It’s not just a question of whether or not someone can write good code. It’s a question of whether or not the team and company are best served by keeping a troubled employee as opposed to reallocating that finite headcount to a new candidate.

kitsune_ 6y ago
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.

hinkley 6y ago

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?

user5994461 6y ago

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.

eyelidlessness 6y ago

I was probably 6-7 years into my career before I encountered such a person. It was my first formally titled “software” role, having spent the years prior making software and calling it “websites”, for a mostly brochureware design firm. I had terrible impostor syndrome. But I recognized that a member of my team was simply not up to the task. And was very well liked by the team, so no one had spoken up. But I was gaining responsibility, including (informal at the time) leadership of this individual. And it was a liability to the team, and to me, and ultimately to the person in question. So I spoke up. I felt terrible about it, I feared alienating everyone, and I feared I was putting the person in financial and career risk. But I didn’t see a way to bring them up to even a standard where their presence wouldn’t be a net negative, and I knew I wasn’t up to the challenge of carrying that weight. So I did what was best for the team. The person was ultimately let go. And they did ultimately find a role that was better suited to them. So all is well. In hindsight I don’t think I should have been so torn up about it. It actually sucks to be in over your head, knowing it or not, and it’s possible finding a more fitting role is a better place for growth into more challenging roles. I’m not sure how to conclude this, I’m not sure if there’s even any value sharing it. But I guess for anyone reading who finds themselves in my position (newish, relatively ascendant, full of self doubt but certain that a peer is in the wrong role), I would recommend trusting your gut. And I would say that there’s a lot of room in tech for a lot of people at almost any skill level. Just not always on your team. And that’s okay. They’ll very likely be okay.

cutemonster 6y ago
> I feared alienating everyone It seems you didn't alienate them in the end? When looking back?