Thanks to all kinds of activities related to software development I’m involved in, from time to time I have a chance to talk to people entering this career path and listen to their struggles. One of the issues that occur the most often is caused by so-called ‘paradox of choice’ - a situation where the total number of choices one has to face (in terms of technology, programming language or the next best framework) makes it impossible to stay focused on the most important topic and learn efficiently.
Additionally, considering the fact that our industry is full of strong opinions (not always held that weakly) about growth and personal development, it’s pretty hard to define a list of tasks one should complete making a meaningful step towards becoming an even better software developer. Some people think that attending conferences is a waste of time, there are people who say that there’s nothing good this particular book, and of course, there are groups of people convincing you that the value this one tool brings to the table just can’t be denied.
Recently I’ve been trying to figure out a solution for both of these issues which could make it easier to find your own learning path in software development, and I think I’m finally ready to share my ideas with all of you. To be more specific, it’s time to learn more about the Layered Model of Learning Programming (the name is highly unstable).
Let me ask you a question - in how many ways could you start your own journey as a programmer? It’s pretty easy to define at least a dozen of them - there is an unlimited number of meetups, conferences, courses, books, articles, bootcamps, hackathons or pet projects you could get interested in to learn a bit more about this crazy world of software development.
One of the most popular ways to start such a journey I can think of is to sign up for a Computer Science class where you discover and play with languages like Python, Java or C++ for the first time. Some of us, however, decide to skip this step and would rather participate in bootcamps or other “task force groups” focused on intense courses for software developers. In parallel to those activities, an ambitious programmer can surround themselves with books written by industry experts, subscribe to their social media profiles where they share meaningful insights or maybe attend a few conferences to learn more about ‘the next big thing’. Finally, we start our first job where we finally have a chance to test all those theoretical concepts in real-life.
At this point, some of us may feel overwhelmed by the number of different paths one could follow. It is a well-known dilemma of most programmers that we wonder what’s the right order of tasks and activities to complete to become an expert?
Should I look for a job rather sooner than later? Is attending a conference a good idea, or a waste of time? Do I really need to buy this paid course if my current account balance is equal to zero? Is ‘Clean code’ a book worth reading for someone like me? What about this new framework that has been published recently - should I learn more about it? Based on my experience in mentoring programmers on various stages of their careers I can tell you that these questions are more popular than you think.
The biggest fallacy about learning software development is that for some of us it’s a one-dimensional path where the most important factor is the order of activities we are involved in.
It’s no wonder that such a model does not help us learn and grow without stress, maybe self-doubts or even anxiety. When the only thing that matters is the order of activities, all we think about is whether we should do this before that, or something else afterward? A book before a course? A talk before a bootcamp? A conference after a book? Is XYZ a waste of time? Is XYZ a good choice? And many more...
In general, there are these two questions worth answering to untangle the paths of learning programming:
- What’s the right number of topics I should be interested in at this point in my career? Should I value a broad range of skills over very narrow specialization, or maybe the opposite?
- How much time and effort I should invest in the topic I have in front of me? What’s the good balance between shallow and deep learning, and when to favor one over the other?
Today I’d like to show you my proposal for answering these questions.
There are two key goals for everyone who thinks about successful learning and developing their skills in programming:
- build competitive advantage by being experienced and skillful more than the average in a small number of well-defined areas to bring the value for everyone who wants to work with you
- stay aware of the situation on the market in terms of techniques, practices, frameworks, and languages to extend your ‘expiration date’ as a software developer and to be able to cooperate with experts from other domains
I believe you can easily agree with me on these two, but finding a good model to cover this concept is a more difficult task.
After spending long hours trying to figure out a stable learning framework based on these two points, I recalled something that all my friends from the world of marketing and sales use on a daily basis. The thing I’m talking about is called a sales funnel.
“A sales funnel is a visual metaphor for the path taken by a potential customer as he or she moves towards becoming a customer. Frequently used by sales and marketing organizations, the sales funnel helps companies understand and visualize their sales process and measure overall conversion success between each step of the funnel.
A sales funnel is shaped like an inverted pyramid, similar to real-world funnels, to which the metaphor alludes. The width of each part of the funnel reflects the audience size, with the top of the funnel being the widest and the bottom being the smallest.” ~ source
How does it relate to things we’re talking about in this article? Let me surprise you - in a very direct way! The only thing we need to do is to replace customers with topics we want to learn about and activities we want to be involved in:
Such a ‘layered learning funnel’ can be used by developers to manage the topics they learn about, invest time into them and interact with. The key point about this funnel is that it adds the next dimension to our thinking about learning and growing as a software developer by introducing this concept of level of involvement.
As it turns out, by noticing the difference between the order of things to learn and the level of involvement, we gain a pretty useful model of approaching basically every new concept without a need to limit your expertise in areas you're most familiar with.
To see how all of this works, let me explain the rules of this model.
The concept I want to show you today consists of multiple layers (buckets) for everything that is (or may be) related to your growth - books, courses, talks, conferences, studies, papers, docs, frameworks, languages, etc.
Layers in the upper part of learning funnel may contain multiple topics you just "collect" to stay aware of how things work nowadays and what's the next big thing for your peers working in different areas of software development (languages you know less about, frameworks you didn't have a chance to work with, etc.). Layers in the lower part require much more effort but they help you build your expertise and market value.
The most important thing about all those layers is that the deeper you go, the smaller number of topics you bring with you (because there's a limited number of hours per day), but your level of involvement has to increase (because this is the place to focus and work deeply).
Let's go through each layer of this funnel to see how it works.
This is the bucket for all kinds of activities for people interested in the world of software development no matter what language or technology or framework is being mentioned. The awareness layer is about attending conferences, talking to people at meetups, following social media profiles or just briefly reading some docs only to stay aware of everything that happens around you. Relatively low level of involvement, but a wide range of topics to cover.
There are some topics in the previous layer that may look especially interesting for you. For example, at one conference you listen to the talk about this brand new framework you have to check or maybe someone mentions this great language that BigCo uses daily, and you decide it's worth spending some time on it. You filter out some of the topics from the Awareness layer only to briefly check how does this new tool look from your own perspective.
The Comparison layer contains all of the topics that fight really hard for your attention while being truly promising in terms of actual usage in real life. This is where you want to compare these shiny new toys with tools you use to build stuff every day. This is also the time to think about their weaknesses, bad parts, the context in which it should work or values that this specific framework, language or technology bring to the table. This is the layer that ends our dry analysis of a given subject because everything that comes next is mostly about practical application.
It's time to check how your topic of choice works in reality. For example, you can create a repository for a demo project where you're going to test this newly discovered practice or framework, you may introduce it in one of your pet projects, or even build an MVP based on it. The key thing is that on this stage the risk of introducing this brand new tool should be relatively low - all in all, you're only evaluating it without making any final decisions.
Everything that lands in the Action layer can be immediately propagated to your portfolio, LinkedIn profile or your summary of expertise. The Action bucket is a place where we keep languages, techniques, and practices that help us build stable, reliable solutions where the amount of risk is minimized as much as possible. Topics we put in this bucket do not bring us the feeling of wasting time because they are directly related to our daily job, projects we work on and the reasons we get paid for.
The Advocacy layer is totally optional for most programmers, but the value it brings forces me to include it among others. So what's inside of it? Well, from time to time we discover something from these "actionable" buckets that makes us so excited, that we can't wait to share the news with our colleagues or the community we want to give back for. We start promoting it on the web, we talk about it at conferences, or we record a video explaining the basics of it. In some companies, we'd be called evangelists of this specific topic. Activities from this layer are very often super time-consuming but at the same time the return of investment from them pays off in a very meaningful way (building a personal brand, meeting experts and sharing knowledge with them, or even building a foundation for everything that comes next for you).
My learning funnel, as a front-end developer working mostly with Angular projects, can look like this:
What's in my Awareness layer? Basically the whole world of software engineering. I'm really eager to learn about new languages, techniques or frameworks. I love to follow social media sh#tstorms about all kinds of stuff and debates whether or not the TDD is the right way of writing tests. I want to stay aware of things, I want to be prepared for changes that are possibly waiting for me in the future, and I want to discover new worlds without that much involvement.
In the layer of Interest, there are mostly topics related directly to my front-end experience. As of today, I'm following the development of Svelte framework, I'm curious how it will change the way we write our client-side solutions and I can't wait to spend more time on this topic. The same with Nest, which seems to be a really promising replacement for raw Node.js environment.
Comparison? Of course two out of "the big three" - Vue and React. Even though I spend most of my professional time in front of Angular, I'm a big passionate of new ideas released under both green-ish and blue-ish logotypes. I read about hooks, I read about single-file components, and I'm trying to borrow some of those ideas to the world I'm the most familiar with, which is Angular.
The Evaluation layer is currently all about Stencil and Web Components. I've managed to release a few production-grade projects based on these two and I'm constantly looking for more knowledge from those areas. Some time ago I fell in love with the idea of building truly reusable components which can be injected into your favorite front-end technology, and by that time I had a chance to not only build WC-based solutions but also discuss different ideas and issues with Stencil's core team and other advocates for that wave.
Last but not least, there's this Advocacy layer and due to me being a big promotor of the knowledge sharing movement, today you can read this article, watch my videos on YouTube or listen to a talk on a local conference. The total amount of time I invest in these areas is pretty big, and so is the outcome I feel every day.
In your case, all these layers I've just described will probably include a totally different set of activities. If reading a technical book is something thanks to which you build your awareness, surely it will land in a different bucket than in my case. If your daily job gives you lots of space to experiment with different libraries and frameworks, you will also treat these "risk-related" activities differently. All in all, it's not about finding the one and only way of labeling such activities as "reading a book" or "attending a conference", but rather about learning in this two-dimensional funnel where next to the order of tasks we also think about the right level of involvement.
Yes, of course, it does. Thanks to modeling my own way of learning the craft of software development everything I do has a much better structure, is organized in a better way and just let me work on my own skills more consciously.
For example, thanks to splitting different activities I'm involved in into layers, I do not feel guilty after visiting one or two conferences (for me it's an Awareness layer) only because some say it's a waste of time. On one hand, I understand that it's a great way of keeping my finger on the programming pulse and stay in touch with bleeding-edge ideas, techniques or frameworks, and on the other hand, I'm not really that sad after missing one or two events because it won't ruin my career immediately. At the same time, as we go into lower parts of the funnel, I know that there's a need to work on a pretty limited number of topics in a more focused and deep manner because without clearly defined areas of expertise I don't feel as comfortable as I'd like to.
Thanks to this additional dimension (level of involvement) I can approach different activities more consciously and expect different outcomes without being disappointed due to lack of results. The more I get familiar with something (an idea, a framework, a tool) and the more promising it looks, the more attention I put on learning it and promoting it to latter layers of my funnel.
Additionally, the model I explained here is not a tool that only beginners can include in their workflow, but it's something that anyone who tries to navigate their career path can use on a daily basis. At the end the process of learning a thing is endless, so I can't think about any reason why putting more order into it will get you into trouble. Give it five minutes and share your feedback with me - I'm really curious what's your view on this topic!