>> Let's face it, usually the reason I write something is that somebody
>> else has written it, badly, and I want to do better.
>
> That's not a bad reason to do something like this.  It often helps one
> understand something if one has to learn it well enough to teach it - and
> when you write something, you're teaching.
>
> That's actually a really good strategy for learning, as well - if you
> have to explain what you learned to someone, that helps focus your
> attention on what you're learning.

Well, that's true enough. I quite often walk around the place telling my 
imaginary friend about the finer points of logic design, or chaos 
theory, or data compression algorithms. Quite often you discover a new 
way of looking at something just be *pretending* to explain it to somebody.

I like to pretend that this is the reason that I do this. Obviously, the 
real reason is that until very recently, I was a sad pathetic loser with 
no *real* humans to talk to...

> The trick is not to identify "Haskell" as the subject you're writing
> about, but to break it down into smaller pieces.  Then break those
> smaller pieces down, and so on.
>
> Then you get to something manageable.
>
> After that, then build a structure.

Chopping the subject up into pieces is not difficult. It's stringing 
them into a logical structure that's difficult. I think I do this quite 
well for smaller documents. For large documents, it ends up all going wrong.

> When I worked on the books I co-authored, that's what we did; Peter (my
> co-author) and I sat down together (or sent lots of e-mails, since we did
> a couple books together and he's in Toronto and I'm not) and worked out
> an outline for our troubleshooting book.
>
> We started with what topics we needed to cover, then organized them.
>
> Then pitched the idea to a couple publishers, and one came back and said
> they'd like to publish it.  We asked for feedback on the proposed outline
> (since they know the technical book market), and they liked it, so then
> we split the sections up and wrote them.
>
> Not necessarily in order (but mostly so), but we wrote them.  Made sure
> we knew which of us was writing what and what each of us was writing (so
> we could refer to it if necessary), and the publisher's editorial staff
> and technical review staff helped ensure the consistency of style,
> format, and information.

I should imagine having professional people review your work helps a 
lot. I did write a short piece for Internet "publication", and the 
editor's comments were helpful. (Not that I suppose he's a professional 
editor; this is only a small hobby publication, after all...)

>> Didn't Mozart write Twinkle Twinkle Little Star at the age of 6?
>
> Yes, but that doesn't really matter.  My point is that you don't start
> out with something complex, you start out with something simple and work
> up to complex.

Fair enough. Although, like I say, I've written plenty of smaller 
documents, and they've worked out well. It's large documents that end up 
not working.

> When I learned to play the violin, Twinkle Twinkle Little
> Star was one of the first actual pieces of music I learned to play.  So
> was Three Blind Mice.  I didn't tackle things like Lalo's Symphonie
> Espagnole, Bach's Sonatas&  Partidas (only some of which I tried to learn
> on my own), or Howard Hanson's 2nd Symphony (which I actually did get to
> perform in concert in the USSR with the youth orchestra I was in) until
> I'd mastered simpler stuff.

I think Ode to Joy was about the summit of my violin skills. Actually, 
one of the girls at work got given a violin for her birthday (she has no 
idea why), and I was still able to play this. (She brought the violin in 
to work because she couldn't actually get a note out of it. I managed to 
just about fix that too.)

>> When searching with Google, I never know whether I'm just using the
>> wrong search term, or whether the document I'm searching for actually
>> doesn't exist. I rather suspect it's almost always the latter. (Except
>> that every now and then, Darren will pop up and write an almost
>> identical search term and it comes back with useful data...)
>
> The thing is to try different search terms - work out synonyms - a good
> thesaurus can be helpful for that.  Also I find that with Google, the
> fewer words used, the better, unless you're looking for a quote (in which
> case, put part of the quote in quotation marks).
>
> But if you search and come up with nothing and Darren writes an "almost
> identical search term" and comes up with useful data, compare your search
> to Darren's.  Don't say "they're almost the same", but note the
> differences.

I guess mainly it just comes down to extreme pessimism about whether 
there's any useful documents to be found in the first place. (E.g., what 
are the chances of somebody having written a document about wavelets 
that isn't either a vague summary that tells you nothing, or a dense 
technical report which is incomprehensible?)

>>> So I guess the other part is learning how to break a complex topic down
>>> into manageable pieces.
>>
>> Oh, I think I've got that down. It's putting the pieces back together
>> into a coherent whole that I don't do well.
>
> Then that's something that you can work on - that's also a learnable
> skill.  But to do so, it will help those trying to help you to share not
> only the final product, but some of the process used along the way.
> Since that process is what needs refinement, it needs to be examined.
> Again, offer's on the table.

OK, fair enough...

>> Each individual concept isn't too difficult to explain. Trying to figure
>> out the best order in which to explain all of them is maddeningly
>> difficult.
>
> So let's use that as an exercise and see what we come up with. :-)

Heh, OK.

Perhaps not this week though, as (inexplicably) I actually have some 
work to do. Yeah, I know, imagine that...

Post a reply to this message