>> Heh. The hard part is figuring out how to take a big heap of knowledge 
>> and structure it into something coherant with a logical order to is 
>> that somebody else might even be able to follow. ;-)
> 
> Yes, that's the hard part. :-)

You noticed?

> It's one of the problems with open 
> source software that's doing something totally new, where there's two or 
> three people who know how it works inside and out, and they don't know 
> how to explain it to someone who doesn't already know what they're 
> talking about.

Welcome to Haskell!

I am *totally certain* that the guy who designed the undecidable 
typeclass instance translation rules to System F knows *exactly* what 
they're talking about and why it works... but they're far too busy 
programming it to tell anybody about it in words of less than 6 
syllables. o_O

> It's a tremendously useful skill to have: the ability to explain to 
> grandma (or your boss) what she needs to know about the technology. 
> (That's probably one reason I use too many analogies - I find they work 
> well with non-technical people.)

Indeed.

IMHO, the *key* skill here is looking at a thing and figuring out what 
*is* important, and what is *not* important, for the purposes of the 
discussion in question.

A computer is a very large, complex device, and the software that powers 
it is built from abstract concepts implemented on top of concepts 
constructed from yet more concepts, in a mind-blowing vertical tower of 
abstraction.

Just imagine trying to explain to a Victorian scientist how to design, 
build and program a modern-day computer. I mean, apart from the minor 
detail of needing semiconductor technology and microscopic lithography, 
you'd have to give them a lecture in electronics, Boolean algebra, logic 
gates, sequential logic design, binary encodings, processor design, 
instruction sets, computer programming, subroutine calls, interrupt 
handlers, I/O device design, system programming, compiler design, 
language design, memory allocation and task scheduling algorithms... 
shall I stop yet? :-P

Having just said all that, if somebody wants to know how to connect 
several PCs to a single Internet connection, you *could* tell them about 
IP addressing and subnet masks and the intricasies of NAT... or you 
could just tell them to plug a few boxes together and it'll work. Guess 
which answer most people want to hear. ;-)

> It's also one of the important skills you learn from a PhD.

I'll take your word for it, Dr New.

> I'll second the notion that if you can sit down and write something like 
> you post here, and just churn it out, do so. Getting the ideas down is 
> good.

I had an idea that I could produce a kind of "portfolio" of good-quality 
written documents (various subject areas and target audiences) and I 
could show it to people and say "hey dude, I'm clever!" The thing I 
posted here is a first attempt at one such portfolio document.

(I'm polishing up my Parsec thing to make another such document. And I 
may or may not to a layman's overview of computer hardware - I don't 
know if I could do it justice...)

> After that, if you want to go further, sit down and make an outline (as 
> in "table of contents" type outline). Break it down until the structure 
> has an entry for each idea, where "each idea" is covered in a paragraph 
> or two. Then read the outline and make sure someone else could 
> understand it on the first read through. Then you just fill in the outline.

The trick to this seems to be figuring out which concepts "depend on" 
which other concepts, which ideas "lead to" others, and finding an 
optimal order to present the ideas. And some good metaphores and 
examples usually help immensely... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message