Every Way to Learn, and Which One Fits You

There’s no single best way to learn a technical craft. Every way to learn does one job better than the rest. A course is great for a new subject. A book is great for depth. A code review is great for habits. The skill isn’t picking the perfect method. It’s knowing which tool to pick up for the job in front of you.

This is the fourth post in the Workshop Bench series. Picture the wall above a craftsperson’s bench. It holds dozens of tools, each hung in its own painted outline. Nobody uses all of them every day. But a good craftsperson knows each one, and reaches for the right one without thinking.

Courses: The Guided Tour

A course is a guided tour through a subject. Someone who knows the ground has already picked the path, put the topics in order and removed the dead ends. When a subject is new to you, that order is worth a lot.

Classroom courses add a teacher you can interrupt. Online courses add a pause button and the freedom to learn at midnight in your pajamas. I’ve recorded many online courses, and I love the format. I also know its weak spot better than most.

Watching isn’t doing. A course can show you how to swim. It can’t get you wet. The learners who get the most from courses pause the video and type every example themselves. They break it on purpose, fix it and only then move on. The ones who only watch finish faster and remember less.

Books and Documentation: The Deep Well

Books go deeper than any course has time for. A good technical book explains how a feature works and why it was built that way. It also shows where it fails. That why is what lets you solve problems the book never mentioned.

Documentation is the quieter cousin. It’s dry, complete and the closest thing to the source. Reading the official page for a command you use every day is humbling. You’ll find options you never knew existed and limits you’ve been lucky to avoid.

Reading Code: The Apprentice’s Watching

Apprentices spent a long time watching before they touched anything. For developers, watching means reading code. Your team’s code, open source projects and the scripts experienced people share.

Reading code teaches style, structure and taste in a way nothing else can. You start to notice why one stored procedure is easy to change and another is frightening. You pick up naming habits, error handling patterns and small tricks without anyone teaching them directly.

Pairing and Code Review: The Hand on the Shoulder

Pairing puts two developers at one keyboard. One types, one thinks ahead, and they swap every half hour. It feels slow at first. Then you notice how many bugs never get written, and how much each person learns from watching the other think.

Code review is pairing spread over time. A good review explains why a change matters and links it to a principle. The author walks away a little wiser. A team with honest, kind reviews trains every member every day, at no extra cost.

Building Something: The First Real Drawer

Nothing teaches like building. Set up a test server, invent a small problem and solve it. Load a million rows and watch what your query does. Break a backup on purpose and practice the restore before a real disaster asks you to.

Side projects work because the stakes are low and the curiosity is yours. You go down rabbit holes nobody would approve at work. Some of the deepest knowledge developers carry came from a weekend project nobody else ever saw.

Teaching and Writing: Learning Twice

The surest way to learn something is to explain it. I’ve written this blog since 2006, and every post has taught me something before it taught anyone else. Writing for strangers exposes every gap in your understanding.

You don’t need a blog to get this benefit. Explain a fix to a teammate. Write a clear wiki page. Answer one question in a forum. Each time, you’ll understand the subject a little better than before you started.

AI as a Tutor: Fast, Patient and Sometimes Wrong

AI assistants are the newest tool on the wall. They’re endlessly patient, available at any hour and happy to explain the same idea five different ways. For a learner, that’s a gift.

They’re also confidently wrong at times. An assistant can invent an option that doesn’t exist. It can write a query that works on ten rows and fails on ten million. Use AI as a tutor, not an oracle. Ask it why, not only what. Then test every answer on a real server before you trust it.

Certifications: The Map, Not the Territory

Certifications give a learning path a clear shape and a finish line. Studying for one forces you through topics you’d skip on your own. That’s their real value.

A certificate is a map, though, not the territory. It proves you studied the ground. It doesn’t prove you’ve walked it in bad weather. Treat it as a structure for learning, and keep the bench time that turns knowledge into skill.

Who Pays, and With What

Every way to learn costs something. Courses and conferences cost money. Books cost evenings. Pairing costs the team some speed today for much more speed later. The question isn’t whether learning is free. It’s who pays, and with what.

That’s the wrong answer, and the joke works because everyone has met a version of it. Companies that want skilled teams pay with time and money. Developers pay with attention and some evenings. When only one side pays, the arrangement breaks, as the second post in this series explained.

The good news is that the cheapest methods are among the best. Reading code, honest reviews, building on a test server and explaining things to each other cost almost nothing. A team that does those four things well outlearns a team with a large course budget and no habits.

How to Choose

Start with the goal, not the method. For a brand new subject, take a course for the map. For depth on something you use daily, read the book or the documentation. For better habits, pair and review. For confidence, build something and break it. To lock it all in, teach it.

Then be honest about how you learn. Some people need a teacher’s voice. Some need silence and a book. Some only learn when their hands are busy. No style is better. The best plan mixes two or three methods and keeps one of them hands-on.

A Little Every Day

The method matters less than the rhythm. A week-long course once a year fades fast. Twenty minutes a day builds something that stays.

The workshop knew this too. Apprentices didn’t learn joinery in a weekend. They cut the same joint hundreds of times, a little better each time, until their hands knew it without thinking. Repetition with attention is how skill moves from the head into the hands.

For developers, a daily rhythm can be small. Read one page of documentation with your morning tea. Run one experiment on a test server after lunch. Read one pull request from a teammate slowly, even when you aren’t the reviewer. Write two lines in a notebook about what surprised you today.

None of these feel like training. That’s the point. Learning that hides inside the workday survives busy weeks. Learning that needs a special occasion waits for one that never comes.

Keep a simple record too. A list of what you learned each month becomes proof of growth on the days you feel stuck. It’s also a ready answer when a manager asks what the training budget bought.

The Case Against So Many Options

You could argue that all these choices are a trap. People spend weeks comparing courses and never start one. Better to pick one method and grind until the skill arrives.

There’s real wisdom there. Choosing can become a polite form of avoiding. If you’re stuck deciding, pick the first reasonable option and begin today.

But one tool for every job leaves gaps. The developer who only watches videos can’t explain their own code in a review. The one who only reads can’t recover when a demo fails. A craftsperson with one chisel can make a lot, but not a cabinet.

What to Remember

Pick the method that fits the goal, mix at least two and keep one hands-on. Type the examples, test the AI’s answers and explain what you learned to someone else.

The last post in this series pulls everything together. It’s a letter to the developer starting out, written the way I wish someone had written to me.

The Workshop Bench series

1. Developer Training: The Day School Ends and Learning Begins
2. Employee Training Is a Promise Both Sides Keep
3. Learning from People: Conferences, Meetups and Mentors
4. Every Way to Learn, and Which One Fits You (this post)
5. A Letter to the Developer Starting Out

No single tool is the craft, the craft is knowing which tool to pick up.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.