The Antifragile Developer
What if you could benefit from stress, chaos and disorder? On becoming antifragile as a developer.
The world out there is fast, interconnected and (especially these days) packed with uncertainty. Rare events happen quite more often than either anticipated or acknowledged. I'm speaking of such rare events which change the way you live your daily life. The downside or upside of such events depend highly on your current way of living.
The Fragile World We Live In
We are currently enduring such rare events. A pandemic followed by a global economic crisis. Granted, pandemics happen rarely. But they happened before. Economic crisis happen not as rarely as we think or we're being told. Also, economic crisis happen on local scales as well. It could be a job loss caused by a change in an industry, change of customer behaviour, competitors that won market share and your services aren't able to compete anymore, the management was changed and things work differently now, legal changes,...
As software developers, we're facing rare events as well. Events such as technical issues. Your service is disturbed by network issues (they really don't happen that rarely), a service provider you're relying on is down, a 3rd-party library you're using introduced a severe bug, you yourself introduced a severe bug, the planned feature was completely underestimated and consumes a lot more time and resources (technical and financial resources), the platform you'd like to distribute your app on might reject your app because it does not implement certain platform-specific features,... Just to name a few.
What if we could benefit from such rare events? Can we at least protect us from the downside? Even introduce an upside we could benefit from?
The last months I've been working through Nassim Taleb's
Incerto Series. It took me a while and I'm still not completely done as they are not books one reads in just one go. At least not me. Every few paragraphs I had to stop and think about what I read. Not because the topics were hard to digest, but because of different viewpoints, ideas, thought patterns, etc. I picked up. I highly recommend the series to anyone who's interested in anything related to probability and uncertainty in daily life. You might not like his style, though. Be warned. But I do like it. So much so in fact, that I'm on the verge of getting the high priced
Deluxe Edition. But that's for another day.
The one book of the series which stood out to me the most was (and still is) Antifragile. If I could pick only one book to read for the rest of the year, it's this.
Know What to Look For
So, Antifragile. What is it? In short, the opposite of fragile. Obvious,
isn't it? Well, not so fast.
"Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better."
- Wikipedia, Antifragile
This word didn't exist a couple of years ago. If I'd been asked "what is the opposite of fragile?" a couple of months ago, I probably would have answered: "robust". But it's wrong.
In situations of stress, chaos or disorder
- fragile things lose
- robust things are indifferent
- antifragile things gain
See? Robust can't be the opposite of fragile, as it doesn't behave the opposite way under the same circumstances.
With this in mind, we already have plenty of food for thought to examine the systems we have built or are currently building as software developers and how they behave in daily life situations, especially under shocks.
What we build as software developers, what we build as companies, how companies are built, how systems in general are built and behave in different situations. We can even view ourselves and our positions, roles, skills, believes, etc. as systems and examine how each system performs in daily life under volatility.
Becoming Antifragile
What systems we identified are fragile? Does the fragility of a system mean ruin under situations of stress? If so, can we avoid ruin? What do we need to do, so they become robust or at least less fragile and won't lead to ruin anymore? Can we even create systems which benefit from shocks?
Before our systems or we ourselves can become antifragile, the systems need to become robust. There are probably different ways to build antifragile systems. But to me, the most intuitive one is to first avoid anything leading to potential ruin. Nassim Taleb mentions the Barbell strategy a few times.
Once explained and understood, it makes sense how this strategy can potentially lead to antifragility.
In finance, a barbell strategy is formed when a trader invests in long and short duration bonds, but does not invest in Intermediate duration bonds. This strategy is useful when interest rates are rising; as the short term maturities are rolled over they receive a higher interest rate, raising the value. Taleb generalizes the phenomenon and applies it to other domains. Essentially it is the transformation of anything from fragile to antifragile.
A dual strategy, a combination of two extremes, one safe and one speculative, deemed more robust than a “monomodal” strategy; often a necessary condition for antifragility. For instance, in biological systems, the equivalent of marrying an accountant (stable life) and having an occasional fling with a rock star (good fun); for a writer, getting a stable sinecure and writing without the pressures of the market during spare time. Even trial and error are a form of barbell.
- Wikipedia, Antifragile
Meaning quite simply, if most, say 95%, of your systems are robust and are indifferent towards shocks, you can tinker with the other 5% of your systems. Provided, none of it leads to ruin. This part is important. The downside needs to be small and limited.
While 95% of your systems are robust and keep you going no matter what, you can focus on things with limited downside and potentially unlimited upside. Then, use the potential payoffs to get you ahead.
Becoming an Antifragile Developer
Much of my daily life I spend with developing software. So, naturally, I've started to apply the Barbell strategy and search for ways to make systems more robust at first, and maybe even antifragile eventually.
Actually, it's not something I've just started. But I do it differently now. More deliberately. More effective. Many of us working in tech probably experienced fragility first-hand at some point in their career. A service or website going down because of network errors, hardware failure, bugs, a wrong command, a faulty SQL statement in a migration, and the bells of alarm start to ring. We already know about fragility and robustness. Intuitively and from experience. But the concepts of antifragility, the resulting thought patterns, frameworks and strategies give us new words and viewpoints to talk about.
We can challenge believes from a different perspective.
I can analyze systems and try to understand how it, or some of the parts its made of (subsystems) behave under volatility (e.g. stress, chaos, disorder, uncertainty). Is it fragile, robust, or antifragile? Understanding a systems characteristics, I can then challenge how the systems currently are built. What part needs to be rebuild. What needs to be added, or removed. Or even challenge its existence as a whole.
Walk Before You Run
Let's make this concrete for a moment. Take a static website. Websites can be built in various ways. Many different components can be involved, such as servers or databases, services for authentication, analytics, handling images, services to import data from different sources, build artefacts, backups,... But a static website is a very simple thing providing already enough value for many use cases. Write content and publish it. It can be just a Phoenix application reading Markdown files from disk at build time. Much in the same way as described by Jòse Valim in this blog post. It allows one to abandon a complex system such as databases. A backup system can simply be a GitHub repository storing the static content and a Docker image which can rebuild everything from scratch and then serve the content from basically anywhere Docker can be run. The pages are precompiled and served with little effort and low operational costs. This allows for a robust system which doesn't really suffer under stress (e.g. high amount of concurrent requests). Granted, publishing new content with such a system is not for everyone. To publish new content, you'd know which commands to run to compile, release and deploy a new version. But it's the baseline for a robust system. From here on out, one could use the Barbell strategy and aim to make the publishing process more
user friendly. 95% of the system should stay the same, with the remaining 5%
I'd try to tinker with and find a way to reach the goal.
One might ask: "If you wanted to make a robust blog, why pick such a young language and ecosystem such as Elixir? Isn't it prone to be fragile?". Well, yes and no. Elixir is the 5%-part of my current Barbell strategy of my professional career. More on that shortly. But why does it not increase fragility in this case? Let's examine again what a static site is made of (mostly). Broadly speaking, it's a couple HTML tags (plus little framework specific template syntax) and some CSS. The content is stored in separate Markdown files. Parsing Markdown and putting it in an HTML div can be done with many programming languages today. If I had to decide to move the blog to a JavaScript based system (JavaScript is at the time of writing one of the biggest ecosystems regarding websites), I could do so probably within a few days. So, betting on Elixir would not ruin me even if it turned out to be a failure. Right now, it's actually doing the opposite because...
Making myself robust is another task I'd quickly aim for.
The Robust Self - Learning to walk
I'd examine myself as a system, or rather my skills within a company, a niche of an industry or the industry itself. Given that my current financial system only grows from one income stream (my job as a software developer), I'd better do my job right. No job, no income. Rather fragile. So, first things first, make myself robust. How? By being good at what I do. I learn and gain experience at every possible occasion. Then, Barbell strategy. I've started out as a Python developer. Most of the time I wrote Python. But I also knew some JavaScript. I didn't know it at the time, but I was using a variation of the Barbell strategy. Out of pure interest and curiosity, I learned more and more other languages, concepts, architectures, ecosystems,... until I could consider myself good enough to play on different fields; backend and frontend development, operations, UI/UX design,... Nowadays, I handle customer requests, plan and build features and services, write and test software for mostly frontends (hence, mostly JavaScript/Typescript).
Searching for Antifragility
It turned out to be quite a robust system so far, even with all that's going on right now (the pandemic, the market downturn). But it's not antifragile and probably will never be. But being robust gives me opportunities to play on other fields.
JavaScript will be around for a bit longer and I've gained quite some specialized experience. I can still fulfil new business requirements. However, I suspect JavaScript won't be around forever. No language ever did and even those which played a big role at some point, don't play that much of a big role today.
Therefore, my current 5% is learning Elixir, its ecosystem, and learning more of the business side of software. Especially the last part may lead to systems which benefit from shocks.