5 ms·

Yeah when I read that my first thought was that the CTO reacted that way because he was in fear of being fired himself. I wouldn't be at all surprised if he wro

by dkrich 9y ago

Yeah when I read that my first thought was that the CTO reacted that way because he was in fear of being fired himself. I wouldn't be at all surprised if he wrote that document or approved it himself.

sillysaurus3 9y ago
So at what point are you allowed to fire someone for being incompetent? Blowing away the production database seems to rank pretty high. Note that I'm not talking about the situation in this article. That was a ridiculous situation and they were just asking for trouble. I'm asking about the perception that is becoming more and more common, which is that no matter what mistakes you make you should still be given a free pass regardless of severity. Is it the quantity of mistakes? Severity of mistakes? At what point does the calculus favor firing someone over retaining them?
- nialv7 9y ago
  You fire people when they stopped producing values for the company. In my opinion, mistakes should never be considered the person's fault. The development process should be designed to prevent human mistakes. If mistakes happen, that only means the process has been designed poorly.
  - khazhoux 9y ago
    You can't treat mistakes as no-ops. This event demonstrated lack of attention.
    - ResidentSleeper 9y ago
      Don't be ridiculous - the first day at a new job can be incredibly stressful and disorienting. And even if somehow this doesn't apply to you, keep in mind that it does to a lot of people.
      - khazhoux 9y ago
        Ha! I missed that it was his first day. World's worst on-boarding guide!
  - gremlinsinc 9y ago
    No kidding, --he should get a bonus for finding a HUGE bug in their security lol.
- hluska 9y ago
  Firing should only really be an option when someone doesn't respond well to re-training and education.
  - sillysaurus3 9y ago
    It's hard to imagine a startup allowing themselves to die because they're trying to patiently re-train and educate someone. I know startups are a limit case, but we didn't bother to make those sorts of distinctions for this article, so it's worth considering.
    - lmm 9y ago
      If the startup is large enough to have employees who can be fired then it's large enough to train/educate them. 5 whys may be too many for a small startup but 1 is certainly too few.
- khedoros1 9y ago
  > So at what point are you allowed to fire someone for being incompetent? If someone is still expected to be learning, mistakes (even large ones) are to be expected. Incompetence has to be judged against reasonable expectations. In the case here, there was a series of pretty severe mistakes, but deleting the database isn't what I'm thinking of. Protecting the database was the job of the more experienced employees of the company, and ultimately the CTO. Some combination of people at the company were negligent, and the absence of actions taken to protect their systems shows a pattern of irresponsible behavior.
- DavidWoof 9y ago
  > blowing away the production database seems to rank pretty high. In this case, it's not a matter of degree, it's a matter of responsibility. The junior dev is absolutely not the one responsible for the prod db getting blown away, and is absolutely not responsible for the backups not being adequate. As somebody else mentioned, this is like leaving the electric cable to the production system strewn across the office floor, then firing the person who happened to trip over it. I agree somebody's job should be in jeopardy, especially if the backups weren't adequate: not for a single mistake, but for a long series of bad decisions and shoddy oversight that led to this.
- smsm42 9y ago
  This has nothing to do with competence. Competence is not never making mistakes (if somebody tells you he never makes mistakes, it's actually more likely he's just incompetent enough to not notice them). Competence is arranging work in a way that mistakes don't result in a disaster. Which clearly wasn't the job of the junior dude, and very likely was the job of the CTO. I could easily count at least half-dozen ways in the situation was a total fail before the mistake happened. So no, one shouldn't be given free pass for mistakes. But one should expect mistakes to happen and deal with them as facts of life. As for killing whole prod database, anybody who have spent some good time in ops/devops/etc. has war stories like this. Dropping wrong instance, wiping wrong system, disabling network on wrong system... A lot of people been there and done that. If it didn't happen to you yet and you're in the line of work where it can - it will. It would feel awful too. But it'll pass and you'd be smarter for it.
  - mmcnl 9y ago
    > Competence is arranging work in a way that mistakes don't result in a disaster. I like this definition.

by dkrich 9y ago

sillysaurus3 9y ago

So at what point are you allowed to fire someone for being incompetent? Blowing away the production database seems to rank pretty high. Note that I'm not talking about the situation in this article. That was a ridiculous situation and they were just asking for trouble. I'm asking about the perception that is becoming more and more common, which is that no matter what mistakes you make you should still be given a free pass regardless of severity. Is it the quantity of mistakes? Severity of mistakes? At what point does the calculus favor firing someone over retaining them?

nialv7 9y ago
You fire people when they stopped producing values for the company. In my opinion, mistakes should never be considered the person's fault. The development process should be designed to prevent human mistakes. If mistakes happen, that only means the process has been designed poorly.
- khazhoux 9y ago
  You can't treat mistakes as no-ops. This event demonstrated lack of attention.
  - ResidentSleeper 9y ago
    Don't be ridiculous - the first day at a new job can be incredibly stressful and disorienting. And even if somehow this doesn't apply to you, keep in mind that it does to a lot of people.
    - khazhoux 9y ago
      Ha! I missed that it was his first day. World's worst on-boarding guide!
- gremlinsinc 9y ago
  No kidding, --he should get a bonus for finding a HUGE bug in their security lol.
hluska 9y ago
Firing should only really be an option when someone doesn't respond well to re-training and education.
- sillysaurus3 9y ago
  It's hard to imagine a startup allowing themselves to die because they're trying to patiently re-train and educate someone. I know startups are a limit case, but we didn't bother to make those sorts of distinctions for this article, so it's worth considering.
  - lmm 9y ago
    If the startup is large enough to have employees who can be fired then it's large enough to train/educate them. 5 whys may be too many for a small startup but 1 is certainly too few.
khedoros1 9y ago
> So at what point are you allowed to fire someone for being incompetent? If someone is still expected to be learning, mistakes (even large ones) are to be expected. Incompetence has to be judged against reasonable expectations. In the case here, there was a series of pretty severe mistakes, but deleting the database isn't what I'm thinking of. Protecting the database was the job of the more experienced employees of the company, and ultimately the CTO. Some combination of people at the company were negligent, and the absence of actions taken to protect their systems shows a pattern of irresponsible behavior.
DavidWoof 9y ago
> blowing away the production database seems to rank pretty high. In this case, it's not a matter of degree, it's a matter of responsibility. The junior dev is absolutely not the one responsible for the prod db getting blown away, and is absolutely not responsible for the backups not being adequate. As somebody else mentioned, this is like leaving the electric cable to the production system strewn across the office floor, then firing the person who happened to trip over it. I agree somebody's job should be in jeopardy, especially if the backups weren't adequate: not for a single mistake, but for a long series of bad decisions and shoddy oversight that led to this.
smsm42 9y ago
This has nothing to do with competence. Competence is not never making mistakes (if somebody tells you he never makes mistakes, it's actually more likely he's just incompetent enough to not notice them). Competence is arranging work in a way that mistakes don't result in a disaster. Which clearly wasn't the job of the junior dude, and very likely was the job of the CTO. I could easily count at least half-dozen ways in the situation was a total fail before the mistake happened. So no, one shouldn't be given free pass for mistakes. But one should expect mistakes to happen and deal with them as facts of life. As for killing whole prod database, anybody who have spent some good time in ops/devops/etc. has war stories like this. Dropping wrong instance, wiping wrong system, disabling network on wrong system... A lot of people been there and done that. If it didn't happen to you yet and you're in the line of work where it can - it will. It would feel awful too. But it'll pass and you'd be smarter for it.
- mmcnl 9y ago
  > Competence is arranging work in a way that mistakes don't result in a disaster. I like this definition.