The :q!

Details in this chapter have been changed, combined, and generalized to protect others’ privacy. This is not a description of any specific individual or company.

I spent seven years on a team where I knew how to be effective. My teammates and I worked very well together. We had the same values around the craft, how things should be built, and that honest code reviews and nitpick comments were fine. We can have discussions that only last a few minutes but landed us on the same page. However, after seven years, I could feel my work flattening out. I was still useful, but I was no longer surprised by the problems in front of me.

For a long time, I had been good at my job in a way that felt dependable and quiet. I could walk into almost any problem and feel my brain click into place. I knew who to ask. I knew which questions to ask. I knew the invisible map of what mattered, what didn’t, what was urgent, what could wait.

A former teammate I trusted mentioned an opening on his team over lunch one Friday. It wasn’t pitched as a life-changing move. It was mentioned casually, like a fact about the weather. I nodded, pretended it didn’t matter, and kept eating. Later that night, it came back to me and I knew it was something I had to try.

The next week, I asked him what the work was like on that team and about his general experience. I asked if I was being naive moving into a field I really didn’t know much about with only application development experience. The answer he gave was honest: it would be different enough to feel like a different career for a while. That should have scared me more than it did but I was still living in the comforts and confidence of my current team.

I was seeking to expand my horizons. At the time, I felt like I could handle almost anything if I had a debugger, an IDE, and enough time. I wanted to take what I’ve learned over all my experience at the company and see how far it can travel in other areas of software engineering. I had spent a long time at the company already. I knew that making this move would probably be my last move before finding somewhere else to work. I knew it was time to take a chance. I did not want to stay in one spot forever and just be treading water. I wanted to find out whether my skills still held up outside the environment that had made me comfortable.

The New Team

On my first morning with the new team, I didn’t just want to look competent. I wanted the kind of belonging that lets you ask a half-formed question without worrying you’ve exposed yourself. I wanted to know who drove decisions, what counted as urgent, and which gaps in my understanding were normal versus embarrassing.

Most of the team spoke another language outside formal meetings. Meetings were the only place I could reliably follow the work, and even there I felt like I had joined a show in the middle of the season. The problem wasn’t only comprehension. It was that the casual, high-bandwidth conversations where context gets transferred were happening around me, not with me.

No one was openly unkind. It was probablyIt was probably the language they naturally fell into with each other. But the effect was that I felt stranded inside my own workday. I sat at my desk trying to figure things out the whole day, trying to catch someone in between meetings to ask questions. But there was no support structure I could lean on the way I had before. No real working relationships yet. Every day felt like I was spending hours pushing on problems I didn’t even understand well enough to describe.

At first, I told myself this was normal beginner discomfort. Some of it was. What I missed was that my confidence had never been purely individual. It had been built out of shared context, trust, and the ability to ask a half-formed question and still get help. On the old team, that support was invisible because it was always there.

My first project was a schema migration. At a distance, it looked straightforward: take one format, map it to another, and standardize the output so future changes would be easier to manage. The pitch made it sound like a transformation problem. It turned out to be a context problem.

In practice, it was a project built out of hidden context. There were over 2000 services to account for, each with its own decisions baked into its schema. The possibilities were endless, and it felt nearly impossible to come up with all the right combinations.

I spent days reading docs and internal notes. I could explain the goal back to someone else, but I still couldn’t reduce the uncertainty enough to make good decisions. Each time I tried to start, I ran into the same problem: I needed answers to questions I didn’t know enough to ask clearly.

I opened Slack and stared at the names of people I vaguely recognizedI hovered over the name of someone I had known for years and thought about asking a question, but my pride got in the way. I didn’t want to be that person who transfers and immediately drags their old team member into their new problems. I didn’t want to use anyone as a crutch. I told myself it was pride (and it was). I told myself it was professionalism. I told myself I would figure it out and that I was good enough to be on that team, without any help.

Weeks passed without the uncertainty shrinking. I could produce output, but I wasn’t actually de-risking the migration. Each apparent win exposed another class of failures behind it.

I slept badly and started each morning already depleted. Opening my laptop felt physical; I would hesitate before touching the keyboard. The dread stopped being a Sunday-night feeling and turned into background noise. What made that harder to admit was that I had loved this job before. I used to look forward to solving problems with my team. Now I was measuring the week by how far away Friday was.

I tried to get time with people who understood the system. Sometimes I got it; often I didn’t. No one was malicious. They were busy, and unblocking someone else rarely looks urgent unless you are the stuck person.

Eventually I built a prototype that recursively translated the schema patterns I had seen so far. It worked on the narrow sample set I had modeled against, which gave me a brief sense of relief. Then we ran it against a broader set of services and it fell apart. Cases I had treated as edge cases were common. Local decisions I didn’t know about turned out to matter. The prototype hadn’t uncovered the path forward. It had only revealed how much hidden variation I still didn’t understand.

The failures didn’t just exist in logs. They showed up in the places where progress was tracked, discussed, and judged.

It wasn’t framed as “this is normal when you scale a prototype.” It was framed as evidence. Evidence that I wasn’t moving fast enough, evidence that I wasn’t seeing the obvious patterns, evidence that I was the problem. But was it that?

I learned something that seems obvious in hindsight: the real work wasn’t converting a schema. The real work was discovering all the ways people had already deviated from whatever “standard” was supposed to mean. There were too many systems. Too many variations. Too many edge cases that were only obvious if you already knew where the bodies were buried.

The response was not to reduce ambiguity. It was to increase pressure: move faster, search more code, find the patterns.

I responded the way engineers often do: I made lists, categorized failures, and tried to turn the mess into a system.

I started working longer hours out of desperation. I kept trying new possibilities, writing new test cases, duplicating schemas so I could check that each change wasn’t introducing regressions. I wanted to prove to myself that I was making forward progress in the form of passing tests and green check marks. However, trying to cover the possibilities over 2000 services was futile. I wasn’t ever going to get through it in the timeline leadership wanted me to.

There were days when I pushed as hard as I could against blockers and ambiguity and ended up in tears during my late night frustrations.

One night, I turned to my husband and asked, “Can I just quit my job?”

He told me to give it more time. I hadn’t been new in a long time. I spent several years on my old team. Maybe I just needed a little runway. I wanted to believe him because the alternative was terrifying.

Over time, he saw what I was actually living inside. We stopped talking like this was a temporary rough patch and started talking like we needed a plan.

Around then, I started a side project because I needed a form of programming that didn’t make me feel trapped. One night, while half-looking for another job and half-looking for a distraction, I started building a tool to make system design interview diagrams easier to sketch and adjust. I wasn’t trying to launch a startup. I wanted a problem with a clear user, a clear scope, and feedback I could trust.

I wanted something easy. Something that is meant for the job. No more Google Drawings or Excalidraw. I started with the smallest useful interaction I could think of: place a box, drag it, connect it, and redraw the lines cleanly when the layout changed. That tiny loop was enough to make the project feel alive.

Thirty minutes on that project felt completely different from thirty minutes at work. On the side project, I could make a decision, implement it, and immediately see whether it improved the tool. That loop made me feel sharper, not smaller. At work, I was drowning in hidden context. On my own project, I could still move.

On low-energy nights, when I couldn’t bear to keep debugging, I could still open my own code and feel like I knew I could build things despite the struggle I felt at work. I could make a lot of progress, explore new ideas, talk to my friends about it, and be excited.

It is hard to watch a version of yourself you trusted stop showing up at work. I had said I wanted to be a beginner again. I had not understood how quickly beginnerhood can turn into humiliation in an environment that does not support learning. Capability is not a fixed trait. It depends partly on whether the system around you lets you ask, test, and recover.

I had heard plenty of engineers say that when work was bad, coding at night was the last thing they wanted. In many cases, that was true for me too. This time was different.

The side project did not fix my job. It did something smaller and more important: it gave me back a form of progress I could trust.

In one of the worst stretches of my career, the side project proved something simple: I could still sit down, make decisions, and build. Work had made me doubt my ability. My own code reminded me that the ability was still there.