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 :)
Never trust an engineer who says they don't need to write tests. It's somewhat of a dream for many engineers to be heads down working alone on deep technical problems but while coding may be solo endeavor, _code maintenance_ is a team sport. It's never good to let someone go it alone for too long.
Side note: It's much simpler to say "they/them" when referring to someone rather than "he/she", "s:he", and "his/her".
Sorry, not a native speaker and reading too much strange english books, which could spoil my writing. Could you point me to one or two specific errors I made in order to help me improve?
If you're referring to s:he and so on, that is our german way of obfuscating the gender of the subject :) I don't like it (at all, since most of the time it just dismisses achievements of women).
What I just said it's that's what most people do. I clarified that this is in spite of "they" typically referring to multiple people. It's helpful for non and new English speakers if you explain these colloquialisms.
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