Technical Tradeoffs

When you first start off at almost anything you can only advance linearly. If you want to start to get fit, your cardio is probably as bad as your weightlifting which is as bad as your flexibility. Some people might naturally have an advantage towards one or the other, but progress in any of those domains helps you progress in all of them at the beginning. Once you make it through the beginner stage you face a choice - do I put more effort into one of these and gain outsize rewards or do I try to distribute the benefits?

To answer that question you have to know what you want - do you want to lift heavy? Dance for hours? Touch your toes…with your elbows? Perhaps you want to be a generalist - a good balance of all three. I see this same tradeoff in engineering all the time - and with two examples in particular. First, what to do with your career - should you focus on one particular thing or specialize? Second, how do we build this current system? (Captured in jargon as CAP theorem)

Balancing tradeoffs and understanding that you can’t get everything you want is a hallmark of wisdom, extremely hard to internalize and also very useful in building reliable, scalable systems. I can mark when in my career I truly felt that I had finished my transition from junior to senior. 2018, I was re-factoring a large system which worked well and served the current use cases, but was brittle to new changes. The org we were in was growing rapidly with 10+ feature integration requests coming in every month. We were a team of ~4 and had to pay down technical debt as well as deal with incoming tickets. This was overwhelming - and switching to the new system would essentially freeze development all across the greater 150-person org for a quarter.

I tried burning the candle at both ends - the team would answer tickets and work on the new system, launching it quietly and turning it on for a small percentage of user traffic. People were upset they had to double the work and their existing requests weren’t being processed fast enough. I tried compensating by pushing the deadlines of low priority projects and trying to speed up my team, but people were still upset. If I was going to continue on the path of building the system we needed, I had to accept that people were going to be upset. I couldn’t - I was too much of a people pleaser and I mistakenly assumed that people would only be upset and complain if it were a serious issue. Turns out some people just like to complain, sometimes as a means of getting things done.

I shifted tactics to cater more to existing client tickets at the expense of work on the new system. This turned out to be a mistake in the long run - there was a very clear tradeoff - 2 months of people being very upset at not being able to launch new features or 6+ months of trying to make everyone happy while building our new system. I look back often and wonder why I chose to make everyone happy. Part of it was the culture of Google, part of it was the last ‘junior engineer’ optimism still in me. I believed that with my labor and genius I could get all of it done, on time, faster than expected. I however was a subject of the Peter Principle. My past successful projects had led me to a position where I could not be successful using the same techniques. I remember sitting there in the post-launch evaluation of our project, once we finally burned through all the user tickets and turned it on for the whole world to see thinking “Huh, I would have happily traded the past 6 months of split focus for just 2 months of intense complaints.” Many of those incoming integration requests never actually materialized, many tickets disappeared because the project was in a state of flux. In truth, we had a lot more time to fix things up. And no one would remember being upset (turns out this is a somewhat unique Saurya feature, to hang on to times when someone upset or disappoint you and prosecute them forever in the court of your mind).

I think the real tradeoff I have to make in the future is how much I trust the person in front of me versus my own instincts about how the project will go.