One of the things I love most about engineering is that I get to solve problems. My days, if I can avoid meetings, are full of intellectual challenges that test both my wit and my character. I’m forced to find solutions within constraints, and to take on tasks so big they scare me, because at times the wrong decision can have irreparable consequences and reflect poorly on my standing with my peers. Because, as we all know, it’s the opinions of others that matter most. It can get emotional, because the solution often needs the skill I’m least good at. So I have to confront myself and fight the part of me that wants to avoid failure by taking an easier, less effective route.
All this to say, I love solving problems. But that’s also a problem, because not every technical problem needs solving. At least not in business. The hard part is rarely solving the problem. It’s knowing which problem you were actually asked to solve.
Lost in Translation
Over the past few months I’ve been in meetings with other developers where we tried to turn vague requests from business stakeholders into technical requirements. That conversion from business to engineering is not lossless. We lose nuance. We lose the things that were implied but never clearly said, and that’s nobody’s fault. You can read a poem today and take one meaning from it. Several moons later, after life has tested you, you read the same poem, same words, same author, and it means something else, because you have changed. A voice note from a loved one might mean little now, but if you become estranged from that person, you might play it for comfort. Same words, same person. Different circumstances, different meaning.
A colleague recently suggested I read Derrida, and I didn’t expect it to land as personally as it has. His idea is that meaning is never fixed. It depends on context, and context itself is never closed. That put words to something I’ve lived with for a long time. As an autistic person, my mind processes information differently, and that difference shows up most in communication. The words that leave my mouth often don’t carry what’s in my head, and I don’t always interpret others the way they intend. This is frustrating. At times it’s as though I am crying but cannot wail in a way people can understand. The people closest to me may never be able to comprehend the convoluted ways in which I express my love, and sadly, I may never read their expressions of love for me the way they intend. That conversion, from the depths of my heart to the ears of my loved ones, is not lossless either.
Much of my life has been about learning patterns: which cultural norms apply, and what something means in a particular context. Others seem to bend and reshape context in the moment far more easily than I can. I usually need to sit with my thoughts and distil them, and even then my own tongue can let me down. I sometimes feel like a calligrapher whose ink smudges the moment it touches the paper, leaving me to deal with the mess. Or a blacksmith whose steel refuses to bend the way he envisioned, no matter how much force or heat he applies.
The Ticket That Lies
What I live with daily happens to every requirement that passes through an engineering team. The words in the ticket don’t change, but their meaning depends on who reads them, their biases and their past experiences. We read meaning into things. And our love for technology can blind us, because it colours how we interpret words from someone who isn’t a technologist. So as we rushed to compress requests into technical requirements, we sometimes built solutions that didn’t solve problems. We answered technical questions but not practical ones. The solution helped nobody, yet building it took real effort. For me, the dissonance that follows when a “solution” goes unused is disorienting in an existential way.
I felt this from the other side when I presented at my company’s DevDay, which is like ComicCon for nerds who’ve had to solve a differential equation at some point. To prepare, I did dry runs of my talk on technical debt. Engineers loved it; I could see the excitement. Then someone non-technical would give feedback. They would point to my wording and my cadence, and they didn’t always understand what I meant. To me, none of that mattered. Tech debt is tech debt. But I was told people might not be receptive if I phrased things one way or another. I was told people might get lost if I didn’t pause and leave them room to process what I’d said. It was the calligrapher’s smudge all over again, only this time in front of an audience. I left feeling discouraged and uncomfortable in my own skin. I couldn’t reconcile it. I wanted to do the mature thing, throw a tantrum and just not present. (Still working on the maturity.)
Sitting With It
Instead, I did what I always do: I sat with it. I thought, rethought and journaled, searching for a way to articulate myself that wouldn’t dilute the integrity of the engineering problem while still making it make sense to people who aren’t engineers. I had to fight my own bias, the voice that said just talk like an engineer, because my peers would understand. And I had to sit with the fact that the same sentence about DynamoDB, spoken in my cadence, would be interpreted differently by different people. I didn’t understand the difference, but I forced myself to accept it. For once I was the one standing between two worlds, and I learned that translating between them is a skill, not a byproduct of being smart.
Then I got to watch someone who has that skill. I was added to another meeting (the man upstairs must not like me). It was all engineers, but a business analyst was guiding the conversation. When two people talk, I think they create a context bubble in that moment, where their backgrounds, their biases and the present all mix to produce meaning. She built that bubble for a whole room. She probed each of us when our opinions differed and steered us toward a resolution. Then she did the part I find hardest: she wrote it down. And she tagged me in some of the bullet points. Normally I hate being tagged; it feels like someone ringing a bell and shouting my name in a market square. This time the words next to my name made sense to me. The meaning had survived leaving the room.
The Problem That Actually Needed Solving
We hadn’t just inched closer to a technical solution. We had identified the problem that actually needed solving. Our solution had one intent: to address a business need, not to use the technology we preferred or build the most interesting thing. It was ordinary. It was also effective, and it met its mandate.
Derrida might say words never stop meaning; they just mean something different once they leave the room. A requirement leaves the room the moment it becomes a Java class. So here is my case: we need more business analysts. People who can carry meaning from the boardroom to the codebase without letting the ink smudge on the way. I still love solving problems. I’ve just learned that the most valuable one I worked on recently was one someone else helped me define.