Hacker News Reader

Comment by ocdtrekkie | Hacker News Reader

If you aren't doing production support, you don't actually know your product. You aren't connected to the pain points your users experience and you miss what is, to your support team and your customers, the glaringly obvious.

I would argue all developers should be required to do some support work.

View on HN

Having skin in the game will make you a better engineer. You’ll get better at the non-sexy things: monitoring, alerting, testing, etc. You better believe a person who is pages for software at 3:00 am has an incentive to make that software more reliable.

I'm not even talking 24/7 pager work. But just tackling some support tickets as part of your job so you see where people are having issues with your product.

Too often I see BigCorp development teams seeming blatantly oblivious to where their pain points are, and it's because they aren't forcing their developers to do support. They're pushing code, but they aren't pushing code that solves real problems for people.

If you work for a Bigcorp development team, you are probably jus trying to keep a product owner happy. The user being happy or not will not ever impact your life, especially since you might well have moved on before it ever goes to prod.

But the directors and VP's aren't getting paged at 3am, so the incentives of the organization still go to lower quality software.

If the directors and VPs aren’t getting paged at 3am you need better leadership. The first thing that I did was subscribe to all outages. And I let the operations center to call me anytime if they need help resolving a production issue.

Sorry, this is a terrible argument.

No one expects customer support people to write code. Why? Because they don't have the skillset.

Yet people who make this argument seem to think any moron can do support.

The skillset for an engineer is not a superset of a customer support person.

Have your engineers sit in on support, by all means, but actually making them DO support will result in unhappy engineers and sub-par support.

Do not undervalue a good support person. They have a whole suite of skills engineers often don't have.

Dont most developers do level III support? Ultimately if the first and second lines of defense cannot solve the problem, from everything I've seen, it goes to an Engineer. If it is your product, i'd assume it comes to you. This has been the case at almost every company I've been at.

Don't dismiss the value of tier 1 and 2 support requests. Maybe 30% of your tier 1 requests are some confusion that support knows how to alleviate, but an engineer could make the product more straightforward to eliminate those support issues entirely.

You aren't looking for the hardest problems, you're looking for the problems your users hit the most that an engineer could reduce in the product.

> You aren't looking for the hardest problems, you're looking for the problems your users hit the most that an engineer could reduce in the product.

This is the hard part of software.

Why should a company hire two lines of support to shield an engineer from bugs they introduce?

1. Not every support request is the result of a bug.

2. Not every bug is directly related to the product owner/team. Bugs can be introduced from different teams/processes.

3. Requiring senior engineers to do L1 and L2 support is likely a misallocstion of resources when less senior people can handle those issues.

1. The best team I've ever worked with considered every support request to be a bug. Is the user confused? At minimum, that's a documentation bug. It's also possible the product itself should be doing a better job stepping the user through a process or self-diagnosing.

3. https://news.ycombinator.com/item?id=24554399

4. Engineers have a bad habit of renegotiating scope in front of the customer without realizing they’ve done it.

As usual, "that should be easy to fix, just line of code here". At least from SWE perspective the fix may be easy to make but architecture or product management team may not be so happy about such pitch, especially when customer responds with "oh great, when?".

3 is a common mistake, like the one engineers make when they pretend that the hard part of programming is typing

I am not sure most of the calls are bug reports. There's a customer support level, they triage. Sometimes what the customer think it's a bug it's a design decision (or lack of a feature) and the customer support knows another way of accomplishing the same task. Or they know it's not supported at all.

I largely agree. My company has dedicated CS, a second tier 'triage', and well...me. I always prefer if customers just email me directly. CS is a frustrating, cost saving measure. And often I'll get tickets, 3 weeks later, like 'customer said they have an issue.' What's the point again?

Reply on news.ycombinator.com