Hacker News Reader

Comment by Aeolun | Hacker News Reader

Ok, but how do you deal with people that submit broken CSS, break the site, and are unapologetic? Especially when you are in no position to fire them (because laws, or organisation)?

All these “if you do it this way it works” posts seem to assume everyone has the best of intentions (or at least want to do the best job possible), and especially in corporate settings I just don’t think that’s always the case. People are just there for a paycheck and to divert any possible responsibility away from themselves…

View on HN

First time: teach them the right way to do that

Second time: you did it again, did you forget the right way?

Third time: we've talked about this before, what's the deal? If this keeps happening, we're going to have to reconsider your employment here as a web developer

Fourth time: last warning

Fifth time: bye

Good people don't do this sort of thing repeatedly. If your organization refuses to get rid of people like that, you shouldn't stay at that place either.

I see that you gave the person 5 warnings - I feel 3 times is less and this is exactly what I would do. Its so much better to give people more chances rather than less and then letting them go instead of letting an ego or something similar come in detween earlier.

Please do not take number 5 so literally. It's the process that matters. You do 2, 3, 4, 5, 6, 7, 8, 9 or 10 chances whatever suits your needs. The actual point is you don't fire people on the first mistake unless you're an asshole.

I guess you need to put automation in-place that interrupts these people when they're trying to deploy something broken. Tests, linters, static analysis etc.

If it's clear someone is not acting in good faith, I can think of three options:

1. Find out why and try to fix it

2. Fire them

3. Embrace the low-trust environment by trying to mitigate the dysfunction with layers of bureaucracy

Strategy 3 seems quite popular, and to be fair it might be the only one that scales.

There must be a point in which they can be fired, unless there some nepotism going on.

If so, then it's already pretty messed up.

you fire them

That takes months or years if it's possible at all (at least in many places). For any place where you can neither fire bad devs nor find very good ones to replace them with, the trick is to make good processes and products using mediocre people. And that's hard. But that's also why a lot of processes appear, that would seem unnecessary to someone who is a good engineer and used to working only with good engineers.

You fire them anyway. The problem isn't incompetence. It's the inability to self reflect and see your own mistakes as mistakes that is missing.

Reply on news.ycombinator.com