It has been since I sat down to write an article properly, since most of my off-work time has been put into my podcast. With the lockdown situation continuing for the foreseeable future, production has been a bit more difficult, so I thought I give the good old blogging another shot. This week I want to discuss adaptability, a virtue that I rarely see discussed in the industry and in my opinion absolutely essential to being a productive software engineer.
This article is a mix of my personal experiences and proper reasoning and arguments, which is how I like to write. That being said, I am sure not everyone is interested in my individual life, so feel free to skip past any anecdote and stories. And without further ado, let's begin!
- How did I come across this?
- "Sure, but why do I have to be adaptable?"
- Adaptability for software engineers
- "Great! So how do I become more adaptable?"
- Closing words
The topic of adaptability is by no means a sudden choice, and goes back to a couple years ago for me. In 2013 I was applying to various universities around the world, and one of the most common questions on the applications was
What is your biggest strength?
I spent a good few weeks thinking about this. Is it hardworking that helped my grades, or honesty that led me to good friends? I came up with more virtues as a 17-year-old possibly could, but none of them seemed to be the answer for me.
The answer came to me, as many others do, in the form of an episode of The Big Bang Theory:
"I am nothing if not adaptable."
Comic as it may be when Sheldon said it reacting to being pranked with unexpected dinner choice, I found this to be very true for myself. Moving to a city by myself a year earlier, I needed to adapt to a new environment and lifestyle. And with the prospect of moving again for uni, I felt like my ability to get comfortable and productive wherever I am were the best edge I had.
Consciously or otherwise, the following few years did prove exactly that. I have moved a few more times for various reasons, and I can confidently say that I have adapted to each to the best of my abilities. Recently I came across a post about taking feedback in code reviews, and added a comment about how I adapted to it since I started working full time as a software engineer.
With this tiny reminder, I felt like it was time to offer my own two cents with a proper post.
Before getting into detail about how adaptability is crucial in the tech industry, there is a fundamental point to made here. Humans, or any other organisms for that matter, have been adapting for as long as history can tell: "Survival of the fittest". We are always adapting to the situation, and changing our ways to make the best of things. Adaptability isn't a special skill that you have to learn; everyone has it already. It's only natural.
As a software engineer, we have all heard and experienced how fast and drastically the tech world changes (remember when you have to dial the phone to get on the Internet?). Languages, frameworks, technologies come and go all the time. Sooner or later, you come to a point where what you know isn't useful anymore. As Albert Einstein said:
The measure of intelligence is the ability to change.
For example, for the longest time I thought a backend server is where you put your business logic, and there is no other way. When I approach a new project, I always put up a server in some VM, and it just felt right. Then a couple years ago, SaaS (Software as a Service) came out of nowhere for me. Suddenly you can just write individual functions and expose them to your client, without the form of a server at all. I couldn't not see the benefits of this approach, and gradually shifted my thinking to that. Painful as it was in the beginning, this went on to boost my productivity to a whole new level. Adapt yourself my friend, there's always fruit for your labour.
I hope now you are more convinced about the usefulness of being adaptable. But what does it mean to be an "adaptable software engineer"? This is by no means a complete list, but what I consider the strongest indicators from other engineers that I look up to:
Software is written to solve problems, and there are many ways to solve the same problem. An adaptable engineer is aware of the particular constraints of the problem: latency, computing resources, or even availability of the team. With this in mind they move to find the best option that suits these constraints. Most of the time these constraints pop up unexpectedly, and they must quickly understand them, and readjust to make sure nothing blows up.
Software development is a bigger field than most of us realize, and you will encounter problems in areas that you probably did not know existed before. An adaptable engineer is able to shift their technical mindset into a particular field, and analyze the problem in the appropriate domain language. If it is a user interface problem, then they think in a matter of time and events. If the problem is about complex logic, they think in a matter of data and flow.
Code is only one thing that we interact with day-to-day; there are also other engineers, designers, users, and many more. An adaptable engineer is able to communicate to each front in an effective way, acting as a interpreter of sort. They understand what users want, and translate it into hard logic to machine.
Adapting seems like a reactionary action, but the truth is far from it. An adaptable engineer keeps a keen eye for improvements, whether it is code or the product. They know that adapting does not only happen in the dark days, and in fact continuous improvements is a better route to success than a pinch overhaul.
I believe one does not become adaptable in a day, and many of these indicators seem too hard to achieve. Honestly, I am also in the very early stage of my career, and I have no clue how one stays adaptable 10 years down the line, having moved from position to position. But below are a few advice that I have, many of which were given to me by the best engineers that I know.
The first and the most important principle of being adaptable is willing to do so. Way too often we hung on to our intellectual products, because we thought and worked hard for it. As Adam Hunt wrote in The Pragmatic Programmer: From Journeyman to Master:
The greatest of all weaknesses is the fear of appearing weak.
Just like the post that inspired this one, the code that we wrote does not always represent us as engineers. The decisions we made earlier might not be the best now, most of the time through no fault of our own. Rather than disregarding the risks and persistently sticking to our guts, we might have a better chance if we listened and adjusted.
A cliche phase I know, but I have found this be a incredibly useful principle for calibrating yourself. When you are presented with a problem, understand the core of the problem itself. And when you are trying to solve it, and having to adapt to various constraints, always remember whatever you shift to do should help you get closer to solving the core problem. In the past I have had episodes where I tried to change direction when hitting a roadblock, forgot what I needed to solve in the first place, and ended up with something totally unusable. Don't make my mistake.
Inertia is an ironically powerful force. You should be looking out for opportunities for adjustments, rather than being forced to one when your car has metaphorically ground to a halt. A useful tip that I have adopted is having sync with manager/colleague periodically (weekly or bi-weekly for me), in which I talk about my recent productivity, what's lacking, what's coming my way, and how I should adapt. If I ask for advice, more or less we can come up with a few things to change, and over time I have grown to a better engineer because of them.
I hope this post has given you a think about adaptability as a software engineer. In my opinion this is one of the most productive qualities one can cultivate. If you have any thoughts and experience, I would love to hear about them!
Before you click out, I want to leave you with a quote from Bruce Lee, one of my personal idols:
You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.
Originally published on my personal site. Also recorded in audio.