RE: Pass Number - a struggle

A few weeks ago, I wrote about a colleague of mine; when I originally wrote that post, I wasn't sure if that colleague had an online presence, and so didn't feel it appropriate to name them. I've since discovered that he has, in fact, started to blog, so it's time to "name and shame" my friend and colleague Gautham. :-)

In one of his first posts, he recounts some difficulties which he's suffered in coming to grips with one of the more obscure (but powerful) aspects of MDX (the analytical language at the heart of Analysis Services 2000, one of the core platforms we develop on, and one of my areas of professional expertise).

CalculationPassNumber, CalculationCurrentPass are some functions of Analysis Services that I want to run away from, but it makes me sick to know that they are one of the most important functions to know whilst in an extremely, perhaps dreadfully complex calculation situations. I have been beating my head to understand this for quite sometime now but instead have learnt more about some other things in MDX and Analysis Services. Though my knowledge of MDX and Analysis Services is much better now but this "Pass Number" is something that is turning out be my worst struggle for knowledge.

[Via Gautham V Kamath]

I felt very guilty when I read this, because Gautham had asked me if I could explain all this to him, and, as has been my wont in recent months, I promised to do so, and then completely forgot that I had so promised. :-( And Gautham is far too much of a gentleman to remind me of my unfulfilled promise. Anyway, I've left a comment (which I hope will clarify things for him) on his blog post, and will follow up with him to make sure he's happy with the answer. So why blog about it here? Well, whether or not you've any interest in MDX, this episode illustrates a learning point which I've encountered many times, particularly when I was a technical educator, and I want to explore it a little further here.

The dilemma is this; the more knowledge, skill and experience you have with a particular tool-set (be it a programming language, like MDX, or physical tools like a chain saw or lathe) the more challenging the tasks you can tackle. Until you gain that knowledge, skill and experience, you may not recognise when it's appropriate to make effective use of a specific tool. *However*... learning the *use* of the tool, in isolation, may be difficult if you don't have a specific, relevant (to *you*) example on which to practise.

So, until you learn to use the tool, you may not realise it's the appropriate tool for certain problems; until you *have* a specific instance when it's appropriate to use the tool, you may not be able to learn to use it properly; and until you *have* learned to use it properly, you probably won't realise when that specific tool shoud be used.

In other words, a vicious circle.

As an educator, I want to transfer knowledge and skill so that the individual can develop the experience. With some tools, covering the theory is enough; how and when to apply the tool becomes immediately apparent. With other tools, the theory is *not* enough; you also need relevant (to the student) problem areas against which the student can immediately apply that theory, as they learn the skill, in order to develop their experience. These latter skills are the most challenging to teach; they're typically the highest value-add skills, but they're incredibly difficult to teach (or learn) in isolation. The former skills are the kind that can be learned from e.g. documentation and books; the latter can (in my opinion) only be learned through interaction with others who've already learned them. That interaction may be in a formal setting (e.g. in a classroom or through professional coaching) or in a more informal environment (e.g. internet discussion groups or personal networks). How can someone recognise that they might need to learn one of these *latter* skills, when they don't necessarily know what the skill is that they need to learn?

That's the key, learnable, transferable skill that I want to highlight in this post; recognise when you're working too hard.

I'm not a believer in using some flashy tool simply because it *is* flashy (or new, or sexy); the right tool, for the right job, at the right time, in the right way; that's what I aim for. From experience, I've populated my toolkit with a selection of tools, and the experience to know when to use them (and, just as importantly, when *not* to use them). How do I recognise when I need to add a new tool to my toolkit, or improve my skill with an existing tool?

Simple; when I'm working too hard.

That's the indicator that tells me when I'm missing a trick. I'm a simple, optimistic girl; I believe there's a simple, elegant way to do just about anything. If I'm trying to do something and it hurts, then that tells me I'm missing a trick. There's some tool I *should* be using; even though I may not know what it *is*, at least I now know to go and look. Which, for me, normally involves raising the issue in one of those informal environments where knowledgeable peers may respond. Once a new tool has been suggested, I can evaluate it, learn it, use it, and move on, until the next time.

So there's a two-fold lesson I'd commend to colleagues like Gautham (indeed, *all* students of some discipline)

1) If you're trying to *do* something and it's too hard, maybe you're missing some relevant *tool*; instead of giving yourself a headache, pause and ask someone whose perspective you trust;

2) If you're trying to *learn* something and it's too hard, maybe you're trying to learn it at the wrong *time*; store and use what you have learned, so that when you finally encounter a concrete instance when you'll need that skill, you stand a better chance of realising that *now* is the time to finish learning that skill.

Here endeth today's lesson! ;-)

This blog has been migrated to new software on a different server (http://www.multidimensional.me.uk) and comments on this post on *this* blog are now closed. All existing comments have been copied to the equivalent post on the new blog. If you still wish to comment on this post, please use the equivalent post at: http://www.multidimensional.me.uk/