How I learn things

[andrewducker]

I learn by doing.

Give me something _simple_ that works, and let me play with it.

Then add another simple thing to it, and let me play with that.

Slowly build up the different levels, until I have something that is functional, and useful.

I mention this, because I'm grappling with the Velocity template tool* at the moment. And the documentation is shit, and in a particularly strange way.

Firstly, the documentation isn't on the actual website. Which means that you can't have a three minute scan before you decide if it's what you want, you have to actually download it, unzip it, and then look in the docs folder. This is not a great start.

Then, when I start looking at the User Guide it works in _exactly_ the way I want - if you're the person writing the web pages. It does exactly what I want - start off with a simple "Hello World" example, and then build up from there into something useful.

It wasn't until I'd read that all the way through that I realised that it hadn't provided anything useful for setting it up in the first place. So I skip to the Developer Guide, and the first part is "The Fundamental Pattern". Except that that doesn't start me off with a "Hello World" example, but instead starts telling me what abstract steps I need to carry out, and then hits me with the choice of whether to use the Singleton Model or Seperate Instance.

And if you're baffled by that, then you're not alone. The people writing the documentation clearly think that the best way to learn is to feed you all of the abstract information about the design of the system up front, and then once you understand it all perfectly you'll be able to write whatever you want. And I just don't learn that way.

What frustrates me is that the way I learn is clearly not unusual. Every single computer game follows the model I laid out at the top. Learn a simple move/technique, use it to solve a problem. Learn a second technique, use it to solve another problem. Solve a problem that combines technique one and two at the same time. Learn a third technique, and so on.

I really don't understand why more people don't get it.

*Take some HTML, mix in some data, throw it at the browser. I didn't like JSP very much, because it has the code in the middle of the html, and I'd rather keep them separate if I can.

Comments

[birguslatro]

That there's money in computer games probably has something to do with why they understand how people learn. It's in their interests to get it right.

Compare with the rewards for writing open-source software.

[akicif.livejournal.com]

Thanks indeed for the heads-up on this. The next version of the Shibboleth IdP software will be using Velocity Templates instead of JSP for customised login pages etc...

[andrewducker]

The actual tool looks pretty awesome. I'm just trying to work out what basic steps I need to follow to get started...

[undeadbydawn.livejournal.com]

you have caused me, indirectly, to think about the way I learn *a lot* of late. I'm thinking the problem is one of abstraction.

As long as I can see or intuit a natural link between a process and a result, I learn very quickly. When a term or unexplained symbol[ism] comes in the middle, I'm totally lost.

this, I believe, is why I find coding virtually impossible. Just as the word 'log' entirely obscures my understanding of logarithms - literally, the word being there makes it extremely difficult for me to process the maths and understand what it wants me to do.

similarly, the epic frustration I had in civil eng was the EU notation, where *everything* is a letter followed by a partial word. I can't process that. _even if I know what it means_

coding consists almost entirely of such abstractions

[stillcarl.livejournal.com]

coding consists almost entirely of such abstractions

It depends on the language. REBOL is very wordy...

http://www.rebol.com/docs/reference.html

And the few abbreviated words could be replaced with whatever you want. ie. logarithm-e for log-e. (Or natural-number-logarithm, or whatever.)

Unfortunately REBOL's in a state of flux at the moment, but usable if you don't mind a few rough edges.

[channelpenguin.livejournal.com]

I was actually talking about this sort of thing last night. I personally, for a non-physical task, pretty much head straight for abstraction. I am totally comfortable there and don't care about using symbols or even no name or label whatsoever in thinking about things (mentally, that "nameless" mode is kinda like... oh so if I do "this" [complex mental image] to "that" [another mental construct] , add a few of "those"... etc. - and that's really not explaining it very well at all!)

e.g. I learned set theory before I took up databases - and I do think it helped (and continues to help) me avoid some common pitfalls (but don't actually ask me to hold forth on set theory 20-odd years later!)

BUT... I am aware that most people are much more concrete thinkers who need concrete examples upfront, and that names matter - which is why I have to really concentrate and think if I want to teach or explain.

[andrewducker]

If I don't understand why I'm learning an abstract thing then it refuses to stick in my head. And I'm no good at dealing with things unless I have a web of connections and understanding for them - which tends to mean I actually take longer than most people at work to get started on something, but then I understand it better, because I've had to to work on it at all.

[channelpenguin.livejournal.com]

yeah - that's a good way to be, in the end, I agree you probably, under most circumstances end up with a deeper understanding than someone like me - it's something that sometimes troubles me a little, I often feel a bit like I'm passing the equivalent of Turing Test but there's no real consciousness involved in my understanding. But I'm also kind of of the opinion that conscious understanding is not always necessary - that our minds work in many ways, and being reliable *able* to do a task/set of tasks/exercise a skill 'counts' even if you can't consciously articulate how or why or even pick it apart. It's too big, too synergistic... an epiphenomenon, if you like, of the mind (brain/body combination for any task with a physical component).

[andrewducker]

My deep understanding is rarely that useful in the immediate - it's usually more useful when something breaks, because I understand the next level down. Or when we're designing something.

[steer.livejournal.com]

I prefer to know both the abstract and the "how to". If I only want to work with something for a bit then a simple how to and examples is fine. However, if I need to produce something of quality using a codebase I need the abstract because without that my code becomes a bunch of increasily ghastly workarounds from modifying the examples provided.

I suspect the reason for the documentation you describe is not that the writers don't "get it" but that they simply don't have time. While we all know that documentation is important, given limited time, poor documentation of working code is better than great documentation of non-working code.

[andrewducker]

Oh, I need to know the abstract too, but not until I've got a handle on things. And I can usually put together the basics of the abstract stuff myself from the API, once I know how they expect it to go together.

[steer.livejournal.com]

I remember the first time I worked with a model-view-controller architecture the whole damned thing seemed like magic for a long time and I'd got a lot of examples working but just couldn't figure it out. I needed to read up on that abstract framework before I could stop fighting the paradigm and trying to bend example code to do the wrong thing. I think it's because I'm used to fairly straightforward coding in various languages. Having "code" (or code-like things) in three seemingly unrelated places, well, I just did not click with it until I got a firm grip on the paradigm.

[andrewducker]

Yeah - it's getting inside the heads of the people who wrote it, and understanding how they want you to do things.

And that's something I find a lot easier when I'm operating inductively rather than deductively.

[steer.livejournal.com]

Perhaps the key is finding the exact moment where the abstract view is useful. In the case of MVC I bogged down too long in examples and trying to curve those examples to do "the right thing" without understanding the bigger picture. It's really horrible to see programmers who get stuck in that mode of operation because you end up with "programming by google" where they desperately scrape around trying to find the example which does the nearest thing to what they want without a larger understanding. (I remember one guy I was loosely supervising and I solved a problem by making a variable static so it could count class instances... a week later when I came back to look at his progress *every* variable was static and nothing worked because he didn't understand what "static" was but just that I could solve problems using it).

It also depends on your existing set of concepts I suppose. Someone with a firmer grounding in databases would likely have "got" MVC frameworks faster than I did.