Nov. 30, 2025, 1:07 p.m.

Issue 47: A Personal Learning Plan

Discover a proven framework to learn any new skill.

Code, Content, and Career with Brian Hogan

Code, Content, and Career with Brian Hogan

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.

How to Learn Something New

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.

Step 1: Work backward from what you want to build

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:

  • Small enough to finish. Scope matters. You'll learn more from a modest project you ship than from an ambitious project that you never complete.
  • Real enough to require problem-solving. "Hello World" doesn't count. The project should force you to struggle, think, and make decisions.
  • Demonstrable. When it's done, you can show it to someone or put it on GitHub.

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.

Step 2: Identify what you need to know

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:

  • Basic Go syntax and program structure
  • Accepting command-line arguments
  • Making HTTP requests
  • Measuring response times
  • Writing to files
  • Handling errors gracefully

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.

Step 3: Find resources for each area

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:

  • The official Go Tour for syntax basics
  • A tutorial specifically on Go's net/http package
  • Documentation on the os package for file operations
  • A blog post on Go's flag package for command-line arguments

Notice 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.

Step 4: Practice with feedback

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:

  • A program that accepts a URL as a command-line argument and prints it to the screen.
  • A program that appends a line to a file every time you run it.
  • A program that makes an HTTP request and prints the status code.
  • A program that measures how long an operation takes.
  • A program that gracefully handles a malformed URL or a missing file.

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.

Step 5: Get Feedback

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:

  • Share code with a friend or colleague who knows the language well.
  • Post in a community like Reddit, Discord, or a language-specific forum.
  • Use an AI assistant to review the code and suggest improvements.
  • Compare solutions to similar exercises from other learners.

Ask specific questions:

  • "Does this handle errors correctly?"
  • "Is this idiomatic Go?"
  • "What would you do differently and why?"

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.

Step 6: Build the thing

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:

  • Push it to GitHub with a README explaining what it does.
  • Show it to a friend or colleague.
  • Write a short blog post or social media thread about what you learned.
  • Post it in a community and ask for feedback.

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."

Step 6: Reflect and identify gaps

After you've shipped, take some time to reflect. Ask yourself some questions:

  • What was harder than expected?
  • What was easier than expected?
  • What would you do differently next time?
  • What related topics are you curious about now?

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.

Common pitfalls to avoid

Watch out for some traps that self-directed learners encounter when learning something new:

  • Choosing a project that's too ambitious. The temptation is to build something impressive. Resist it. A finished project that's modest teaches more than an ambitious project that's abandoned halfway through. Scope down ruthlessly. There's always time to add features later.
  • Spending all the time on shiny new tools. It's easy to spend an entire day configuring the perfect development environment, choosing the right editor plugins, and tweaking settings. Set a time limit for setup. An imperfect environment that works is better than a perfect one that consumes all the learning time.
  • Spending too much time on side-quests. When you're doing your research, it's tempting to get sucked into related content that takes your focus away from the plan. You don't have to learn everything about the technology to do something with it. You just have to learn enough to meet your goal. Once you do, you'll find it easier to absorb new topics because you'll approach them with more experience and confidence.
  • Skipping practice and jumping straight to the project. The full project isn't the place to learn basic syntax. That leads to frustration and slow progress. The practice exercises build the foundation that makes the project achievable.
  • Practicing in isolation without feedback. Solo practice can reinforce mistakes. Even a little feedback goes a long way toward catching bad habits early. Practice makes permanent.
  • Perfectionism. The project doesn't need to be production-ready. It doesn't need comprehensive error handling for every edge case. It needs to work well enough to demonstrate competence. A finished, imperfect project beats an unfinished perfect one every time.

Stay aligned with your roadmap and keep your goal in mind, and you'll stay on track.

Wrapping up

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.

Things To Explore

  • VectorLint is a new open-source prose linting project that uses LLMs to do the work. It's an interesting approach.
  • Color Palette Pro is a color theme picker with an interesting user interface and random presets.
  • LazyGit is a terminal UI for Git that lets you stage, commit, push, pull, stash, and much more.

Parting Thoughts

As the year winds down, consider the following questions:

  1. When you're learning something new, how often do you reach out to share your progress or get feedback from someone else on your progress?
  2. What's the most challenging thing for you when it comes to learning a new skill? Is it having a clear goal, or is it the feeling of being new and inexperienced? Or is it something else?
  3. Consider connecting with a friend on a shared learning goal and creating a study group for yourselves where you provide feedback to one another, discuss challenges, and collaborate on your learning plan. This can do wonders for motivation.

See you next time.

I'd love to talk with you about this issue on BlueSky, Mastodon, Twitter, or LinkedIn. Let's connect!

Please support this newsletter and my work by encouraging others to subscribe and by buying a friend a copy of Write Better with Vale, tmux 3, Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.

You just read issue #47 of Code, Content, and Career with Brian Hogan. You can also browse the full archives of this newsletter.

Read more:

  • Oct 31, 2025

    Issue 46 - Consuming is not Learning, and Managing Multiple Versions with Git

    Explore multitasking in Git using `git worktree` and rethink the idea that 'everyone learns differently.'

    Read article →
  • Jul 31, 2023

    Issue 19 - Adult Learning Theory and Understanding Promotions.

    Hi friends. This month's issue will be slightly shorter than others; I spent the last couple of weeks under the weather, so I've been catching up on many...

    Read article →
Share on Twitter Share on LinkedIn Share on Hacker News Share on Reddit Share via email Share on Mastodon Share on Bluesky
X
LinkedIn
Mastodon
Bluesky
Powered by Buttondown, the easiest way to start and grow your newsletter.