Basically, you start with a problem, than the teacher "helps" to come up with a solution, (by hints / guides), which casually ends up at the solution implemented.
I think it's one of the reasons people love to reinvent the wheel. When they invent something themselves they truly know it inside out.
You can somewhat do it yourself, if say, you want to learn a new library, by first trying to implement the problem yourself, then take hints from the library and finally use the library.
Learning by invention is also my favourite way to learn.
However, I find it rather unappreciated among both teachers and textbook writers. What is usually done is the result is presented on a silver platter to regurgitate and reproduce, and important details are glossed over in favour of 'simplicity', creating a (dangerous) knowledge gap.
You remind me of something a Physics professor once told me.
He said (I'm paraphrasing) "when you get to really learning the Physics, it's not an incremental logically consistent picture rooted in mathematics like in the textbooks. It's mostly a bunch of little tricks that you learn when to apply, and sometimes you get somewhere."
He wasn't making a pedagogical point, but I wonder if being compelled by the "learn by invention" style is in some way detrimental to learning how to solve hard novel problems.
To be fair, 'Learn by invention' can be detrimental if one is trying to derive a result which requires significant prior knowledge that the learner lacks. However, quoting a simple physics example of what I mean: One can prove the Work-Energy theorem with simple manipulations of the basic definitions of displacement, velocity and acceleration without having to learn it like a law. One cannot derive Newton's three laws, on the contrary.
Most of physics is not a great counter-example to learning by invention. There are several ways to derive Newton's three laws. It's a fun exercise in Lagrangian mechanics.
Perhaps quantization or the curvature of space would be better examples as they require prior knowledge of experimental data (assuming we ignore proposed philosophical arguments that stray a bit too far from physics imho.)
This is exactly how Syntax 1 was taught at UC Santa Cruz when I attended.
We started with a general question of "What is the simplest sentence you can think of?", and then moved to "How could you represent that symbolically? Generically?". With the professor's guidance, the solutions and systems of representation evolved over the course of the quarter to become more rich and complex, and just so happened to trace the development of syntactic theory from roughly the 50s to the 70s. Then you took Syntax 2 tracing roughly the 70s to the 90s, and by the end of that time, you were ready to look at modern problems.
Whenever I see a "how-but-not-why" article I assume that the author doesn't understand the "why" part yet... they've likely just rote-learned the "how" part and are regurgitating it.
My favorite articles are where they only explain the "why" and largely leave the "how" as an exercise for the reader!
You'd enjoy Richard de Crespigny book, QF72, about the A380 in-flight engine explosion incident.
One of the clearest reasons he could save the aircraft, is that he spent some time in France, meeting w/ the designers of the different subsystems, and asked (and was answered clearly) tons of 'why' questions.
Yeah yeah 'how' is interesting but in the end, the 'why' is far more important, but also rememberable, and it helps when the thing is broken or half broken and you have to operate it. And I mean the original 'why', not the post-hoc rationalization! 'oh yeah the special "attack-beak" on each wing is there to give more portance during the landing phase, now that it is in "secured mode" (blocked) I will miss % portance during my approach I need to adjust'. And it is secured in case of hydraulic failure or WTF to avoid triggering spuriously during high altitude flight, etc.
Record the whys, that's what jira, code comments, design and justification documents are for! Forget the myriad uml, merise, whatever young people use these days, give me 'why's !
I highly recommend that book and anything from de Crespigny.
I particularly appreciate when very mature projects still reference the simple old 1.0 way, and why they had to change it to the current mountain of "ContentStore implements AddressableDevice" crap. I'm just trying to get Hello World up and running why can't I just pass a folder as string? Oh... This was brought it to support high availability remote data storage...
The experience of starting with something like Lucene at v8.0 is very different from someone who started when it was simpler and probably has both knowledge of and need for any new complications.
I keep trying to drill into people the fact that with so many people on a project, and so much jargon flying around, often people are going to be scanning docs looking for the right doc. You need an executive summary at the top of each page that basically sums up why someone would care to read this page, because odds are fairly good that they don't and if you beat around the bush then that feeling of being tricked into wasting time can result in some bad feelings about you or the project.
Not just why but also what. So many tutorials miss starting with a high level conceptual overview, and instead just spew out a long list of step-by-step commands to run without even explaining the effects that happen by each command. Or use some variation of pattern 1 from TFA, by only explaining it briefly using new and confusing terminology, like "to frobnicate the fluxiator we need to run 'flux --frob --now' "
I believe this is the main reason so many people struggle learning git, to use it effectively you need to understand the underlying data model, but instead people treat and teach it as a sequence of black-box commands. Once treading out of the happy-flow without understanding what, this sequence will not help you.
Fred Brooks famous quote also comes to mind: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
If we start asking "why" a huge proportion of many programmer's favorite tools would be thrown away - so asking "why" is an unexpected minefield in some circles. It forces an evaluation the "technical lead" (that set up the habit of these tools) and that is far too touchy for many "leads".
> asking "why" is an unexpected minefield in some circles
I suspect this largely stems from too many cases of not asking "Why do we X?" but rather "Why do we X instead of silver bullet/fad of the week Y that will fix all our problems?" Many of those technical leads have spent years fending off an onslaught of "obviously better" tools/processes/etc... that even if they _were_ actually an improvement would have grown to consume all available time in switching costs alone.
Trying to understand how a complex mechanism works is hard, but it’s harder if you don’t know why the mechanism exists in the first place.
It would be madness to start studying how an airplane engine works without knowing it is used to impulse a flying machine.