Everyone should read support emails • Hacker News Board

Re: Everyone should read support emails

#71

Post by SketchySeaBeast » Mon, Mar 04, 2019, 2:49 PM UTC

RickJWagner wrote: post #12

Support engineer here. For anyone considering a career in support: - It's harder than development. Green fields are easier. - It's pretty much a thankless job. - You are sort of the janitors of the IT world. Not much respect. + The money can be pretty good. Because of the above, management usually rewards good support engineers. + You are welcomed by those who don't want to do support. + You stay fresh, learning othe…

> You stay fresh, learning other people's ideas all the time. This contributes to longevity.

I recently moved from a dev/support combo role to more of a support one, and this really stands out to me. I'm supporting a half dozen solutions currently, and each one consists of a pile of different flavours of the month. I'm learning a ton of new technology to support the solutions, much more so than if I'd stayed on any one dev team.

Re: Everyone should read support emails

#72

Post by AlexTWithBeard » Mon, Mar 04, 2019, 2:49 PM UTC

superice wrote: post #43

This is why we regularly take developers to customers. It is eye-opening to see on-site that your mobile app with tiny but well-designed buttons doesn't work for registering container positions when the user is in a shaky 90 metric tons weighing machine, handling 30 metric ton containers. We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incre…

shaky 90 metric tons weighing machine, handling 30 metric ton containers

Also gives an immediate answer to all these "should we fail gracefully or crash loudly?" arguments.

Re: Everyone should read support emails

#73

Post by magicalhippo » Mon, Mar 04, 2019, 2:49 PM UTC

AnIdiotOnTheNet wrote: post #8

That would require developers to think of users as people instead of cattle, and then they might have to accept that the decisions they made because "developer time is worth more than user time" have an actual real-world cost on actual real-world people.

> "developer time is worth more than user time"

To an extent this is true, in the sense that one must consider the opportunity cost. When working on feature A or fixing bug B, I cannot be working on feature X or fixing bug Y. Also, some features might require a disproportionate amount of developer time compared to the time the user saves.

Just the other day I dismissed a feature request from a user which would have saved that user an hour or so doing a particular task. The problem was that it would have taken me over a week to implement and test (it required complex changes), and the user only had to do this task once a month at most. So for now, I couldn't justify the development time vs user time benefit.

That being said, my primary motivation is to enable users, letting them be more efficient and doing things they otherwise couldn't. I love adding features which allows users to spend minutes rather than hours doing a task, or even entirely automating the process. But I must be mindful of the opportunity cost.

Re: Everyone should read support emails

#74

Post by ahaferburg » Mon, Mar 04, 2019, 2:50 PM UTC

supergilbert wrote: post #62

Be careful, it can be demoralizing for engineers working on the product as you can get the feeling that nothing works.

I would presume most competent engineers have a pretty good grasp of what is or isn't working. If something doesn't, they probably knew about it already, or at least aren't surprised.

Re: Everyone should read support emails

#75

Post by AllegedAlec » Mon, Mar 04, 2019, 2:53 PM UTC

SketchySeaBeast wrote: post #70

AllegedAlec wrote: post #42

Earlier quoted context omitted.

A few weeks ago I tried to make a complaint to the national mail service, because they decided the pickup point closest to me was about half an hour from my house, rather than the pickup point that was literally around the corner. They had an online complaint form, but you were only able to use it on workdays between 0900 and 1600.

> They had an online complaint form, but you were only able to use it on workdays between 0900 and 1600. Was it an interactive form with immediate feedback? I'm trying to figure out a way to justify hours on a feedback form.

They promised feedback within a couple of hours. Even so, I see no reason to limit it in this manner, just tell them you'll to to get back the same day or the first workday...

Re: Everyone should read support emails

#76

Post by jpatokal » Mon, Mar 04, 2019, 2:55 PM UTC

levi-turner wrote: post #29

RickJWagner wrote: post #12

Support engineer here. For anyone considering a career in support: - It's harder than development. Green fields are easier. - It's pretty much a thankless job. - You are sort of the janitors of the IT world. Not much respect. + The money can be pretty good. Because of the above, management usually rewards good support engineers. + You are welcomed by those who don't want to do support. + You stay fresh, learning othe…

Very good list, although I'd disagree about pay. I'd add: + it's one of the easier routes to becoming a literal expert in how to deploy the software.

Pay for level 1 positions is indeed not great, but the money is pretty good in companies that value support enough to do it in-house and once you've learned enough to be senior/backline to a whole crew of juniors.

I do agree that the pay does not necessarily reflect the fact that the job is often harder than mere software development: you're basically debugging other people's software in realtime, often while angry people yell at you.

Re: Everyone should read support emails

#77

Post by magicalhippo » Mon, Mar 04, 2019, 2:56 PM UTC

When I started at my current place, I had some great learning experiences answering the support phone after the regular support staff had gone home for the day. Officially our support ended at 1600, but sometimes I'd hear the phone ring 5-6 times in a row, so I figured they probably had an urgent issue and picked it up.

Since I was still quite new, this introduced me to areas of the program I didn't know very well yet, as well as learning just how the users used our program. This knowledge has been invaluable when improving the program.

I also had several instances of me going "wait why did you click there before going here?" with a reply along the lines of "oh if I don't do that I'll get an error message, let me show you", bugs that had never been reported yet being present for years.

Re: Everyone should read support emails

#78

Post by evrydayhustling » Mon, Mar 04, 2019, 2:57 PM UTC

Once upon a time, most growth came from creating supply chains for things people already knew they needed. Then, it was about creating products that made people's lives better in ways they didn't expect. Now, increasingly, it's about getting an audience together and adapting to what they need as it changes over time. Staying close to the customer is getting more and more important.

Re: Everyone should read support emails

#79

Post by nkrisc » Mon, Mar 04, 2019, 2:58 PM UTC

One great thing my company does is put a prominent link on the intranet homepage where anyone in the company can schedule a 1 hour shadowing session with customer support. You don't need a reason and within a few hours you've got time scheduled within the next few days. I think the whole process was actually driven by support as they wanted the rest of company to know what they do and see what they see.

Re: Everyone should read support emails

#80

Post by arkades » Mon, Mar 04, 2019, 2:59 PM UTC

badsectoracula wrote: post #37

AnIdiotOnTheNet wrote: post #20

Earlier quoted context omitted.

> In my experience, such time pressure comes from management In my experience, open source developers are just as bad, if not worse, when it comes to their treatment of users.

Yes, but open source developers are in their vast majority unpaid volunteers gifting their labor to other users, so these users can either accept the gift as it is or not accept and move on. They are not entitled to other people's work and time for free.

>>> such dev behavior is driven by managers

>> open source people, who don’t answer to managers, act similarly. Therefore, it seems unlikely to be due to managerial influence.

> well open source is a gift of labor, people shouldn’t look a gift horse in the mouth

What you say may be true, but also irrelevant to the discussion being had.