undefined | Better HN

0 pointsnevon3y ago0 comments

Have you never had a coworker that needs so much help that they end up "costing" so much of other people's time and focus that you would have been better off if they weren't there at all? While I thankfully haven't encountered a lot of people that far out on the competency spectrum, I have met a few, or more than a few that are not too far off. Not a large proportion of hires, as OP said, but still.

0 comments

kaidon3y ago

Absolutely. On a small team, we had 2 underperforming devs.

One was doing absolutely nothing at all for months on end.

One was doing negative work - every line of code made things worse, every document was unintelligible, and they would approve every PR from other devs the second it was opened.

Suffice it to say, the dev that did nothing at all was the most productive of the two.

twawaaay3y ago

I would add to it that there are a lot of devs that can't build stuff but they try (frequently successfully) to sell that they are doing a lot of volume of work (like closed tickets, lines of code, hours clocked).

And these people frequently last surprisingly long at companies because it is pretty hard for managers to understand how individual team members contribute to overall productivity. Managers tend to focus on short term goals (like getting a feature delivered or a bug solved) but have hard time understanding long term implications of bad decisions their people make.

It is pretty easy to fix a bug or write a feature but a bad developer will cause large amount of debt along with it that will slowly deteriorate productivity in ways that will be difficult to understand. The people who understand what is happening -- senior devs -- will frequently not speak up about it or their voice will be downplayed ("Hey, this guy can't be that bad, he is delivering after all?")

leghifla3y ago

If management does not pay close attention, doing sloppy work with many small bugs is the key to very high (measured) productivity:

  - You close a feature ticket by cutting all corners possible
  - Every corner cut will later become a bug ticket, that you can solve quickly as you are more familiar with the feature

Total: you have closed more tickets than a dev that did the feature right the first time... sad

1 more reply

closeparen3y ago

Given how short tenures are across the board, those of us who are even around to notice long term outcomes are sort of wierdos to begin with. Many senior and staff engineers, architects, directors, etc. have never seen their own work 2 years down the line. Even if they stay at the company they switch teams, etc.

kaidon3y ago

> deteriorate productivity in ways that will be difficult to understand

Exactly! This can be very difficult to quantify; as this kind of debt is undetectable by standard gates (linter, static analysis, etc.). Instead, it is more nefarious... introducing coupling, where none was needed, or long-winded tests; that test very little, and make the code hard to refactor. I don't have a measure for this beyond my intuition of working with code for decades.

What makes it all worse, is when the features are 'delivered' and marked as 'complete' by these folks, they are difficult to take back! Especially if their delivery was identified as a key objective to a quarter.

1 more reply

bratbag3y ago

I've had one. I put them on a pip and they found a more senior role at another company.

Good luck to their new manager.

vervez3y ago

So you `pip install`ed them at a new company? I'll see myself out.

1 more reply

j / k navigate · click thread line to collapse

0 comments

kaidon3y ago

Absolutely. On a small team, we had 2 underperforming devs.

One was doing absolutely nothing at all for months on end.

One was doing negative work - every line of code made things worse, every document was unintelligible, and they would approve every PR from other devs the second it was opened.

Suffice it to say, the dev that did nothing at all was the most productive of the two.

twawaaay3y ago

leghifla3y ago

If management does not pay close attention, doing sloppy work with many small bugs is the key to very high (measured) productivity:

  - You close a feature ticket by cutting all corners possible
  - Every corner cut will later become a bug ticket, that you can solve quickly as you are more familiar with the feature

Total: you have closed more tickets than a dev that did the feature right the first time... sad

1 more reply

closeparen3y ago

kaidon3y ago

> deteriorate productivity in ways that will be difficult to understand

1 more reply

bratbag3y ago

I've had one. I put them on a pip and they found a more senior role at another company.

Good luck to their new manager.

vervez3y ago

So you `pip install`ed them at a new company? I'll see myself out.

1 more reply

j / k navigate · click thread line to collapse