Respect Your Toolbox
August 16, 2020
As a developer, you will need an entire toolbox. No matter how focussed you try to make your career, it is not enough to know how to do just one thing. However, having one go-to tool as a reference helps you navigate the rest of the toolbox. It is easier to know when to use a screwdriver over a hammer when you understand the nuance of the tool. Sure, you can use the butt of a screwdriver as a hammer to some success. Ultimately, they both get the T-shaped metal thing into the wood. Once mastered, the ability to match a screw to a screwdriver and a hammer to a nail will help you be more productive, safer, and save you money.
Early on in my career as a developer, I decided I wanted to focus on being a Ruby on Rails developer. I had learnt the language and framework to a beginner’s standard and was hesitant to start again, in another language, from scratch. That said, learning new skills to a similar calibre is easier having undertaken that journey before.
I hasten to add that, while this approach has worked for me, I have friends and colleagues who are as successful, having taken a completely different approach. Working with different technology every year has provided them with opportunities to find their true calling. One style has worked for me, another for them. There is no single path to walk.
The Benefits of this Approach
When faced with a problem, two things need to come together for resolution. On one side, an understanding of the problem itself and, on the other, an understanding of how we can solve the problem. Developers will recognise this pattern from their support tickets; understanding how to reproduce a bug is necessary before implementing a solution.
If I know how to wield a hammer and the problem asks me to put a nail into a block of wood, I’m confident about my ability to solve this problem.
If I know how to wield a screwdriver and the problem asks me to put a nail into a block of wood, I know that a) I can fix this problem and b) I am aware that a proper solution is within my capabilities.
If, however, I know how to wield a spirit level and am asked to complete the same task, I am at a loss. Firstly, I cannot solve this problem. Secondly, I do not even know how I can go about solving it.
In essence, we have an internal list of things that we can do/have done and an evidence-base to suggest what we can do. These are the tools in our toolbox. Once we gain an understanding of a problem, we can then match the proposed solution against our toolbox.
While this may seem like the argument against my approach (well, it successfully is the counter-argument), I prefer to look at it from a different perspective: I am not familiar with this type of problem, nor do I have a means with which to solve it, therefore, this problem is more likely to be successfully solved by someone else. I am a software engineer, other disciplines (such as data science or infrastructure engineering) have experts in those fields.
Know Limitations
Knowing your limitations does not mean you refuse to help when something is not within your area of expertise, nor does it mean that you should remain willingly ignorant. It does, however, mean that you should respect the extent of your abilities and avoid misleading people. You cannot solve every problem, don’t pretend that you can.
If you’re the best person to solve a problem within your place of work, let people know you’re not an expert and give it a go. You may end up adding another tool to your toolbox. At the very least, you will confirm the weakness in your toolbox. Besides, you will have a clearer idea of the ideal tool you need to add to your toolbox. You may decide not to add that tool (perhaps it isn’t something you foresee requiring again and you have no interest in the domain), at least you are in an educated position to make that decision.
Having an understanding of self is a strength, not a weakness, it is valid to have gaps in your knowledge, particularly when you know where they are. Though Donald Rumsfeld brought the concept of “known unknowns” to the fore in the early 2000s (within the context of the Iraq war), the underlying philosophy goes back to the Johari Window, created in 1955.
Being Better
The point, I suppose, is that we can’t all be great at everything. Those of us who pursue knowledge in a specific area will be able to compare our proficiency in other fields to that area. As you learn more about one thing, you will gain clarity in your understanding of how little you know about other things.
Harnessing that knowledge means you can focus on learning things to complement your existing skills. You can, by extension, deprioritise the learning of skills that won’t add much value to your toolbox.
It’s not about being a one-trick pony, but about being confident about what you know and what you don’t. Over time, your ability to transfer skills or learn new things to a similar standard will improve anyway.