Introduction
Software engineering is ever-evolving. The best practices and tools available for developers today differ from those of just 5 years ago. And they will similarly differ from what will be available in the next 5 years.
In this shifting landscape, one constant is the engineers. Those that are building software today are likely to continue building software in 5 years time. In order to do so successfully, we should know the new tools and promote the usage of best practices of the day. But how can we keep our knowledge up-to-date and our skills relevant all the time? The answer is simple: we must become "lifelong learners" out of necessity.
In this article, I'll detail my approach to continuous learning and upskilling in software engineering. I will spotlight learning resources that I find most helpful. I'll also share a strategy to track learning progress and offer advice on how to keep going when learning doesn't have strict deadlines.
Choosing Learning Materials to Use
Newsletters
Newsletters are curated collections of recent engineering news, articles, and open-source projects. They are great for answering the question "What's new out there?". I am a regular reader of the following three newsletters:
- InfoQ Weekly: A comprehensive roundup of software engineering news and articles. It is worth noting that all articles mentioned there have almost academic qualities air to them. Heavy on knowledge, light on engaging storytelling, emojis or jokes.
- Awesome Go Weekly: Since Go is my main programming language at work, I like to stay updated with the Go development.
- ByteByteGo: A bite-sized system design and architectural articles. System design is a fascinating topic. It is also a topic in which most engineers are rarely directly involved at work.
My main reason for reading these newsletters is to get up-to-date with a constant flow of news and identify new emerging topics I can explore in more depth later.
It's easy to get carried away and subscribe to numerous newsletters. But remember, reading newsletters, unlike subscribing, demands time. It's better to read and benefit from a couple of weekly newsletters than to be overwhelmed with many, leading you to question your subscription choices.
Articles
I primarily come across articles I want to read either through recommendations in newsletters or while searching for answers to specific, well-defined questions.
Articles are useful resources for following use cases.
- Quick broad Overviews: An introductory overview of a topic. Take, for example, "A Framework for Prioritizing Tech Debt". This article provides a clear understanding of what tech debt is and presents a possible structured approach to deciding whether to eliminate it must be a priority. You do not need specific pre-existing knowledge to get value out of the article.
- Detailed Exploration of specific issue: Intensive focus on specific and very narrowly scoped issue. For example, the article "User or *User - Do We Need Struct Pointers Everywhere?" dives into nuances of passing structs either by value or by reference in Golang. You need a lot of pre-existing knowledge of Go and its type system in order to get value out of the article.
Articles help you to go very broad or very deep once you identified the topic
Books
Books offer a huge amount of knowledge on their subjects. One good book can take you on a journey from zero knowledge to expert-level knowledge on the subject.
I divide all engineering books into two categories: "Practical" and "Conceptual".
Practical Books usually contain many executable code examples. The books teaching programming languages are the most obvious examples of "practical" books. For example, Head First Kotlin contains many executable examples, as well as many pen-and-paper exercises for the readers.
Conceptual Bookslean heavily on illustrative diagrams and are sparse on executable code examples. Consider Software Architecture: The Hard Parts as an example. Getting familiar with concepts like "Architectural Decomposition" or "Distributed transactions" is vital for being a knowledgeable engineer, but it is not something you can immediately practice by running a code example.
Conceptual books are perfect for reading on the go when you are away from your laptop. Think commute or periods of waiting. Got a spare 15 minutes and a seat? That's a reading opportunity right there.
When it comes to picking the next book, it can be challenging. Sure, there are the well-known engineering "must-reads" like Clean Code and Domain Driven Design. Their reputation precedes them, and they certainly deserve your time. But what about the latest releases? I have a few suggestions.
- Social media, particularly Twitter, can help. If you follow industry leaders or fellow engineers, you'll inevitably come across book recommendations. A Social media osmosis in action.
- Job-based initiatives like "engineering libraries" in the office or a Slack channel functioning like a book club. Both can provide valuable and relevant reading suggestions.
- Occasionally browsing new releases sections of major publishers such as O'Reilly, Manning, and Packt can be a direct source for filling your to-read list.
Be conservative in estimating how many books you can read in a year. If not sure, aim for 2–3 books. Technical books aren't easy to read. While I might breeze through a novel in two weeks, I never managed to do the same with an engineering book.
Video Courses
They combine auditory and visual learning, distinguishing them from text-based articles and books.
- Front End Masters excel in their 'code-along' recorded workshops on various topics, often beyond the scope of front-end development. For example, The Rust Programming Language is one of such courses.
- Udemy has a huge number of courses, but they can be hit or miss depending on the instructor. One example of a hit is a bestselling course Pragmatic System Design.
- LinkedIn Learning curates a broad spectrum of courses catering to various professional domains.
When on the hunt for a new course, I usually skim through the platforms mentioned above, searching for specific topics related to my current learning area of interest, which can be something like "learning intermediate and advanced SQL" or "Event-driven architecture".
Conference Talks
Most of the talks presented at any given tech conference become available online a few weeks or months after the event. Conference talks have a dual role of educating and entertaining. They are valuable for broadening your knowledge horizons. As with any learning material, not all talks are equally interesting. While some presentations shine due to the excellent combination of visuals and narration, others might fall short when watched in isolation, without the context of the tech conference at which they were presented.
My recently watched favorites include
- Visualizing software architecture with the C4 model - Simon Brown, Agile on the Beach 2019 and - Debugging Treasure Hunt - Suzy Mueller, GopherCon 2021.
To curate a list of talks for future viewing, I visit websites like confs.tech or dev.events, focusing on Backend engineering and Golang conferences. From there, it's a dive into individual conference websites to choose the talks to my "watch later" list. I give preference to conferences with shorter 30-minute talks over longer 50-minute sessions. As I think they provide better value to time ration.
Hands-on Project
Active practice is an essential form of learning. While acquiring information is vital, applying it ensures that it's converted into a skill that stays with you.
Sometimes, the newly acquired knowledge can be immediately used in daily engineering tasks at work. Unfortunately, it is not always the case. So you need to find other ways to practise.
In my early days as an engineer, I frequently worked on mini projects to improve and practise my skills. I still do such mini-projects, but less often. However, I do recommend it as the most straightforward way to practice, especially for junior engineers.
At the current stage of my career, activities such as writing articles or preparing engineering talks also serve as practical, hands-on learning for me. I reinforce my own knowledge by sharing it with others.
Finding Time
First, stating the obvious, finding time for studying when you have a full-time job and various outside-of-work responsibilities is hard. And It will never be easy. But it is necessary as the key to successfully learning anything lies in continuity. Regular, even if brief, learning intervals can lead to significant progress over time.
Some employers recognize the value of continuous learning and upskilling and have initiatives like "Half-Day Learning Fridays". If you're fortunate to work for such an employer, it's a boon. However, if not, you're in the majority, and it's up to you to carve out time for personal upskilling.
Taking myself as an example, I dedicate 6–12 hours weekly, outside of work, to learning. This might seem like a big number, but it doesn't feel like a chore most of the time, thanks to my general passion for learning.
I've found that bundling these hours over 3 days from Friday to Sunday - works best for me. My previous attempts to study in the evenings after work often made me miserable. Attempts to wake up early and study before work resulted in me being sleepy and starting the work day while already tired.
Choosing your learning days and hours around what feels most sustainable for you is essential. There's no one-size-fits-all approach. Remember, the continuous learning journey is about personal growth at your own pace, free from external timelines.
Tracking Progress
With tangible goals like "preparing for a job interview", you have a clear objective and a deadline. However, when you're aiming "to stay reasonably up-to-date with the state of software engineering", the goal is vague, and there's no set timeframe to achieve it.
To manage the ambiguity of ongoing learning, I came up with the idea of a Learning board on Notion, inspired by a kanban methodology. I've been using my board successfully for the past two years. The board uses columns to represent progress stages and rows for categorizing the learning medium. I want to particularly note that there are no "sprints" on my board. I use the same board for an entire calendar year.
The essential structure of a learning board.
Here's how I interact with my board:
On-the-Fly Updates: Whenever there's a change in the status of a learning item, I move the card. For instance, when I start a video course or finish an article, I update its status.
Weekly Board Check: Every Sunday, I dedicate 20 minutes to review the board. This routine helps in:
- Assessing my progress, like how many pages of the current-read book I read this week. Thinking about the upcoming week and picking out items I plan learn.
- Evaluating the "No status" column, either promoting items to "Not started" or removing ones that no longer align with my interests.
- Hunting for the new materials. if I have some topic on my mind that I want to learn more about. Or if my "No status" column looks particularly empty.
The learning board offers a clear snapshot of my activities. It helps me plan what I want to learn and how. It also provides a log of what I've learned so far in the current calendar year.
If you like my learning board approach, you can duplicate it as a Notion template and create your own unique learning board based on it.
Conclusion
I believe that commitment to continuous learning and upskilling is a non-negotiable requirement for being a great software engineer. So, crafting an efficient and structured approach to learning is crucial. Through trial and error, I've arrived at the method shared above.
Although my learning process is already well-defined, I'm always looking for ways to refine it even further. I welcome any suggestions or feedback you can give me in the comments.
Top comments (1)
Love this!
I really like using Trello for my kanban learning, and adding checklists to cards to track book chapters is so satisfying 💖
Can also recommend storygraph for tracking progress with books specifically.
Everywhere should be offering learning time in their working time... if they don't want stagnant Devs.