3 ms·

One of those times when one should stick with one's initial thought. Everyone should have to work a retail job to get a sense of what a broad selection of the

One of those times when one should stick with one's initial thought. Everyone should have to work a retail job to get a sense of what a broad selection of the public is like. Everyone (who is physically able) should have to work in manual labor to get a sense of what hard work is like. Say, 6 months of each. You’d probably get a lot less whining, and people might not be such pricks to cashiers. Ideally a third period would be spent as a nurse or EMT, but that would be prohibitive in terms of training and break too many people.

iagovar 8y ago
Add call centers to that. I basically had jobs in every position of the customer side, and it really helps you to understand many things.
ryandrake 8y ago
Agree completely. Also, (relevant to HN) everyone who writes software or designs computer products should spend some time doing tech customer support. I'm sure we'd end up with better products.
- xapata 8y ago
  And on pager duty. Fewer bugs when they wake you at 3am.
- techsupporter 8y ago
  > everyone who writes software or designs computer products should spend some time doing tech customer support. As someone who's done both, oh yes please, come into "the trenches" and see how customer-facing support, even at the enterprise level, is done and what demands and limitations we face. I have a story on this. I used to work support for a large technology company in the big company software division. Our support tools were pretty limited. We could get logs, we could try to make sense of them, we could ask our peers, and, In Case Of Emergency Break Glass, we could send an inquiry to the developers. This one developer for this one component kept getting upset with us about "how hard could it be" and all that. The problem was, the logs for that component were obtuse. They'd just say "ERR852019" or something like that and we couldn't have access to the source code or symbols to go look it up ourselves and our entreaties for a list of ERR codes was met with "we'll do it when we get to it." Finally, that group hired somebody new and a manager somewhere had the bright idea to send the new guy down to us (support was in a different area, many states away, as these things usually are) to see if the new guy could "straighten us out." We unloaded on him. Poor sod. But, he went away with a vision. He realized the staggering amount of time, effort, and, yes, money being spent on us sitting around getting yelled at by the customers with no real way to help them other than poking the program with a stick and seeing what happened. He championed our cause to that development team and, later, as he moved through the company, made support a priority, if not a focus. Logs stopped just saying "[DATE] [TIME] ERR91" and included full error messages and file paths and even abbreviated stack traces. Senior people on the support teams got access to source code so we could find the error strings and figure out what the program was doing. We even got mini tools we could use to tweak the program to get better logging or maybe even fix the problem for the customer instead of making the (overloaded) development team do it. And the big payoff? We bothered the development people less with "this is making a funny noise" and brought them quality bugs with, in some cases, proposed fixes that saved them time. Oh, and people from the development team started coming down to sit with us "in the trenches" once a year or so.
donarb 8y ago
I worked for a small family run car advertising magazine. The company had two departments, the sales/photography staff who sold ads to car dealers and collected info about each car and the graphics staff who put together the advertising from the car info and photos. There was always a lot of grousing between the two camps that one side did things that the other side couldn't understand and made their jobs harder. The owner devised a plan where each of the employees had to work for a few shifts with the other group to see what their jobs entailed. It made for a better understanding between them and gave each side an idea that the other jobs weren't exactly easy. Made for a better working relationship between the two groups.
- cfadvan 8y ago
  That’s truly brilliant. It reminds me of the Wright Brothers, who would swap sides in arguments to represent the formerly opposing side, as a rhetorical exercise.

iagovar 8y ago

Add call centers to that. I basically had jobs in every position of the customer side, and it really helps you to understand many things.

ryandrake 8y ago

Agree completely. Also, (relevant to HN) everyone who writes software or designs computer products should spend some time doing tech customer support. I'm sure we'd end up with better products.

xapata 8y ago
And on pager duty. Fewer bugs when they wake you at 3am.
techsupporter 8y ago
> everyone who writes software or designs computer products should spend some time doing tech customer support. As someone who's done both, oh yes please, come into "the trenches" and see how customer-facing support, even at the enterprise level, is done and what demands and limitations we face. I have a story on this. I used to work support for a large technology company in the big company software division. Our support tools were pretty limited. We could get logs, we could try to make sense of them, we could ask our peers, and, In Case Of Emergency Break Glass, we could send an inquiry to the developers. This one developer for this one component kept getting upset with us about "how hard could it be" and all that. The problem was, the logs for that component were obtuse. They'd just say "ERR852019" or something like that and we couldn't have access to the source code or symbols to go look it up ourselves and our entreaties for a list of ERR codes was met with "we'll do it when we get to it." Finally, that group hired somebody new and a manager somewhere had the bright idea to send the new guy down to us (support was in a different area, many states away, as these things usually are) to see if the new guy could "straighten us out." We unloaded on him. Poor sod. But, he went away with a vision. He realized the staggering amount of time, effort, and, yes, money being spent on us sitting around getting yelled at by the customers with no real way to help them other than poking the program with a stick and seeing what happened. He championed our cause to that development team and, later, as he moved through the company, made support a priority, if not a focus. Logs stopped just saying "[DATE] [TIME] ERR91" and included full error messages and file paths and even abbreviated stack traces. Senior people on the support teams got access to source code so we could find the error strings and figure out what the program was doing. We even got mini tools we could use to tweak the program to get better logging or maybe even fix the problem for the customer instead of making the (overloaded) development team do it. And the big payoff? We bothered the development people less with "this is making a funny noise" and brought them quality bugs with, in some cases, proposed fixes that saved them time. Oh, and people from the development team started coming down to sit with us "in the trenches" once a year or so.

donarb 8y ago

I worked for a small family run car advertising magazine. The company had two departments, the sales/photography staff who sold ads to car dealers and collected info about each car and the graphics staff who put together the advertising from the car info and photos. There was always a lot of grousing between the two camps that one side did things that the other side couldn't understand and made their jobs harder. The owner devised a plan where each of the employees had to work for a few shifts with the other group to see what their jobs entailed. It made for a better understanding between them and gave each side an idea that the other jobs weren't exactly easy. Made for a better working relationship between the two groups.

cfadvan 8y ago
That’s truly brilliant. It reminds me of the Wright Brothers, who would swap sides in arguments to represent the formerly opposing side, as a rhetorical exercise.