How I Learned To Stop Worrying and Love the Engineers: cross cultural clashes between Support and Engineering (and some ways to fix them)*
It's possible to do Support work while knowing absolutely nothing about the underlying architecture. Support doesn't necessarily know why the product works, or even what language it's written in. It can be super tempting for an engineer to think that well, if these support people really had the competence and capacity to understand how the thing worked under the hood, then they'd be engineers and not mere support people, but that's a bad trap to fall into. Sometimes Support people are engineers in their own right, but a Support person with no computer science training can be an expert on the user interaction surfaces of the product and reproduce a result that has been baffling the engineers, even with no knowledge of the mechanism by which the bug is happening. It's helpful to give Support enough information about the architecture to have a better starting point for asking the user for details and trying approaches to replicate the problem.
It can be tempting for Support to think that any given member of Engineering understands the entire breadth, depth, complexity, and interconnectedness of the entire product simultaneously at any given time, but this is a trap! A good amount of time Engineering has no clue in the slightest about what is going on in another branch of the product, and in a sufficiently complex codebase, there can be millions of lines of code that a single particular engineer has never touched or even heard of. Or it's been long enough since they worked on that part of it that they would have to take several hours of very hard study in order to figure out what's going on. In particular, sometimes in a bug report, Engineering can say "Okay, I see what *part* of the code the user is causing to fire, but I haven't the FOGGIEST idea how the customer actually got that to happen." It's very important for Support to list out every single step (even the ones that seem obvious) that leads to the error occurring.
Technical Support and Engineering should work together harmoniously for the good of the project. This doesn’t always happen. Explore some common misunderstandings between technical support and engineering cultures, and some steps that you can take to make both Support and Engineering more tolerant and friendly of each other, better at their roles, and better at communication.
- A brief exploration of some elements of Technical Support culture
- A brief exploration of some elements of Engineering culture
- Some cases where crossing Technical Support and Engineering went very wrong
- Some cases where crossing Technical Support and Engineering went very right
- Some concrete actions to take to improve the mutual understanding and relationship between Technical Support and Engineering
cultural misunderstandings, technical support, technical support culture, engineering culture
Rev. Lunatic has spoken at past Open Source Bridge conferences. This is the first time they have given this talk as an organized talk instead of a passionate rant over drinks or in IRC.
Specialist in Yelling as a Service. New contributor orientation specialist, code tour guide, and spamwhacker at Dreamwidth.org. Reader, writer, crocheter, geek.
- Title: Yelling As A Service: Adventures in Unofficial QA
- Track: Practice
- Room: B302/303
- Time: 3:45 – 4:30pm
What goes into making a helpful bug report, if you’re not even given access to the repository? Why should you, the user, report bugs? How do you navigate a series of gatekeepers who don’t want to acknowledge your bugs? How do you maintain a good relationship with people in charge of a project that’s screwing up your whole life?
- Speakers: Azure Lunatic