Hacker News new | past | comments | ask | show | jobs | submit login

In some companies, there is a difference between developers (people who create new features) and L2 or L3 support (people who fix bugs and resolve problems for the customer). The trend is not to have this division, and I disagree with that.

I agree that it is good to try both things, and developers should try to be support once in a while, and vice versa. However, I think they are very different mindsets and doing both is making people less productive.

When you're a developer, you need to concentrate on the new feature you're working on only. The better you concentrate, the less bugs and problems you introduce. However, when you fix issues for the customer, it's often punctuated work where you wait for the customer, or investigate the problem, and so you work on many different little things at once. It is not a very good environment to do bigger decisions about architecture changes.




Not sure about this. Separating dev work like that is a risk to get architecture astronauts in low stress position with a bunch of peons suffering for their sins in the trenches. Concentration is not a good argument, bug fixing requires no less of that and is often compounded by time pressure.


I agree and I think couple months rotation is ideal, actually. I certainly do not advocate architects who do not code etc.

Of course, it depends on person. Some people are really good architects/developers and you don't want them to spend their days talking customers through issues. On the other hand, some people are more comfortable in support and that's good too.

And I think if a bug fix requires larger rearchitecture of the thing (that is, the root of the problem is more conceptual than just incorrect code), then it's better addressed by temporary patch and doing it properly in development cycle.


There are always more takers for feature work than for fixing that Friday afternoon race condition a customer is experiencing :) I agree rotation sounds like a good balance.


IME developers will go where the career growth is and it is up to the company to make sure that fixing a race condition on a Friday afternoon is rewarded.


Bug fixing is very different from being on-call. I don't see the correlation between getting a full night's sleep each night and being an "architecture astronaut".


Do you think "people who fix bugs for customers" don't deserve full night sleep each night?


I don't think you are reading my comment correctly (or generously, as per HN guidelines). I made no such assertion, nor do I believe, what your question implies.


OK, I'm now lost what are you trying to refute. Perhaps reading the comment I was replying to originally for the context would help understanding the point I was addressing. I never mentioned being on-call or having a good sleep at all.


I'm not sure why you're getting downvoted. I think this is a point of view that is at least worth considering.

Personally, I really dislike emergency software debugging. I much prefer the kinds of projects that prioritize testing and code stability so as to obviate the need for an 'on call' developer. In these kinds of projects an emergency call should be so rare as to essentially be never.


That kind of sounds like fantasy for complex high throughput systems. As it was also mentioned in the article, the usual on-call response is a rollback to the last working version of the correct deployable. This is pretty easy to identify for someone in the team developing the service.


There's a large category of complex systems where you have to get it right in advance because of the consequences of problems; anything avionics or real-time, for example. Or you can lose a lot of money without blowing things up but still faster than the on-call humans can respond: https://dougseven.com/2014/04/17/knightmare-a-devops-caution...

(High-reliability engineering is very much a different, more expensive, less agile culture from software startups, and I worry that the culture is bleeding across in inappropriate ways. The "self-driving" car with a "safety driver" is an extreme example of this: an on-call human that's supposed to respond to operational problems in an extremely short timeframe, but also provides an opportunity to blame the human rather than the software)


High realiabity and high availability are not the same thing though. There are still problems in aviation, like the dreamliner who had to be restarted every x days or it would go full system shutdown. In these kind of systems you often sacrifice availability for reliability. You also sacrifice progress for reliability, which is absolutely the right thing to do for these projects.

An on call engineer shouldn't be the solution for bad reliability, because as you said it doesn't help. He is primarily there for availability.

Instead of high throughput I maybe should've said highly available systems.


Adding an extra layer of people between the customer and developer is certainly a good idea as it requires a completely different skill set to communicate with a customer and troubleshoot their issue than for being a developer. Like I always ask my mom before I even begin to troubleshoot her problems "Have you tried turning it on and off again?" "Did you really turn it on and off again and not only open/closed the display?" Our support people, when asked for a forward to a developer afaik often jokingly say "you don't want to talk with one of our developers" and I think it's true for most issues.

Splitting the people that write software, fix bugs for that software and make sure their system is available throughout the night is terrible from a responsibility point of view. It makes you not give a crap, while developing new features. That's just human nature.


If I introduce a bug, I fix that bug. I don't understand your comment, sorry.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: