The Pattern #7 - Technical
You can’t build a great career on weak foundations
In this article in the promotion series, I will be going over the technical skills aspect of securing one.
Read the previous articles on opportunity here and perception here.
But first …
Technical
Skills break down into two main types, technical and soft. But that covers a broad spectrum. In this article, we will dive into the technical aspect.
Fundamentals
Early on in my career, I struggled with increasing my technical chops.
I just never felt confident committing myself to any one direction.
I didn’t know if I should I study courses, youtube tutorials, certification pathways, or just pick up what I needed as I went along. I was in a state of analysis paralysis.
So the biggest question of all that loomed over me was, what should I study?
“Fundamentals, fundamentals, fundamentals. You’ve got to get the fundamentals down because otherwise the fancy stuff isn’t going to work”
The place to start, of course like with all things, was the fundamentals.
You can’t build a great career on weak foundations.
The Senior role was an important milestone that I was striving towards, but it came with the expectation of well-rounded expertise.
Imagine being asked a straightforward question about Docker, only to realise you’re stumped due to a lack of foundational knowledge.
A situation like that would’ve challenged my credibility and as discussed in a previous article I wanted to be considered senior at the industry standard, not just in my current role.
The next logical question becomes: how can we identify these fundamental weaknesses and, more importantly, work to upskill in those areas?
Let’s deal with the first part of the question. I've identified four ways to help pinpoint areas for improvement:
Challenging Tickets - Trust your intuition. We often intuitively know our weaknesses. They're typically reflected in the kind of work we avoid due to knowledge gaps
Job Specifications - Look at job postings! I noticed particular tools or technology would appear frequently and If I lacked that knowledge, it was time to study it—even if my company didn't use it. Ideally, I could introduce that tool or technology to my company. This approach offered dual benefits: I was acquiring market relevant skills while also enhancing the company's infrastructure
Roadmaps - Roadmaps maps were a great way of gaining an understanding the types of tools and knowledge areas in the sector. However, I used this resource cautiously— roadmaps often expanded to include every technology in the field, which is not always be helpful. I cross-referenced it with job specifications to highlight the most relevant technologies
Feedback - As discussed in the first article, regular feedback was crucial. Colleagues have been a great resource in providing a different perspective on my performance as an engineer
Great, so we’ve identified our weakness. Whats next? Well its time to start hands on by doing labs.
Labs
I've often seen people spend time on theory without actually putting into practice what they've learned. They might be able to explain the theory of Docker, but wouldn't know how to write the first line of a Dockerfile.
Make sure you get your hands dirty and build things with the tools you're learning. Better yet, try to document your work so you can look back on it and take it away with you.
To put it simply, I found hands-on labs a far more effective learning tool than just reading about technologies in articles or watching tutorials.
Troubleshooting as a Learning Tool
Troubleshooting has been my greatest teacher. The most valuable learning experiences often occur on the job.
"A fool learns only from his own mistakes. A wise man learns from the mistakes of others."
I prefer a modified version of this famous quote: You should learn not only from others' mistakes but their experiences as well.
I believe the true value in articles like these lie in sharing experiences so that you can progress more quickly on your own journey.
With that in mind, I'd like to help you identify some key areas to focus on.
I've gained the most knowledge when faced with obscure errors, forcing me to scour documentation, Stack Overflow, or ChatGPT for solutions. This is where true learning occurs. It also enhances your reputation as an engineer. If you become the go-to person for any random issue—thanks to your persistence and work ethic—it significantly boosts your standing.
These are my two tips for troubleshooting:
Occam's Razor: When faced with several possible explanations for a problem, the one with the fewest assumptions is usually correct. Most issues have simple solutions. For example, a permissions problem is often caused by a typo or a misunderstanding of Identity and Access Management (IAM). Early in my career, I believed that issues raised by senior engineers had to be complicated. However, I discovered that they are often straightforward—like a simple mistake or a misunderstanding of a service. Always look for the simplest explanations before considering more complex ones.
Tenacity: When you're stuck, push yourself to find a solution independently. Imagine your manager is on vacation and you're the only one available. How far would you go to resolve the issue? Be reasonable—don't spend days on a problem your manager could quickly solve. But don't immediately turn to them at the first sign of trouble. Tenacity. This approach helped build my confidence. When I persisted a little longer, I was able to find the solution myself. Sometimes, stepping away and returning with a fresh perspective the next day can make all the difference. I was often surprised how often it was a minor issue all along.
Plugs
A collection of interesting links I’ve found from trawling the internet
Al-A'raf (The Heights) - Sheikh Ahmed bin Talib
Hacking with PDF - How to hack via PDF 😭
A real 10x engineer - Have you ever met a 10xer ?
Justinmath - Roadmap to get from high school math to cutting-edge ML/AI