Don't answer the first question - Lalit Maganti
In my work on Perfetto, a performance debugging tool, one question I get often<br>is: “how do I split a Perfetto trace into multiple files?” Instead of answering<br>directly, I say: “there isn’t an easy way to do that, but what’s leading you to<br>collect traces large enough to want to split?”<br>This is one of my golden rules at work. When a user asks me something “weird”:<br>don’t answer the first version of the question.<br>On the surface this might appear like I’m talking about the<br>XY problem, but that stops one step<br>short. It treats the user’s stated question as a puzzle to decode: figure out<br>what they really meant, answer that, move on. I think we can go much further.<br>Instead, the confusion that produced the wrong question is itself an opening,<br>and the conversation it sparks is valuable to both sides. The user walks away<br>with a better mental model of the tool. I walk away with a clearer picture of<br>where the product confuses people. And sometimes, between us, we figure out that<br>the product itself needs to change.<br>I’ve written before about how I can still be a successful engineer while<br>avoiding the spotlight.<br>While that covered the general strategy, this is one of the concrete tactics<br>that makes it work. I should also say this post is aimed at people who build<br>things for other engineers. If you’re building a consumer product, or a B2B<br>service, it will translate less directly, but the underlying instinct might<br>still be useful.<br>Diagnosing the ask<br>Some questions are easy, routine, and purely a matter of pointing at<br>documentation; those don’t merit much discussion here. The interesting cases are<br>where something is out of the ordinary, and it’s rare that the user will have<br>given me enough information in their first ask1.<br>So I run a mental checklist to figure out where to go next:<br>Have I seen this before? If so, I might already have an answer to hand. If<br>not, it’s uncommon enough that I want to slow down.<br>Does the question even sound reasonable compared to others I’ve seen? If not,<br>why might they be asking it, and is there a more normal question underneath?<br>Does it fit the shape of the tool? Or is the user fighting the architecture<br>without realizing it?<br>Once I’ve figured out what feels off, the next step is asking something that<br>will surface the missing context. I might say something like “well the answer to<br>your immediate question is X but that’s a pretty strange thing to ask for<br>because of reason Y. Can you tell me more about the wider problem you’re trying<br>to solve?”<br>This will probably be the start of a back and forth. How quickly it moves<br>depends on how well the user can communicate their thoughts. But we’ll usually<br>end up in one of a few places: they’re missing the philosophy of the tool, the<br>product is hiding the right path or the product itself needs to change.<br>When they’re missing the philosophy<br>It’s quite common for users to come to us not knowing what they want, or not<br>understanding the problem they’re trying to solve.<br>To be clear, I’m not criticizing them for this; teams are often trying to solve<br>problems with limited time or resources, and they turn to new debugging tools<br>when they’re struggling to make progress. As a result, they often find the tool,<br>find it does most of what they want but doesn’t match their model of “how it<br>should work”. So they file a feature request.<br>A common version of this: people come to Perfetto, see that a trace is a highly<br>detailed recording of what a device did over a window of time, realize you can<br>compute metrics from a Perfetto trace, and treat it as a holy grail solution to<br>all their problems. Want a frame rate? Count frames in the trace. Memory used by<br>an app? Look at the allocations and frees. In principle, any metric could be<br>computed from a trace.<br>But this is a bad idea for a simple reason: traces are expensive to collect and<br>process: you’re collecting all the data about the system rather than samply a<br>single number. You’re going to waste a lot of resources when instead, a<br>dedicated metric collection system would do the job much more<br>efficiently2.<br>My overarching point is that there’s a certain philosophy to how tools are<br>designed, and users often miss it because they’re focused on their immediate<br>problem.<br>A big part of my job is teaching the team how to approach performance<br>engineering in the first place, not just explaining how to use Perfetto. It<br>means making people aware of the tools they have available, how to think about<br>things like startup, frame drops, memory, and power, and how to work with them<br>both in normal situations and when something goes wrong.<br>When the right path is hidden<br>Other times the team understands the problem; they just don’t see how to put<br>existing tools together. Our tools are powerful by design, and we have to be<br>mindful...