Comment

Comment by firebaze

We had a member in our team who was quite sharp, understanding of user relevant functionality/aspects, who could code semi-complex stuff all on his/her own (of course without consulting anyone else) and whose every line was the moment it was typed legacy. As everyone was a bit dumbfounded by the self-confidency, and also because the whole team was busy doing greenfield groundwork, glad to have someone who takes care of him/herself, producing code that appeared to work, we let him/her do without interfering much. When there was interference, the reviewer was left with the impression that she/he just didn't understand the marvels of the code she/he just reviewed. Afterwards, legitimations included "unit tests are non-clean, they require too much mocking/stubbing", this is an "edge-edge-edge case" and so on (architectural and design deficiencies are routinely defended by statements like this, and in this case, spot on).

Since she/he was dubbed a star developer for a while (which is quite astounding, since we have quite a high bar for hiring), she/he could get away with that. From a certain perspective she/he was successful: we launched our project in time, with few bugs, with quite an amazing feature set. Most of the credits go to the not-so-visible, but diligent other team members, but from a management perspective it was quite a success.

After rewriting ~30% of her/his code, with the prospect of ~70% remaining, the person is not working on the project anymore. But she/he is complaining all the time about how much legacy code he/she has to maintain in the new role, and how serious her/his (from her/his perspective non-voluntary removal from the project despite his/her indispensability) abilities must be missing from the project team.

Extreme case, I know. But it's just the most extreme one I saw in my dev career :)

Edit: s/he -> she/he

parent firebaze 6 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton