5

I hate working with sh*tty Devs

I used that term specifically.. No it's not about juniors, it's about those who pretend to be seniors.
In a major company project, one of us has to take a week or two to refactor that one "senior" dev work. When tested it performs poorly, when checked, it violates every SE principle and the business people are wondering why we keep seeing `refactoring User Stories/Tasks` and why we still don't have a working project yet. Yes, we will never have, that mess that `senior` dev created is almost impossible to refactor without major rework.
Now, major rework coming, we need to give something to that Senior so he doesn't feel left behind. Argue to never let him get anything in core or this company will go under...

In short, I hate working with sh*tty devs.

Comments
  • 1
    (second hand knowledge be warned)

    My mentor mentioned a scenario similar to this. Their solution was to minimise the damage caused by the bad Dev while still meeting the imposed deadline.

    Their compromise was to:
    1. establish clear fire gap boundaries between the existing code and what the bad Dev was going to write and told the bad Dev not to cross it.
    2. seniors then paired with the bad Dev on most of the work to iron out the biggest issues
    3. team was able to later refactor most of the bad code quickly as it was isolated by the clear interfaces and feature tests

    Idk how the code looked in the long run as I wasn't there (will ask them next week), but hopefully something like might make your team feel less despair in the short term!
    Do keep us updated.

    I've always found pairing and asking them to review my PRs (and others I think are good) help show the learnings and approaches I think are valuable
Add Comment