4 ms·

Is this seriously a post highlighting the heroics of being on-call?! Wake up -- being on call sucks. Being an on call programmer is even worse. All developers

by jtchang 15y ago

Is this seriously a post highlighting the heroics of being on-call?! Wake up -- being on call sucks. Being an on call programmer is even worse. All developers should have to work support sometime in their life to realize the pain of supporting software vs writing it. Only then will you realize why doing it "right" the first time really matters. I kind of agree with the first comment on that post from Alice Young. Even though DHH just calls Alice out as trolling I know from experience that if you have on-call programmers it is a sign that your product is reaching a new level of complexity. Whether the complexity is coming from internal features or outside integrations it is probably time to take a second look at how you are handling your development processes.

bryanl 15y ago
I believe that programmers shouldn't have to work support "sometime in their life", they should be working it at their current position. Sometimes it is all too easy to throw the problems over the fence to a tech ops (fancy name for sysadmins?) or the even worse -- the dreaded app support team. Having to live with the decisions your code makes can hopefully only make it better.
- dmpk2k 15y ago
  In theory that sounds great. What I've seen and heard from practice (surprisingly) isn't. I think a better idea is to have excellent communication between the two groups, whether on channels or in the same room. Both specialize, but both have the ready support of the other. It's unnecessary to go further. That's what we do at my current gig. It has worked out well.
elliotanderson 15y ago
You're equating complexity with support assurance. From what they have written in the past, everyone has a share in providing customer support so that the developers don't become disconnected from the customers actual needs. Small annoyances are easy to ignore when there's a layer of support personnel insulating you. I've been in a similar situation developing a SaaS ecommerce application, so from my point of view what they are saying makes perfect sense. It's an assurance to their customers that they have proper escalation and continuity plans in place, and should anything out of the ordinary arise there are developers rostered on. This kind of setup would be easy for them to implement considering their employee's are spread across many timezones.
viraptor 15y ago
Depends in what you like to do at work. Writing code isis boring most of the time. The most exciting thing that can happen is trying to figure out a design for a very complicated problem and sure, that's fun stuff. But I find handling production emergencies much more exciting. Whatever you test for, whatever you monitor, one day you find the system down or misbehaving in a completely unexpected way. And if your service is supposed to run 24/7 worldwide, someone has to fix it, preferably as soon as possible and making sure as few people are affected as possible. In short, different people like different kind of work. And that's ok.

by jtchang 15y ago

bryanl 15y ago

I believe that programmers shouldn't have to work support "sometime in their life", they should be working it at their current position. Sometimes it is all too easy to throw the problems over the fence to a tech ops (fancy name for sysadmins?) or the even worse -- the dreaded app support team. Having to live with the decisions your code makes can hopefully only make it better.

dmpk2k 15y ago
In theory that sounds great. What I've seen and heard from practice (surprisingly) isn't. I think a better idea is to have excellent communication between the two groups, whether on channels or in the same room. Both specialize, but both have the ready support of the other. It's unnecessary to go further. That's what we do at my current gig. It has worked out well.

elliotanderson 15y ago

You're equating complexity with support assurance. From what they have written in the past, everyone has a share in providing customer support so that the developers don't become disconnected from the customers actual needs. Small annoyances are easy to ignore when there's a layer of support personnel insulating you. I've been in a similar situation developing a SaaS ecommerce application, so from my point of view what they are saying makes perfect sense. It's an assurance to their customers that they have proper escalation and continuity plans in place, and should anything out of the ordinary arise there are developers rostered on. This kind of setup would be easy for them to implement considering their employee's are spread across many timezones.

viraptor 15y ago

Depends in what you like to do at work. Writing code isis boring most of the time. The most exciting thing that can happen is trying to figure out a design for a very complicated problem and sure, that's fun stuff. But I find handling production emergencies much more exciting. Whatever you test for, whatever you monitor, one day you find the system down or misbehaving in a completely unexpected way. And if your service is supposed to run 24/7 worldwide, someone has to fix it, preferably as soon as possible and making sure as few people are affected as possible. In short, different people like different kind of work. And that's ok.