If you’ve built a system that’s supposed to be reliable, you shouldn’t be up fixing it at four in the morning. You shouldn’t be getting paged at all hours. Sure, you might need to do some occasional planned after-hours maintenance, or some very occasional unplanned-but-process-driven disaster recovery, but you shouldn’t need a hero.
Heroes are damaging to a team because they become a crutch. As soon as you have someone who’s always willing to work at all hours, the motivation from the rest of the team to produce reliable, trouble-free software drops. The hero is a human patch. Sure, you might sit around talking about how reliability is a priority, but in the back of your mind you know that the hero will be there to fix what doesn’t work.
Another great post by Alex Payne. Everybody knows a "code" hero or has been one yourself as one point or another. The problem that Alex points out is that when it happens too often, you are letting your team be mediocre or lazy and you rely on the hero. By now, I hope you have the time to read the whole post.
No comments:
Post a Comment