In previous issues, you've explored how to help others grow through education and content creation, but now it's time to invest in yourself. In this issue, you'll find a framework you can use to learn any hands-on skill. It's what I've used for years and what I recommend to students and mentees.
The book The Pragmatic Programmer mentions the importance of learning a new programming language every year. This practice gives you new perspectives and helps you think about problems in new ways.
This isn't always something everyone can do at their day job, since your employer expects you to work on the things they pay you to do. Events like Advent of Code encourage people to stretch their skills, and some companies offer an end-of-year study break. So some professionals use the holiday season to do some self-directed learning.
Of course, it's a balancing act. People want to grow skills, but they want to relax and enjoy the downtime with friends and family. So they watch some videos and read a few articles or tutorials. They engage in passive learning and then find themselves back at work in January with nothing to show for the time they spent.
As you already know from Issue 46, passive learning doesn't stick. Learning happens through practice and feedback. But there's another problem with passive learning. Without a clear end goal, you don't stay on track. A tutorial might spend an hour on a feature that's irrelevant to real work while glossing over fundamentals that matter. Without knowing what's actually needed, it's impossible to know what to skip and what to dig into.
So here's a plan you can use to learn something new at your own pace, all backed by adult education theory and curriculum design. Whether you want to learn a new tool, a new language, or any other skill, this will work for you any time of year.
The secret to effective self-directed learning is working backward from a specific goal. Start with a concrete thing you want to be able to do, then figure out what you need to learn to do it.
This approach comes from the world of "backwards design", where curriculum developers design outcomes first, and then immediately design assessments that prove learners can perform the desired outcomes. They then build the learning activities that prepare learners to succeed on those assessments. The same principle works for self-directed learning.
So start with your overall outcome. For example, a solid goal would be to learn to build command-line applications with Go. It's focused. You're not saying you want to learn the entire language, or that you want to build microservices or web apps.
Before opening a single tutorial, answer this question: What will you build to prove you learned the skill? This becomes your assessment.
This should be a specific, small, shippable project. Something that requires real problem-solving, but you can finish in a few focused days.
Good projects share a few traits:
If your overall goal is to build CLI apps in Go, then a good project would be "Build a command-line tool that checks if a website is up and logs response times to a file."
That's small, concrete, and requires working with several fundamental aspects of the language.
This project will be the proof of competence.
With the project defined, break it down. What skills and knowledge does it require?
For a Go CLI tool, the list might look like this:
This list becomes your roadmap. Instead of wandering through a comprehensive course, there's now a focused set of topics to cover. Everything else can wait.
Your next task is to find learning materials, but only for the specific areas on the list.
This is where discipline matters. A comprehensive Go course might have twenty hours of content, but only three or four hours might be relevant to the project you're trying to complete. Find those sections. Skip the rest for now. You can always dive into them later, but your current goal is to ship.
For the Go CLI tool, that might mean:
net/http packageos package for file operationsflag package for command-line argumentsNotice what's not on the list: web frameworks, database drivers, and concurrency patterns beyond what the project needs. Those are interesting, but they're distractions right now.
Don't get lost in passive learning, trying to absorb all the information you can. Focus on your roadmap.
Here's where most self-directed learners go wrong. They read the tutorials, feel like they understand, and jump straight to the project. Then they get stuck and spend hours debugging basic syntax errors.
Before tackling the full project, do smaller exercises for each skill area. These are low-stakes practice opportunities that build confidence and reveal gaps in understanding.
For the Go CLI tool, you might write these small programs:
Notice how each one of these maps to one of the topics you identified.
Do variations of each exercise. Make the HTTP program handle different error conditions. Make the file program create the file if it doesn't exist. Repetition builds fluency.
You'll know you're making progress when you can build these again quickly without referencing existing material.
But practice alone isn't enough.
Learning happens through practice and feedback. Practice without feedback can reinforce mistakes and build bad habits.
Find ways to get feedback on the practice you've done:
Ask specific questions:
Feedback reveals your blind spots. The error handling approach you found may work, but it isn't the convention people use. There may be a less complex way to accomplish the same thing. You may have accidentally inconsistently applied patterns in your code because you used different sources. These insights are hard to discover alone.
With practice under your belt, tackle the full project. If you've practiced enough, you've got the building blocks in place already, and the confidence to know you can tackle issues that come up.
And issues will come up. Expect to get stuck along the way. That's normal and valuable. The struggle of debugging a real problem will teach you more than any tutorial you read. When you get stuck, try to solve the problem before looking up the answer. Spend fifteen or twenty minutes wrestling with it first. The effort makes the solution stick.
When the project works, ship it. "Shipping" can mean different things:
Shipping creates accountability and makes the learning concrete. It also provides an artifact you can reference later, along with a reminder that "I built something real with something I taught myself."
After you've shipped, take some time to reflect. Ask yourself some questions:
This reflection solidifies the learning and surfaces areas for future exploration. Maybe concurrency was more confusing than anticipated, and that's worth revisiting later. If error handling clicked quickly, that's one less thing to worry about.
Write down these reflections. They'll be valuable when planning your next learning project.
Watch out for some traps that self-directed learners encounter when learning something new:
Stay aligned with your roadmap and keep your goal in mind, and you'll stay on track.
This framework works because it forces clarity. Defining the goal and the project up front helps you avoid wandering off track. Breaking the project down into skills creates a focused roadmap. Practicing with feedback builds real competence instead of false confidence. And shipping the result makes the learning tangible and gives you a little accountability to shoot for.
This approach works for any skill, not just programming languages. Learning a new design tool? Define a small project, identify the skills required, practice each one, then build it. Picking up a DevOps tool? Same process. Making bread? Same thing.
Use this framework to invest in yourself and learn things quickly at the end of the year, or any other time you have some uninterrupted time.
As the year winds down, consider the following questions:
See you next time.