It is impossible to deeply understand a solution before you have the problem.

Let me give you an example that probably all my readers can relate to: Mathematics education. Do you remember first seeing the quadratic equation and wondering why you should care? Or even if you were a math nerd like me, can you understand why someone would be asking themselves that at that point?

The problem is that the students have not had the problem. For one thing, all the quadratic equations they've been solving were simple ones with integer solutions. For another, even the factoring problems themselves were artificial; they're not factoring because they've encountered a real life problem that requires a factoring solution, they're factoring because they were given homework. It's hard to care about the quadratic equation when it's a solution to a problem you don't have.

Also, the problem is recursive in mathematical education... students don't care about the quadratic expression, because they have no quadratic equation problems, except in school. They don't care about the quadratic equations because they only needed to work them to learn about polynomials, which they have no reason to care about, except that it was homework. They have no reason to care about polynomials, except that they were assigned to teach algebraic manipulation, which they have no reason to care about except that it was assigned in school... and so on, recursively, until you arrive at simple arthimetic at which point most people would agree that it corresponds to real life.

In some sense this is the complement to the classic Lockhart's Lament in which a mathematician observes current math education is nearly worthless from a pure mathematical point of view; I observe that it is also nearly worthless from a practical point of view. The ideal education would encompass both, an education that at least covered one would be better than what we have now, but we offer neither.

As is my way, this theoretical-sounding observation can easily be converted into practice, informing both how I teach myself and others. For myself, when learning something I give the documentation a good skimming to sort of load in the "table of contents", then I just charge in. When I encounter a problem, I go back to the documentation. If what I'm using is solid and the documentation is well-written, I'll find the solution to my problem. It will be in some feature or command that previous did not fully make sense to me (proved by the fact that I had the problem in the first place), but now it will make complete sense, because I've actually had the problem it was trying to solve.

At work the amount of time I spend training others is slowly-but-surely increasing, and this observation very strongly informs how I structure my training. The fact is, most "training" fails, because the average training session consists of trying to essentially read out a glossary and then reading out the solutions to some problems. This is a waste of time when the trainees have never had the problems you are giving them the solution to.

Solution: If at all possible, give them the problems. Right now I'm training people on git at work, and despite the abundance of tutorials on the topic I still ended up writing my own training course. I find most tutorials consist of huge blocks of text explaining the basics of git, then they offer various solutions to source control problems, then that's the end. And I have found most people's idea of what being "trained on git" means is that we'll pile into a room, I'll stand in front of some slides gesturing wildly reading these things off, and then by presumably Magic they'll all know git by virtue of having heard some words.

That is not how I run this training. Instead, I make sure everyone is in front of a computer. We all create a repo and follow along, issuing the same commands to the repo. And I do not cover the happy path of what happens when everything is working properly; in fact I probably spend more of the presentation in error conditions and confusing situations than I do things working correctly. People need to know why adding something before switching branches does what it does. People need to learn how to deal with the "detached head" state. People need to learn what to do when a branch is merged and there's a conflict. They can't understand the solutions until they've had the problem, so if you hope for people to walk away understanding the solution you have to have given them the real problem, too.

If you're a programmer, hopefully that makes sense to you. Yeah, the problems themselves are still ultimately artifical, but hopefully it's still enough to trigger recognition when they occur for real. If you aren't a programmer and the last few sentences of the previous paragraph were so much gibberish, well, I ask you to imagine what use it would be to you if I were to describe the solutions here. You can't understand, partially due to glossary issues, sure, but also because you are so far from having those problems that you have nothing to hang a solution on to.

It's early going yet on whether this training is sticking, but early results are positive. I'm seeing better uptake on these topics than I was expecting.

I also have to admit it's a bit funny to hear how completely unused to being pushed into problem situations people are. I explain up front that I'm going to work us through some problems, but I've found people often still end up surprised when I tell them to type something and git yields an error. It's clearly a violation of deeply-held expectations.

At some point I'm going to be delivering security training, which also has its own long, sordid history of failure. For that, I plan on pursuing an even more advanced variation based on this observation: The most important result that security training can have is for the developers to come away aware that they have a problem at all. The vast bulk of security failures can be traced back to that core issue, that the developers didn't even realize they had problems, because they aren't jumping up and down in front of them wearing a sign that clearly labels it as a problem. It is the thinking on that topic that led me to write my previous post. Security issues are about more than just not making the "top 10" errors, it's about realizing that frankly the deck is utterly and totally stacked against you in almost every conceivable way, that dealing with that problem one line at a time is virtually impossible, and that we must start with recognizing these problems before we can even start solving them.

Providing solutions in training is a distant second-rate concern in this case; if developers realize they have problems, they'll seek out and create solutions. Solving problems is what they do, after all. It's that first clause of the "if" where the problem lies.

I hope this can help you improve your own training, and any teaching you may do for others.