Item 50: Embrace the Chaos

Almost all of the items in this section dealt with change; changing of people working on the codebase, changing of the idea of the codebase itself, changes in dependencies that the codebase relies on, changes in the world that affect how the product is used. More specifically, though, it talks a lot about dealing with change. "Handling" change. Until this point, we've looked at the concept of "change", of "volatility", as a necessary evil, a bad thing that disrupts you and forces you to put mechanisms in place to cope with it.

But there's another way to look at change: as a good thing. Imagine that you have a codebase for a product that's gotten some traction, but not much. That said, you've architected it to deal with constant change. You've written robust E2E tests. You've abstracted away all of your dependencies. You've ensured that the major ideas of the product shine through in the code. You've invested in making sure your team has the knowledge and the empowerment to feel like the idea representation in that codebase is theirs. Suddenly, the world shifts. The company you work for is pivoting in a brand new direction and all of a sudden, your product is now at the forefront of next year's objectives. You have to quickly scale to meet the demands of all of the new anticipated users. You have to add a very complex set of powerful features for Fortune 500 customers. You have to quickly hire and onboard 10 new engineers by end of Q1, almost 3x the current size of your team. Look at what happens here. Because you have planned for change, you have anticipated it, embraced it, you have fortified yourself against many of the negative aspects of it. Because you have fortified yourself against the negative aspects of it, something amazing happens: you are able to accommodate it, and allow it to be used to your advantage. You quickly onboard your new team (thank goodness for your excellent recruiting partners!), they scale up quickly, and the codebase gets worked on without minimal friction, far exceeding the expectations of your leadership chain. Tasks are delivered in a reasonable time-frame. Pre-existing functionality is preserved for current key customers, so retention remains strong. That one crazy algorithm a very passionate dev on your team wrote that was only used in a few places now starts to power critical components of your system. Congratulations: you have hacked change.

If you plan for change, and minimize harm when it occurs, then the only thing that can happen is that you benefit from it. That is the beauty of embracing change, and that is what effective communication can give you. The world is constantly moving and shifting and sending you signals, things are constantly smashing against one another causing chain reactions and paradigm shifts and ecosystemic disruption, and it's all happening at a mile a minute. By sharpening your communication skills, you will be able to quickly and accurately process that information coming at you. You will then be able to adapt to that information by using the techniques you've picked up in this book. But also, you will be ready, when that fateful day comes, when you and your team are called upon for that P0 mission fulfillment, for that all-or-nothing project, to deliver. You embrace the chaos, and then let the chaos work for you, not against you.

I became a software engineer because I wanted to help people, plain and simple. I hope that, if nothing else, this book has helped you to do just that.