>> 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

Warp wrote:
>   I believe that the most usual reason for the negative attitude is
> that the "noobs" are getting the job "done" faster, but at the cost
> of software quality. The software made by a newbie usually lacks
> robustness and efficiency. However, because bosses usually cannot
> see past the GUI, they are fooled into thinking that the newbie is
> actually a better programmer than the experienced one because he got
> something visible done faster. Then they hire the newbie and kick out
> the experienced programmer.

This reminds me of a problem that I saw working in the math study center 
at my local college.

We were explicitly told not to help the Business Math students with 
their homework, because the requirements of what they wanted were so 
different from what students in the regular math courses needed. 
Specifically, they didn't need to know "how it worked", just "how to 
press buttons on a calculator to get the correct result".  As a result, 
it was felt that our teaching them correct mathematical principles would 
be a waste of time, both theirs and ours.

This drove me nuts.  In fact, on several occasions (when there weren't 
other students needing help), I explicitly ignored the instructions and 
helped the business math students.  But I wouldn't do it the way their 
instructors wanted (press this button, get this result).  Instead, I 
would teach them the theory behind what they were doing, to the point 
that if they forgot the correct button press, they could still work out 
the answer (or at least, figure out what buttons to press on their own). 
  Usually, they expressed gratitude for my helping them to finally 
understand what they were doing.

I think software is the same way.  While I never coded with 1s and 0s, 
relatively soon after learning BASIC I learned x86 assembly, in real 
(not protected) mode.  Things like pointers aren't a problem to me, 
because they're an inherent part of computer architecture (virtually 
everything uses pointers), and I understand the underlying architecture 
fairly well.  I'm not against using VB, C# or LISP, per se.  But I *do* 
think that my understanding of the underlying architecture is important 
even in those languages.

The disdain that "real" programmers feel for newbies who crank out quick 
code using "toy" languages is, I think, more akin to the disdain "real" 
mathematicians feel towards business math majors.  Sure, they can "press 
the buttons", but they don't really know what they're doing.  It's not 
about jealousy - after all, many programmers who started out writing 
assembly code are now using higher level languages and cranking out code 
just as quickly.  It's about perceived understanding of what your code 
actually does.

Personally, I think this understanding is so important that I would say 
*all* programmers should, at one point or another, learn to write 
complete programs in assembly language, by hand.  Not that they should 
use machine language for their jobs, but because knowing how computers 
*really* work will help them write better programs in the long run.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

> Personally, I think this understanding is so important that I would say 
> *all* programmers should, at one point or another, learn to write 
> complete programs in assembly language, by hand.  Not that they should 
> use machine language for their jobs, but because knowing how computers 
> *really* work will help them write better programs in the long run.

I never went lower level than C. (well, I have looked at the 
assembly-like code for LEGO RCX, but I doubt that counts; there aren't 
even pointers there) I think some day I should learn asm...

Post a reply to this message

Chambers wrote:

> Personally, I think this understanding is so important that I would say 
> *all* programmers should, at one point or another, learn to write 
> complete programs in assembly language, by hand.  Not that they should 
> use machine language for their jobs, but because knowing how computers 
> *really* work will help them write better programs in the long run.

This, presumably, is why my course included a module on microprocessors, 
machine code, binary representation, etc. It probably didn't help in the 
slightest that this module was taught by Mr Apothetic. Seriously, I have 
*no idea* WTF this guy's problem was, but damn...!

"Well this stuff is in the exam so I *suppose* I'd better teach it to 
you. But it's pointless really. You'll never actually *need* to know 
this stuff." Way to motivate your students, man! [Yes, these are the 
actual words he used. His emphasis.]

But then, his views on BP were quite similar. "Oh yes, I understand 
they're trying to 'rebuild Colossus'. Pointless really. The actual 
machine was destroyed, so it'll never really be exactly like the 
original. And what will they *do* with it anyway?" Jesus, dude, take a 
pill or something!!

It really made me sad. This _would_ have been one of the most 
interesting parts of the course... much more fun than learning Java or 
how to balance accounts...

Post a reply to this message

Nicolas Alvarez wrote:

> I never went lower level than C. (well, I have looked at the 
> assembly-like code for LEGO RCX, but I doubt that counts; there aren't 
> even pointers there) I think some day I should learn asm...

The concept of assembly without pointers bemuses me.

I don't "get" what's so hard about pointers. All data is stored in the 
computer's memory. The memory is a vast grid of numbered cells. Each 
cell's number is called an "address". A "pointer" is simply something 
that holds the address of something else - it "points to" something. The 
End.

Now, pointers and typecasting... scary stuff!

Post a reply to this message

Darren New wrote:
> 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.

The following structure from public speaking applies to pretty much any 
technical document or report, as well.

a) Tell the audience what you're going to say.
b) Say it.
c) Tell them what you said

:)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Orchid XP v8 wrote:
> Heh. I've still failed to convert even one single person to Haskell yet. 
>  >:-)

Consider that I'd never even *heard* of Haskell before I read your posts 
here.  In fact, I *still* haven't gotten around to learning LISP, Ruby, 
Perl, Python, Smalltalk, Lua, or any of a number of languages, although 
I *have* looked at them and considered learning them.

In fact, C# is the first time in about 10 years now that I'm learning a 
*new* language, and its only a derivative of the ones I already know.

Getting people to invest time into something like learning a new 
language is difficult, at least, and close to impossible, in many 
situations.  Just keep plugging, and don't lose hope :)

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message