The expert at anything was once a beginner.
American actress whose career spanned 80 years.
In the previous articles, we discussed at length the role of exploration in learning. But if your destination is to reach expertise on a subject, you can’t just wander and hope for expertise to join you on your ride. You need a better strategy.
Climbing the stairs
Cambridge Dictionary defines expertise as “a high level of knowledge or skill.” This definition reflects the analogy in the previous post where expertise was depicted as a mountain. Expertise is going higher and higher, where less and less explorers dare to adventure. It’s being at the top of your discipline. Expertise is not walking. Expertise is climbing.
Indeed, learning your first web framework is a step toward expertise, whereas learning other web frameworks is not. To continue the climb, you need to find new complementary knowledge or skills you can apply on the same project and not alternative knowledge you would apply on a new project. For example, for a web developer, it can mean learning the intricacies of the HTTP protocol, or studying accessibility guidelines.
Moving toward expertise means moving up the pyramid. When you are learning a similar framework, you are turning around the pyramid to observe the landscape from a different side of the pyramid. It’s not necessarily a bad thing, as long as you are conscious of it
My years in IT consulting companies
My first decade in the professional world was spent working for different IT consulting companies. Those companies usually don’t develop software in-house and provide instead the services of their consultants. Clients are publishing mission opportunities with a precise list of technologies they are using on a given project. The more keywords you have on your resume, the more you can match with a large number of these opportunities.
This problem is not really unique to services companies. We talked in the previous article of this series about job opening positions, concluding that a few companies focus on agnostic skills while most focus on specific technologies. In services companies, the second approach is the norm. Clients need developers that are quickly operational on the job. It makes sense, at least for them. But do you want their short-term vision to drive your learning?
During those years, I lost a lot of energy trying to fill the gap between my resume and potential mission opportunities. I learned a lot, for sure. But following this path is not following the path towards expertise. A large part of what I learned is now obsolete. The truth is technologies change faster than I was able to adapt. The technological landscape is expanding like the universe. I decided to stop this race. It’s a losing battle.
When learning something new, you have the choice between favoring breadth (moving around the pyramid) or depth (moving up the pyramid). For example, what is more important to create a web application? Knowing the details of every frontend frameworks (breath) or having a solid background on the whole stack (depth)?
Moving around the pyramid is not without dangers. What is not apparent with the above illustration is, in practice, each stair doesn’t necessarily have the same number of sides. When learning a Version Control System (VCS), your choice is mainly limited to Git and Mercurial. But when learning a web framework, the choice is much bigger. New frameworks will probably pop up during that time and you can end up moving around without never coming back to the initial side. Moreover, even if you come back to the initial side, you can think to have seen everything. You looked in every direction. You’ve contemplated the whole surrounding landscape. You learned a lot, for sure, but if you look up at the pyramid, you will discover the ascent is just starting.
Reaching the top means a lot!
Observe the pyramids in the following illustration:
These pyramids depict possible roadmaps to reach expertise on various aspects of software development. I will use two imaginary developers climbing those pyramids to illustrate my point.
Who do you think is more likely to reach the top of the DevOps pyramid? Bob, who has several years of experience on the subject? Or Sandy, who is just starting the ascent after her previous accomplishments?
If you focus on work experiences like we commonly do during job interviews, you will probably bet on Bob. He has already demonstrated some skills for the job. Why choose a novice who can’t answer your clever questions? But if you focus on the climbing activity, I’m quite sure you will bet on Sandy. She has already demonstrated the ability to stand at the summit. She demonstrated perseverance. She learned to overcome plateau. In short, she is experienced to repeat the exploit on a new pyramid. And you would be right!
Our current position is a bad indicator of success. Even if I start the ascent of Mount Everest while an experienced climber is still sleeping at home, several thousands of miles from here, this doesn’t mean that I will reach the summit first. In fact, most people, including me, will never reach the summit at all. The history of our positions says a lot more than our current position. Learning is moving and thus, we are interested in the trajectory and not in a single point on it.
What about being an expert on a given technology?
If reaching the top of the pyramid is so important, sometimes, things are not so easy. The next stair may be a little too high for us, and thus a little help is welcome. That’s what we will discuss in the next section.
Climbing the steps
Climbing a pyramid when the stairs measure one meter is quickly exhausting. Things don’t have to be so hard. All you need are baby steps.
Baby steps are a classic example of the divide-and-conquer technique. As long as you find steps that are small enough for you, nothing can prevent you from reaching the summit. “The journey of a thousand miles begins with one step,” said Lao Tzu. Nobody cares if you do giant or baby steps. Just keep moving upward, one step and one day at a time. The view from the top is so worth the climb.
My struggle with Computer Security
I’ve always considered security is everyone’s responsibility. But in practice, I haven’t really committed to this idea, and consequently, I started my current job with big gaps on the subject. I decided to change that.
Software Security is a large topic despite that a single leak is all an attacker needs to win. Therefore, a solid understanding of the subject is required if I want to build secure systems in practice. How to proceed? Divide and conquer!
The literature on the subject is very exhaustive. I decided to try the books that have always been on my reading list. Curiosity is my compass when I’m lost. I read Applied Cryptography by Bruce Schneier (clearly not the most approachable book, but it focused on a single topic, and my initial goal was not to understand everything). I also read The Art of Deception by Kevin Mitnick (a very fun book to read) to learn more about social engineering. I attended local conferences. I didn’t understand everything, but that’s exactly what I came looking for. Feeling ignorant drives me to learn even more.
Learning security has always seemed to me a daunting task. There is no switch to illuminate everything I need to know, so I use my flashlight to proceed step-by-step and try to understand how the pieces of the puzzle fit together.
Our journey started in the city as a tourist. We then moved to explore the world as a gardener. And we finally gained height to admire the panorama as a climber.
Before closing the series, I would like to summarize the key lessons we discovered during our journey.