Dear reader,

It feels extremely vain to write a post reviewing my 2021. The intended audience of this post is just me but I hope you derive some value from my exercise in vanity. At the end of this post, I have a list of notable things I read this year with some links. Feel free to jump to the end.

It’s been a while since I wrote here, but perhaps this will explain why. In June my daughter was born. It has been an all consuming experience since then. Both the highs and the lows have been extremely intense and I love being a father.

To add to that I changed jobs twice. In March, I left Booking.com after having worked there for ~6 years to join Messagebird. Around 7 months later I left Messagebird to join Stedi. Messagebird was a great place and I would strongly recommend it to anyone who wants to work there but I couldn’t say no to the opportunity at Stedi, I definitely intend to write a post as to why I am so excited about the opportunity at Stedi.

Each change of job involved a change in stack as well. I went from a mish mash of perl/java stack running mostly on-prem with a sprinkling of kubernetes to golang running on AWS and eventually typescript and hardcore aws serverless. It’s been breathless and while my breadth has been stretched, the depth I have acquired is surprisingly shallow.

One thing I was happy about was how much more hands on my jobs at Messagebird and Stedi have been. At Booking.com, I sometimes felt I was doing a lot of glue work and not too much hands on work. I am glad that has changed.

At a personal level, I found this year to be harder than 2020. We went from mostly being in lockdown to mostly taking care of a newborn and learning on the fly. I had my worst year in terms of exercising since I started exercising regularly about 4 years ago.

I did manage to read a few good things in between all the nappy and job changes. In no particular order these were the most memorable ones:

1. The Goal: A Process of Ongoing Improvement

The Goal explains the theory of constraints in the form of a story, but I think thats underselling the book. I think for me the book was a revelation in how to think about global goals of an organisation instead of optimising for local efficiencies which happens very naturally in most places. The other thing that I liked was the debugging organisational issues from first principles. I strongly recommend this book.

2. Invent and Wander

Invent and Wander is mostly the Amazon shareholder letters penned by Jeff Bezos and they are full of really great insights on how Amazon was built as a company. Particularly interesting is the relentless focus on the long term, the appetite for big failures and the consistency in thinking about things for over 20 years. Every shareholder letter is amazing but if you are curious as to whether you want to read all of them, I would recommend at least reading the following shareholder letters:

• The first shareholder letter from 1997 - The principles introduced here are often referenced in later shareholder letters.

• Taking the long view from 2000 - The letter right after the dot com crash.

• Building a culture of high standards from 2017 - Probably my favourite!

3. Working Backwards

Working Backwards covers various aspects of how work is done and thought of at Amazon. There were a few things that stood out for me.

• The sheer number of concepts that came out Amazon and which have been picked up in the industry - two pizza teams, bar raisers, single threaded leadership and increasingly writing memos instead of powerpoint.

• The constant focus on process improvement informed once again by first principles. While reading the Goal, I often kept thinking of Amazon and how similar the thinking process was.

4. No Silver Bullet

Well, this is cheating, kind of. This is a paper written in 1986 by Fred Brooks and is part of the Mythical Man Month. But I had to mention it as its one of the most profound bits of writings I read this year. The paper posits that there are two types of complexity inherent in building software - accidental complexity and essential complexity. Essential complexity is a function of the problem space and has to be solved. Accidental complexity is a function of how we go about solving the problem (the toolchain we use, the methods we use etc). After reading this paper I started thinking more deeply whenever I find a hard problem - is this complexity essential? I strongly recommend reading it.

I am extremely optimistic about the next year. Like everyone, I have plans to do things better in the next year. I intend to share them here but that will have to wait and hopefully not > 6 months like last time.

I am off to enjoy dinner with my wonderful wife who has made this really tough year into the most memorable of years.

Hope you have a good one!