Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developer on Call

henrikwarne.com

Post reply on HN
Print view View original

161–170 of 246 posts

Re: Developer on Call

#161

Post by hinkley »

jpalomaki wrote: post #71

Kayak.com co-founder Paul English on this topic (2010): "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking crack. They say, "Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?" If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they'…

My very first job was tech support and then QA (because fewer bugs means less email) for a small team working on a popular product.

I started informing the developers every 2nd (or maybe it was 3rd) time I saw different people experiencing the same problem.

So by the time we'd had around 8 people reporting the same issue they'd gotten tired of seeing my face and fixed the bug.

It's the feedback that's important. A little friction in the path could be a good thing, as long as the people providing the friction have an incentive to do the right thing. I sat one room over from the devs, I was friends with one of them, (had designs on switching teams) and we all went to the same planning and status meetings, so my head was in the right place for this.

I recall many many years ago Dell cancelled a plan to move front-line QA overseas because they realized that there was a perverse incentive for an external team to keep quiet about frequently asked questions (because they're cheap to answer and you get paid by the call).

Those people in Arizona won't give a damn about how many people can't figure out the app, so long as users keep calling (ie, just good enough that you retain customers).

Re: Developer on Call

#162

Post by sdegutis »

tristor wrote: post #128
wink wrote: post #89

Earlier quoted context omitted.

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.

It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A…

> So which set of customers do you please? How do you ensure that customer requests for behavior changes, or customers being surprised by application behavior doesn't result in a scope creep that expands the requirements of your application to an unsustainable level?

> How do you ensure that your business doesn't get coopted by BoM (Buckets of Money) to basically be a contract development house and eventual acquisition target by your largest enterprise customer while ignoring/harming all your other customers who were earlier adopters?

Fork the product into two (or more) separate products, each of which are somewhat similar but cater to different audiences with different needs.

Re: Developer on Call

#163

Post by OnlyRepliesToBS »

jpalomaki wrote: post #71

Kayak.com co-founder Paul English on this topic (2010): "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking crack. They say, "Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?" If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they'…

[dead]

Re: Developer on Call

#165

Post by bobwaycott »

icedchai wrote: post #155
dboreham wrote: post #103

Earlier quoted context omitted.

Pro tip: have your managers do customer support .

That would be nice, except most are simply incapable. They forward the requests to the dev team, causing interruptions, distractions, and aggravating engineers.

Sounds like those managers need to be replaced. A manager ought to foremost protect the dev team from interruption, distraction, and aggravating or time-wasting requests.

Re: Developer on Call

#166

Post by Celarnor »

tristor wrote: post #132
ascar wrote: post #68

Earlier quoted context omitted.

My contract with a company that had on call read somewhere along the lines of 9 to 5 are the core working times and all work necessary outside these times, including Saturday and Sunday, is already remunerated in the base salary. In this case I was being paid for it and I only heard about it in the first week after starting. I asked "how often do I have to work on weekends", but not "will i be on call" in the contrac…

Disclaimer: IANAL " all work necessary outside these times, including Saturday and Sunday, is already remunerated in the base salary." That's actually not enforceable in most US states. Typically a base salary cannot cover work which is outside normal business hours if it's a consistent expectation that work will be performed outside normal business hours. Contracts are enforceable because both parties are given "due…

Do you have any citations/references to support this?

All of my jobs have been as the GP describes, where managers see after-hours problems as the dev's responsible for the relevant feature's "fault", and expect them to both manage communication with business stakeholders about the problem and make it go away within short notice.

Re: Developer on Call

#167

Post by amdelamar »

As a new engineer to the team with on call rotation, I've definitely learned a lot faster/more about the system we support, than I would have if I read our documentation alone. The real difference is seeing the system from a customer's POV rather than an architect's POV.

Re: Developer on Call

#168

Post by Novashi »

stevoski wrote: post #139
tristor wrote: post #128

Earlier quoted context omitted.

It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A…

That's a great description of the subtleties of product development, especially within a small team. Many books and articles make it seem like a simple procedure, but actually you often face decisions which will leave some people unhappy, no matter what you decide.

You basically have to get into supporting extensions or custom code and supporting an API if you run into enough of these customers and that’s when you declare that you only have so much responsibility for the customer’s code (and it quickly turns into another support revenue stream).

Re: Developer on Call

#169

Post by icedchai »

bobwaycott wrote: post #165
icedchai wrote: post #155

Earlier quoted context omitted.

That would be nice, except most are simply incapable. They forward the requests to the dev team, causing interruptions, distractions, and aggravating engineers.

Sounds like those managers need to be replaced. A manager ought to foremost protect the dev team from interruption, distraction, and aggravating or time-wasting requests.

I agree. That's why I moved on from that place.

Re: Developer on Call

#170

Post by colanderman »

varjag wrote: post #85
colanderman wrote: post #80

Earlier quoted context omitted.

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.
Post reply on HN