 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Now, if only I knew the magical incantation. [You know, the one that
> makes her go from "ok, I'm sitting here with a bunch of people chatting"
> to "hey, that boy is cute. I should make out with him..."]
Some pages from a software development wiki:
http://c2.com/cgi/wiki?DatingIsHarderThanProgramming
http://c2.com/cgi/wiki?DatingPatterns
http://c2.com/cgi/wiki?ExtremeDating ("Dating in the mode of Extreme
Programming")
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Darren New wrote:
>
>> Yah, plus your technical writing isn't bad either, from the few
>> snippets you've posted here when you write about things you enjoy.
>
> Ooo... really?
Really. You could write informal white-papers that other geeks would
read, methinks. (At least, I read what you write and find it interesting.)
The part others seem to think you lack is the knowledge of how to
structure a document that's bigger. You need to be able to say (a) why
would the reader want to read this document, and (b) present it in an
order and form that makes it easiest to understand.
> Interestingly, my experience with the disaster recovery procedure
> document suggests otherwise...
Oh. OK. Well, I haven't seen that. :-) I'm not saying you can't, I'm
saying that earlier in this thread, you said
> I have no idea how to write a report...
Based on that...
> That document is now 25 pages long, and consists of a high-level
> non-technical explanation of what systems we have in the first place,
> the fault tolerance measures it has, the emergency contracts he hold,
> etc etc before it even goes *into* disaster recovery steps. And then,
> for each disaster, it explains (in non-technical language) exactly what
> impact such a fault would have, and lists various recovery options.
> Apparently "external auditors love it". Make of that what you will...]
It means that "I have no idea how to write a report" is incorrect. It
sounds like exactly what you ought to be writing.
Why do you say you don't know how to write a report, when you're
getting praise for the quality of your report from people whose job is
to *judge the quality of your report*. :-)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I'm good at writing short, unstructured things. When trying to explain
> big concepts, I have trouble figuring out where to start and what order
> to say things in. My writing tends to lack high-level order - much like
> my thought processes.
Yeah, that's a hard thing to get over. The trick I've found is you need
to be able to hold the whole thing in your head at once. The only way
to do that is to abstract it repeatedly until it all fits.
In other words, write an outline, and then rearrange the outline. Make
sure what you want to say is all in the outline. Expand parts of the
outline, concentrating on only those sections, until the outline
includes enough detail that you know where everything you want to say goes.
I bet if you were to go back and generate an outline of your disaster
recovery report, it would look great. Then you just have to get in the
habit of doing that for every document.
> Now, if only I knew the magical incantation. [You know, the one that
> makes her go from "ok, I'm sitting here with a bunch of people chatting"
> to "hey, that boy is cute. I should make out with him..."]
Heh. It's not magic. Just be your witty charming self.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> http://c2.com/cgi/wiki?DatingIsHarderThanProgramming
Thanks for that. That's way funny.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Yah, plus your technical writing isn't bad either, from the few
>>> snippets you've posted here when you write about things you enjoy.
>>
>> Ooo... really?
>
> Really. You could write informal white-papers that other geeks would
> read, methinks. (At least, I read what you write and find it interesting.)
Heh. I've still failed to convert even one single person to Haskell yet.
>:-)
> The part others seem to think you lack is the knowledge of how to
> structure a document that's bigger. You need to be able to say (a) why
> would the reader want to read this document, and (b) present it in an
> order and form that makes it easiest to understand.
Yeah, I'm not too good at that. I know that you're supposed to say
everything thrice and all that, I'm just not good at ordering my
thoughts in a coherant way.
> Why do you say you don't know how to write a report, when you're
> getting praise for the quality of your report from people whose job is
> to *judge the quality of your report*. :-)
It's not a report, it's a policy document. Different set of rules...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I'm just not good at ordering my thoughts in a coherant way.
Almost nobody is. It takes practice and discipline.
> It's not a report, it's a policy document. Different set of rules...
You organized it the same way as a "report." Probably because you really
know that whole bit inside-out, so you didn't have to organize it in
your own head.
Seriously, try building an outline first next time you have to write
something, even if it's only a page or two long.
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I'm good at writing short, unstructured things. When trying to explain
>> big concepts, I have trouble figuring out where to start and what
>> order to say things in. My writing tends to lack high-level order -
>> much like my thought processes.
>
> Yeah, that's a hard thing to get over. The trick I've found is you need
> to be able to hold the whole thing in your head at once. The only way
> to do that is to abstract it repeatedly until it all fits.
>
> In other words, write an outline, and then rearrange the outline. Make
> sure what you want to say is all in the outline. Expand parts of the
> outline, concentrating on only those sections, until the outline
> includes enough detail that you know where everything you want to say goes.
I find I tend to sit down, start writing, generate loads of ideas, run
off at tangents, and end up with a bunch of stuff that makes sense, but
misses out lots of interesting details that I couldn't fit into the flow
of the text.
Oddly, even when I write an extensive outline, I still end up managing
to muddle things up. The text ends up not matching the outline very
well. :-S
>> Now, if only I knew the magical incantation. [You know, the one that
>> makes her go from "ok, I'm sitting here with a bunch of people
>> chatting" to "hey, that boy is cute. I should make out with him..."]
>
> Heh. It's not magic. Just be your witty charming self.
Ooo, I've never tried that before.
Oh, wait...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>>> I'm pretty sure that Andy is perfectly able to write a decent report.
>>
>> He said he isn't. So who am I going to believe.
>
> I'm good at writing short, unstructured things. When trying to explain
> big concepts, I have trouble figuring out where to start and what order
> to say things in.
My way of looking at a text or presentation: Look at it as if it is a
program. The conclusions are the main routine. The lines in the
conclusions call various subroutines (aka the previous sections and
slides) that can in turn call other subroutines (paragraphs). You should
therefore be able to draw a flowchart of the concepts in your text. A
text is good if 1) no external subroutines are called (i.e. everything
is defined within the text or common knowledge to the audience) 2) there
are no dead branches. 3) all subroutines are define before use or
explicitly declared as something to fill in later.
When I said that a programmer should be able to write a decent report
(or give a good presentation for that matter) because the skills
required are the same, the above is what I meant.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I'm good at writing short, unstructured things. When trying to explain
>> big concepts, I have trouble figuring out where to start and what
>> order to say things in.
>
> My way of looking at a text or presentation: Look at it as if it is a
> program. The conclusions are the main routine. The lines in the
> conclusions call various subroutines (aka the previous sections and
> slides) that can in turn call other subroutines (paragraphs). You should
> therefore be able to draw a flowchart of the concepts in your text. A
> text is good if 1) no external subroutines are called (i.e. everything
> is defined within the text or common knowledge to the audience) 2) there
> are no dead branches. 3) all subroutines are define before use or
> explicitly declared as something to fill in later.
> When I said that a programmer should be able to write a decent report
> (or give a good presentation for that matter) because the skills
> required are the same, the above is what I meant.
My God... this is genius. Genius, I say! 0_0
I have never, ever thought about writing stuff that way... Damn, so
*this* is what being intelligent must feel like? Heh. I gotta try
writing something now...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> My way of looking at a text or presentation: Look at it as if it is a
>> program. The conclusions are the main routine. The lines in the
>> conclusions call various subroutines (aka the previous sections and
>> slides) that can in turn call other subroutines (paragraphs). You
>> should therefore be able to draw a flowchart of the concepts in your
>> text. A text is good if 1) no external subroutines are called (i.e.
>> everything is defined within the text or common knowledge to the
>> audience) 2) there are no dead branches. 3) all subroutines are define
>> before use or explicitly declared as something to fill in later.
>> When I said that a programmer should be able to write a decent report
>> (or give a good presentation for that matter) because the skills
>> required are the same, the above is what I meant.
>
> My God... this is genius. Genius, I say! 0_0
>
> I have never, ever thought about writing stuff that way... Damn, so
> *this* is what being intelligent must feel like? Heh. I gotta try
> writing something now...
And Darren's suggestions about making an outline first match the analogy
too (you should design your code structure before actually filling in
actual code inside functions / methods).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
