How to prioritize what you learn by creating a topic backlog
Lessons from 25 years of coding
Way back in 1994, I started learning how to code. I look back on those early days of experimentation with great fondness. My journey kicked off after a friend of mine showed me a program he’d written in QBASIC on his IBM 386 PC. I was mesmerised by the idea of being able to control the PC with lines of code.
With the help of a book and the Microsoft QBASIC help files on my 286 PC which I bought second hand for $200, I quickly started writing programs. It was delightfully carefree and my only goal was to create things that were cool or interesting. I had little understanding of the underlying concepts in the code I was writing. I knew the basic data-types, control structures and how to write a function but that was the extent of my knowledge.
Fast forward 25 years and I’m still learning. The tech industry is an ever changing beast and I made a conscious decision a number of years ago that even working in management positions I would endeavour to keep my skills fresh. Most recently, I’ve applied myself to Elixir, Elasticsearch and on improving my understanding of Cryptography.
Every successful engineer has a philosophy of continuous learning, but so often we don’t consider the process of learning itself. To be truly successful you must first learn to learn.
Having mentored engineers for many years I’ve often observed an understandable but sometimes limiting tendency: the urge or desire to go deep on a concept quickly.
We’ve all experienced this at some point: you’re working on a problem and become distracted by something adjacent - even tangential - to your core task. Perhaps you’re reading the API docs for Twitter and stumble across their streaming API. Before you know it you’ve spent the last 3 hours playing with WebSockets in Node.js, streaming tweets in Electron and the Rails app you are supposed to be fixing for a client has taken a back seat. OK so maybe that’s just me?
When learning a new topic, especially for early stage developers, the urge to go deep can become harder to address. Rather than being an issue of simple procrastination excused by the discovery of something new and shiny, the problem is caused by not knowing what to ignore and what to invest in.
I recall a time with a student of mine a few years ago while teaching at the Coder Factory. Jenny (name changed) had an incredibly curious mind and years later is now a successful engineer in Sydney. However, in those first few months of learning, Jenny would get stuck on unimportant details, that while interesting were taking her focus away from some of the more fundamental concepts she was yet to grasp.
On one occasion I had introduced a method in ActiveRecord and casually mentioned that it was implemented via
method_missing. My intention was that we’d cover this in our meta programming workshop later in the course but Jenny wanted to deep dive on the spot. To her, understanding how the method worked was just as important as how and why to use it (maybe even more so).
Now to be fair, I loved Jenny’s curiosity - it’s largely why she’s a great engineer. But Jenny needed to find a way to balance going deep on a topic and getting the fundamentals down. She needed a system.
The Topic Backlog
There is so much to learn in software engineering; more than most people could possibly imagine. Even after 25 years I sometimes feel like a total beginner. But as I’ve become more experienced I’ve developed a system for identifying what topics I should focus on and how to cover them.
I wrote down a simple list of things I wanted to learn. I called it my Topic Backlog. A list on its own isn’t really that useful though. What I needed was a system to prioritise, add and most importantly, check off items!
I use my Topic Backlog as a mechanism to avoid procrastination or distractions when I’m working on something important. When I’m focused on getting something done (say the fixes for that Rails app) and I come across something that interests me or that I don’t understand, I add it to my Topic Backlog. Instead of getting distracted and wasting 3 hours, I file the topic away and focus on the problem at hand.
I also often add items at other times. For example, recently I heard some members of my team talking about Grafana. “I really should learn a bit about that”, I thought to myself. I had an important deadline to hit with the work I was currently doing so I just added it to my Topic Backlog: filed away for the right time.
Prioritizing your topic backlog
If you’ve decided to give this a go yourself, prioritizing your Topic Backlog is probably the hardest and yet most important part of the process. If you have a mentor, working through your backlog with them can be extremely helpful.
I prioritize my backlog about once a month. But if you’re just starting out you might like to do it every week or even every day. When you’re deep in the learning process you will probably be adding new items constantly so it is critical that you keep the most important items at the top of the list.
To prioritize, I use 3 questions:
- Do I know what the topic is?
- Will it be useful to me in the medium-to-long term?
- Does it relate to what I’m working on now?
To help articulate my process I’ll share an example. At one point my topic backlog looked something like this:
1. How MD5 was broken
2. Zero Proof Algorithms
3. Monads in functional programming
All interesting but very different topics. They are also all fairly big topics!
I started with the first question: Did I know what each topic was?
I had a rough idea about topics 1 and 3 (I sort-of knew what a Monad was and I knew that the MD5 hashing scheme had been broken a while back), but topic 2 was a total outlier - I had no idea what it was at the time.
Topics like this go right to the top of the backlog. This is because your first goal is to determine what the topic even means!
I put “Zero Proof Algorithms” at the top:
1. Zero Proof Algorithms
2. How MD5 was broken
3. Monads in functional programming
On to the next question: Would the topic be useful to me in the medium or long term?
I had no idea about “Zero Proof Algorithms” but I’d moved it to the top in the first step so skipped over it. As I’m taking a deeper interest in cryptography I figured understanding how MD5 was broken would indeed be useful to me in the long-term. Similarly, though I didn’t know much about them, I figured monads would be as well. Since these topics were of comparable value, I didn’t change the order.
On to the last question: Does it relate to what I’m working on now?
At the time I was working on refactoring some code in a large Elixir codebase at Expert360. Given Elixir is a functional language, I figured Monads could be useful in refactoring. The math or security principles behind the breaking of MD5 were certainly not useful to me here. So I shuffled the priorities again.
My prioritized backlog:
1. Zero Proof Algorithms
2. Monads in functional programming
3. How MD5 was broken
With a prioritized topic backlog, I was ready to start working through it!
Most items in a topic backlog fall into one of three categories: identification, discovery or practice.
Topics in the identification category are those about which you have no idea. You don’t even know what the topic is let alone how to apply it. The tech industry is full of these!
Identification topics can usually be tackled fairly quickly. Most often a Google search or a conversation with another engineer can help identify the topic. My first topic was an Identification topic and I was able to understand the premise of a Zero Proof Algorithm via the Wikipedia page.
Once an Identification topic has been identified you are done with it. You might like to convert it into a discovery topic or drop it from your list altogether.
The goal in identification is to determine
- What it is, and
- If it might be useful to you
Discovery topics on the other hand are topics that you have already identified but now seek to understand more deeply. My second topic fell into this category. I knew the basic theory of MD5 (Merkle-Damgard construction) and its application from my Cryptography studies. However, in the work I’d done so far I had not come across how weaknesses were discovered in MD5 and exactly why it is no longer considered secure.
My discovery work on the MD5 hashing algorithm started with a Google search which led me to a stack of blog posts, articles and papers. I didn’t read them all but after a few hours of sifting through the posts I felt I had a reasonable grasp on it.
Your discovery work may be similar but may also be more effective with a mentor. In my role at Expert360 I tend have regular mentoring sessions with several members of the engineering team in which we cover items from the person’s topic backlog. A discovery topic will often involve white-boarding, discussion of examples and lots of Q&A.
This leads us to practice. A practice topic is arguably the most important of the three. This is where your skills are honed and your understanding solidified.
The first practice topic in my backlog (actually my second prioritized topic) was “Monads in Functional Programming”. I already knew what Monads were (identification) and had watched several talks and had a few discussions on their applications (discovery) but had not had much opportunity to use them in practice.
I started by doing some exercises often affectionately called Code Kata. In Karate, A Kata is a set of movements that are repeated over and over until the practitioner can perform them without thinking. The Kata teaches a martial artist control of movements, correct breathing and in many cases, the application of blocks or strikes to a real world opponent.
A Code Kata, analogous to its Karate cousin, teaches the practitioner the application of coding techniques to problem solving, syntactic idioms to improve readability and effective testing strategies.
Like in Karate, a Code Kata should be practiced many times, over and over. Each time identifying a new trick or indeed, a trap to avoid. When solving the same problem over and over you can start to think less about the problem itself and more about its subtleties: the way you structure your code, memory or run-time efficiency, how readable the code is to others and so on.
One of the most powerful books I’ve read in recent memory is James Clear’s “Atomic Habits”. In it, Clear describes multiple techniques for sticking to a habit. To be effective in your learning it must become habitual: something you practice regularly and without fail.
I set aside an hour every morning to burn-down my topic backlog or to write about the various topics I cover - as I’m doing now!
As Angela Duckworth says in her book “Grit” when speaking on students preparing for a national spelling bee:
“Deliberate practice predicted advancing to further rounds in final competition far better than any other kind of preparation”
The same could not be truer for learning to code: effort counts more than talent.
25 years after writing my first lines of code, I feel accomplished in what I have achieved but I still so often feel like a beginner. The intense feeling of being completely confused or overwhelmed by a topic is still a regular occurrence.
But over time, I’ve gotten used to it and even now embrace it. But by using my topic backlog and a robust system of learning, I’ve developed the confidence to tackle virtually any topic that comes my way!
Technology changes constantly but there is one unassailable constant: foster a habit of learning in your career and you will succeed.