Discussions of computer programming...

http://blog.slickedit.com/?p=223
http://blog.slickedit.com/?p=224

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

Darren New <dne### [at] sanrrcom> wrote:
> http://blog.slickedit.com/?p=224

  I somewhat disagree with this view. Sure, there are *some* people who
are envious of "noobs" getting the job "done" with their fancy high-level
languages without really understanding what's going on under the hood.
However, I don't think that's the most usual reason for the negative
feelings.

  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.

  And the result can be seen, for example, at thedailywtf.com.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   I somewhat disagree with this view. Sure, there are *some* people who
> are envious of "noobs" getting the job "done" with their fancy high-level
> languages without really understanding what's going on under the hood.
> However, I don't think that's the most usual reason for the negative
> feelings.
> 
>   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.
> 
>   And the result can be seen, for example, at thedailywtf.com.

I think sometimes people *are* just jelous of a higher level language 
making programming "too easy". Those people should get over it.

On the other hand, there certainly *are* some really awful programmers 
who outwardly appear to "get the job done faster" by writing really 
terrible code. Measuring programmer performance by how quickly they 
"deliver" a "solution" is almost as stupid as measuring it my LoC.

In short, I think both points of view are valid. As to which one 
predominates... well, I personally am in *no* position to make an 
authoritative statement about that! ;-) But judging by some of the guys 
I graduated with... hmm, I think incompetent is probably more prevalent. :-S

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> On the other hand, there certainly *are* some really awful programmers 
> who outwardly appear to "get the job done faster" by writing really 
> terrible code. Measuring programmer performance by how quickly they 
> "deliver" a "solution" is almost as stupid as measuring it my LoC.

> In short, I think both points of view are valid. As to which one 
> predominates... well, I personally am in *no* position to make an 
> authoritative statement about that! ;-) But judging by some of the guys 
> I graduated with... hmm, I think incompetent is probably more prevalent. :-S

  Having heard second-hand accounts about real production-level commercial
software from very reliable sources, the common trend in the software and
web development industry is that code is usually an absolutely awful pile
of ugly hacks over older hacks, and that it's usually a miracle that it
works in the first place.
  In other words, clearly the work of people without proper programming
expertise.

  It's considered *normal* in many companies that implementing a feature
takes several months, and if a competent programmer implements it in a
week it causes a jaw-dropping effect. Bosses usually don't have the
slightest idea about how long a specific features should really take
to implement. (Often it goes both ways: Features which are small and
can be cleanly and efficiently implemented in a few days may be implemented
by incompetent programmers in several months, and no boss even wonders
about it. Yet some features which truely require many months to fully
implement even by a team of competent expert programmers might have
completely insane deadline requirements.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   It's considered *normal* in many companies that implementing a feature
> takes several months, and if a competent programmer implements it in a
> week it causes a jaw-dropping effect. Bosses usually don't have the
> slightest idea about how long a specific features should really take
> to implement. (Often it goes both ways: Features which are small and
> can be cleanly and efficiently implemented in a few days may be implemented
> by incompetent programmers in several months, and no boss even wonders
> about it. Yet some features which truely require many months to fully
> implement even by a team of competent expert programmers might have
> completely insane deadline requirements.)

I wonder why this is the case.

I mean, if you want a bunch of construction engineers to design and 
build a bridge, the people doing the work usually have a pretty good 
idea how long it will take. What's different about software engineering?

[Other than the fact that a ridiculously badly designed bridge is 
usually at least moderately self-evident, while bad software isn't 
always...]

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> [Other than the fact that a ridiculously badly designed bridge is 
> usually at least moderately self-evident, while bad software isn't 
> always...]

  Imagine that someone hires someone else to build a bridge. The bridge
is completed and looks pretty on the outside, and it seems to work ok.
However, one day there's a lot of traffic and the bridge collapses.
It results that the bridge engineers were completely incompetent and
built the bridge completely in the wrong way, which caused it to collapse
with heavy traffic.
  In real life those engineers go to jail.

  In programming they get a new contract to develop the project further.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Imagine that someone hires someone else to build a bridge. The bridge
> is completed and looks pretty on the outside, and it seems to work ok.
> However, one day there's a lot of traffic and the bridge collapses.
> It results that the bridge engineers were completely incompetent and
> built the bridge completely in the wrong way, which caused it to collapse
> with heavy traffic.
>   In real life those engineers go to jail.
> 
>   In programming they get a new contract to develop the project further.

...OK, so I'm officially pretty worried here...

Post a reply to this message

Darren New wrote:
> Discussions of computer programming...
> 
> http://blog.slickedit.com/?p=223
If warp does 224, let me take 223 in stead.

I tend to agree in an manner. Of the university students I have had to 
fortune to supervise, when they visited our lab, over the last couple of 
years, an astonishing 100% was unable to write a decent report. They all 
had writing skills that I normally associate with 12-15 year olds. None 
of the reports conformed to a standard structure (intro (including 
problem description), methods, (results), conclusions and discussion). 
Some were almost day by day accounts of what happened '... and then we 
did... and then he said...', most did not even use the spellchecker, and 
don't get me started on grammar. Interestingly, I had nearly no say in 
the grading and they all past their exam before I had a chance to 
correct it. Apparently the society wants technicians and computer 
science experts that are unable to write. But I don't.

Post a reply to this message

andrel wrote:

> I tend to agree in an manner. Of the university students I have had to 
> fortune to supervise, when they visited our lab, over the last couple of 
> years, an astonishing 100% was unable to write a decent report. They all 
> had writing skills that I normally associate with 12-15 year olds. None 
> of the reports conformed to a standard structure (intro (including 
> problem description), methods, (results), conclusions and discussion). 
> Some were almost day by day accounts of what happened '... and then we 
> did... and then he said...', most did not even use the spellchecker, and 
> don't get me started on grammar. Interestingly, I had nearly no say in 
> the grading and they all past their exam before I had a chance to 
> correct it. Apparently the society wants technicians and computer 
> science experts that are unable to write. But I don't.

OK, now you're just describing *me*. :-(

I have no idea how to write a report...

Post a reply to this message

Orchid XP v8 wrote:
> andrel wrote:
> 
>> I tend to agree in an manner. Of the university students I have had to 
>> fortune to supervise, when they visited our lab, over the last couple 
>> of years, an astonishing 100% was unable to write a decent report. 
>> They all had writing skills that I normally associate with 12-15 year 
>> olds. None of the reports conformed to a standard structure (intro 
>> (including problem description), methods, (results), conclusions and 
>> discussion). Some were almost day by day accounts of what happened 
>> '... and then we did... and then he said...', most did not even use 
>> the spellchecker, and don't get me started on grammar. Interestingly, 
>> I had nearly no say in the grading and they all past their exam before 
>> I had a chance to correct it. Apparently the society wants technicians 
>> and computer science experts that are unable to write. But I don't.
> 
> OK, now you're just describing *me*. :-(
I thought about including a disclaimer that 'any resemblance to a p.o-t 
regular or mascot is purely a coincidence' but decided against it.
> 
> I have no idea how to write a report...
So how did you manage to graduate from university then? Did you not do a 
small research project?

Post a reply to this message

>> OK, now you're just describing *me*. :-(

> I thought about including a disclaimer that 'any resemblance to a p.o-t 
> regular or mascot is purely a coincidence' but decided against it.

Heh. And to think a few people claimed I had writing skills... despite 
the fact that I can't spell, can't write a report, and have lousy 
sentence construction. :-S

>> I have no idea how to write a report..

> So how did you manage to graduate from university then? Did you not do a 
> small research project?

Yes. I failed that particular module...

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Apparently the society wants technicians and computer 
> science experts that are unable to write. But I don't.

  Quite amazingly, this seems to be so even in academic circles. Well,
at least here.

  One could assume that a person who graduates as MSc, which requires,
among other things, writing an academic paper (the MSc thesis) on some
subject, would know how to write. It's an academic grade, after all, and
academic reseach is all about writing papers and publications.

  But no. Each year hundreds of people get their MSc grade here without
knowing even the basics of proper Finnish or English grammar. Their works
(which have not been spell-checked and beautified by third-parties) are
full of grammatical mistakes and poor language.

  Knowing how to write properly (in any language) is not a requisite for
admission in universities of technology, there are no mandatory courses
on academic writing (or any kind of writing), there aren't even optional
courses on writing, and bad grammar and poor writing can never be used
to penalize when grading exams or other types of written work. Basically
you are allowed to write however you want, and you are in no way expected
to be able to write properly.
  The only piece of work where some grammar is necessary is the MSc thesis,
but given that there are no requisites nor courses on the subject, they are
very lenient, and they don't mind at all if third-parties spell-check and
beautify MSc theses. In fact, it's a very common practice.

  I have always STRONGLY disagreed with this policy, and I have never heard
one single rational reason why this is done, but what can I do? It just is
the way it is.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   In programming they get a new contract to develop the project further.

LOL.  Bingo!

That, and in other situations, nobody makes big changes after the specs 
are finished.

SQL Server: Hey, we need to support .NET stored procedures, and XML output.

Downtown: You know, we're glad you finished the 50-story office 
building, because now it's full of tenants. But could you add a couple 
of stores between 40 and 41?  Or at least put another bank of elevators 
on the other side of the lobby too?  Be sure not to disturb any of the 
office work already going on in the building.

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

Warp wrote:
>   Quite amazingly, this seems to be so even in academic circles. Well,
> at least here.

Yah. And I've found most marketing people, many of whose jobs it is to 
write, have little or no grasp of simple things like sentence construction.

It just takes lots of practice and correction. I was fortunate to go to 
a grade school (as in, first through 12th grade) where they actually 
hammered on you ever single week to get you to improve. You started with 
"here's a topic, take it home, and bring back a one-page essay about it 
next week." It ended with "take a seat, here's your topic, you have 20 
minutes for a 2-page-with-outline essay discussing the topic."

I think the Ph.D. stuff (at least in the USA) is much more about 
reading, writing, and presenting than it is about the actual field of 
research.  Maybe places like MIT teach you more technical stuff in the 
PhD degree than the Masters degree, but that isn't the case in any of 
the places where I or my friends went.

-- 
   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" <voi### [at] devnull> a écrit dans le message de news: 
47f7dabb$1@news.povray.org...
>>> OK, now you're just describing *me*. :-(
>
>> I thought about including a disclaimer that 'any resemblance to a p.o-t 
>> regular or mascot is purely a coincidence' but decided against it.
>
> Heh. And to think a few people claimed I had writing skills... despite the 
> fact that I can't spell, can't write a report, and have lousy sentence 
> construction. :-S

You *** do *** have writing skills, otherwise people would just skip your 
posts and never answer them (even if it's just for snarking). You know how 
to tell stories and make them interesting, even ones based on really dull 
material. The self-pitying angle comes off pretty well and is somehow 
endearing (when it could be horribly annoying), in some Woody Allenesque 
way. Also your spelling isn't bad, except for some occasional glaring 
lapses. What you may lack is better material to work with and some literary 
background to give you inspiration and pointers, but otherwise what your 
write is enjoyable.

G.

Post a reply to this message

Gilles Tran escribió:
> You *** do *** have writing skills, otherwise people would just skip your 
> posts and never answer them (even if it's just for snarking). [...]
 > but otherwise what your write is enjoyable.

That's why he's our mascot, isn't it? :)

Post a reply to this message

Gilles Tran wrote:
> What you may lack is better material to work with and some literary 
> background to give you inspiration and pointers, but otherwise what your 
> write is enjoyable.

Yah, plus your technical writing isn't bad either, from the few snippets 
you've posted here when you write about things you enjoy.

You might need some instruction on how to (say) write a report for 
management, or something like that, but that's a skill that's relatively 
easy to learn with a bit of practice. It *does* take instruction, so you 
can't just keep trying an expect to get better without feedback. (Not 
unlike resumes, really.)

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

Gilles Tran wrote:
> "Orchid XP v8" <voi### [at] devnull> a écrit dans le message de news: 
> 47f7dabb$1@news.povray.org...
>>>> OK, now you're just describing *me*. :-(
>>> I thought about including a disclaimer that 'any resemblance to a p.o-t 
>>> regular or mascot is purely a coincidence' but decided against it.
>> Heh. And to think a few people claimed I had writing skills... despite the 
>> fact that I can't spell, can't write a report, and have lousy sentence 
>> construction. :-S
> 
> You *** do *** have writing skills, otherwise people would just skip your 
> posts and never answer them (even if it's just for snarking). You know how 
> to tell stories and make them interesting, even ones based on really dull 
> material. The self-pitying angle comes off pretty well and is somehow 
> endearing (when it could be horribly annoying), in some Woody Allenesque 
> way. Also your spelling isn't bad, except for some occasional glaring 
> lapses. What you may lack is better material to work with and some literary 
> background to give you inspiration and pointers, but otherwise what your 
> write is enjoyable.
> 
Sure, but this and his blog are something different than a report of a 
couple of weeks stay at a research lab. Spelling mistakes and bad 
sentences are common in newsgroups because people take too little time 
and write too late at night (my god it is nearly 12 already). In blogs 
it may depend on the writer, but normally you expect less trivial errors 
but allow for structural abnormalities as it is a free form text format. 
But if you are unable to construct a logical line of argument in a paper 
you can not be a good programmer as the skills required are the same. 
That was one of the things the author of 223 meant in his paper, I 
think. And if he didn't, let me say it. In summary: yes, I also think 
Andy may be a reasonable programmer. ;)

Post a reply to this message

"andrel" <a_l### [at] hotmailcom> a écrit dans le message de news: 
47F### [at] hotmailcom...
> Sure, but this and his blog are something different than a report of a 
> couple of weeks stay at a research lab.

I'm pretty sure that Andy is perfectly able to write a decent report. It's 
just that the stuff he has to write about bores him to death so he won't 
even try to http://www.google.com/search?q=%22how+to+write+a+report%22 that.

G.

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray, Cinema 4D and Poser computer art
- Posters

Post a reply to this message

Gilles Tran wrote:
> "andrel" <a_l### [at] hotmailcom> a écrit dans le message de news: 
> 47F### [at] hotmailcom...
>> Sure, but this and his blog are something different than a report of a 
>> couple of weeks stay at a research lab.
> 
> 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. In the same vain, I'm 
pretty sure that Andy is perfectly able to find a decent girlfriend. 
Yet, here the current facts seem to point another way.

> It's just that the stuff he has to write about bores him to death so he
> won't even try to http://www.google.com/search?q=%22how+to+write+a+report%22
 > that.

I *have* seem him use google a few times recently. Perhaps he did learn 
a few things since leaving university. He may not have been able to 
write a report then, but past performance is no guarantee of future 
results.

Post a reply to this message

>> 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 writing tends to lack high-level order - much like 
my thought processes.

["So you see, the derivative of a Nth order polynomial is a polynomial 
of order N-1. And that means - ooo, I wonder if dolphins can hear in 
stereo?"]

> In the same vain, I'm 
> pretty sure that Andy is perfectly able to find a decent girlfriend. 
> Yet, here the current facts seem to point another way.

As a matter of fact, I'm going to meet a friend in a pub this very 
afternoon. And I'm *hoping* he's convinced a certain lady he knows to 
tag along... ;-)

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..."]

Post a reply to this message

Nicolas Alvarez wrote:

> That's why he's our mascot, isn't it? :)

You know, a few minutes after I posted "Phrases", I did wonder if maybe 
I might have accidentally created another bukkakke moment. :-S

Post a reply to this message

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?

> You might need some instruction on how to (say) write a report for 
> management, or something like that, but that's a skill that's relatively 
> easy to learn with a bit of practice. It *does* take instruction, so you 
> can't just keep trying an expect to get better without feedback. (Not 
> unlike resumes, really.)

Interestingly, my experience with the disaster recovery procedure 
document suggests otherwise...

[It used to be 3 pages of whaffle about "hey, um, if X fails we could 
maybe do Y, unless Z and then... uh... that's quite unlikely?" The sort 
of thing a student might dash off half an our before the hand-in date. 
Full of unecessary technical jargon, most of it used incorrectly.

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

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 writing tends to lack high-level order - much like 
> my thought processes.
> 
> ["So you see, the derivative of a Nth order polynomial is a polynomial 
> of order N-1. And that means - ooo, I wonder if dolphins can hear in 
> stereo?"]

Well, can they?

>> In the same vain, I'm pretty sure that Andy is perfectly able to find 
>> a decent girlfriend. Yet, here the current facts seem to point another 
>> way.
> 
> As a matter of fact, I'm going to meet a friend in a pub this very 
> afternoon. And I'm *hoping* he's convinced a certain lady he knows to 
> tag along... ;-)
> 
> 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..."]

What does 'make out' mean in this context?
BTW I am not sure if you have already past your 'cute' date (because of 
being of the wrong sex to judge). You might try to go for 'interesting'. 
I think that is much safer. You can do that for many years to come, even 
outside of the context of chatting up ladies in bars. And you do have 
some unique features.

Post a reply to this message

Orchid XP v8 escribió:
> 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

Orchid XP v8 escribió:
>> 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

Chambers escribió:
> 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

Chambers wrote:

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

Ah yes, the "tell them thrice" structure.

I pretty much suck at that. It's true... :-{

Post a reply to this message

Orchid XP v8 escribió:
> 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.

The RCX has numbered variables (16-bit signed integers). There is no 
real access to "memory". Although the 2.0 firmware supports indirect 
access (indirect(3) reads get_variable(get_variable(3)) ) so things like 
indexing an "array" in a loop is possible.

Post a reply to this message

Chambers wrote:

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

I looked at Clean. It isn't.

I also looked at F#. And didn't like it much. Ditto for Erlang. And 
Lisp. And Prolog. (But that was a very long time ago...)

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

You're talking to somebody who learned PostScript in their lunch break 
one day. Just for the fun of it. BECAUSE I WAS BORED!!

Holy crap, I need a different job! o_O

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

Woah... and here I am trying to get people to learn something that's so 
fundamentally weird it freaks Pixar employees out... o_O

Post a reply to this message

andrel a écrit :
> 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.

I wonder how the (very good, by the way) analogy applies to the 
functional programing so dear to Andrew :-)

If he starts writing reports that resemble Haskell programs, there will 
be recursive sections all over the place :-D

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:

> I wonder how the (very good, by the way) analogy applies to the 
> functional programing so dear to Andrew :-)
> 
> If he starts writing reports that resemble Haskell programs, there will 
> be recursive sections all over the place :-D

If it was Haskell, you could define constructs in arbitrary order and it 
would still work! ;-)

Actually, hell, see my logic programming source code post. It's valid, 
parsable, runnably Haskell source code...

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

Oh come on, pull the other one.

> I have never, ever thought about writing stuff that way... 

I am not really surprised :( IMHO it should have been a recurring theme 
in your CS education. The fact that it wasn't confirms any prejudice 
that they still mainly teach technical subjects but fail to teach what 
*programming* is about.

> Damn, so *this* is what being intelligent must feel like? 

I think it has more to do with finding the right metaphor for a specific 
  person than with intelligence. But if it helps you to look at texts in 
a new way and helps you to write even*) better structured texts I will 
be a very happy man indeed.

> Heh. I gotta try writing something now...
Yes, do so.


*) 'even', because you knew it instinctively at a certain level and were 
writing good stuff already **)

**) footnote aka an inline function.

Post a reply to this message

>> My God... this is genius. Genius, I say! 0_0
> 
> Oh come on, pull the other one.

Who said ideas have to be complex to be revolutionary? E = mc^2

> I am not really surprised :( IMHO it should have been a recurring theme 
> in your CS education. The fact that it wasn't confirms any prejudice 
> that they still mainly teach technical subjects but fail to teach what 
> *programming* is about.

Oh, sure, he had lessons about how to write reports. It just didn't make 
a lot of sense to me. (Why would you tell somebody something thrice? 
That makes no sense.) Well OK, some of it made sense. (Like, write it 
for the correct target audience.)

I guess the problem fundamentally boils down to me being a very messy 
thinker who's easily distracted.

>> Damn, so *this* is what being intelligent must feel like? 
> 
> I think it has more to do with finding the right metaphor for a specific 
> person than with intelligence.

I meant, being *able* to think up the correct metaphore is really 
intelligent. Reports are like code. It seems so *obvious* in retrospect...

>> Heh. I gotta try writing something now...
> Yes, do so.

Wait - how do I make people read it?

Oh yeah - don't write about Haskell. That'll do it... :-/

> *) 'even', because you knew it instinctively at a certain level and were 
> writing good stuff already **)
> 
> **) footnote aka an inline function.

Surely that's an out-of-line function? :-.

Post a reply to this message

Orchid XP v8 wrote:
>>> My God... this is genius. Genius, I say! 0_0
>>
>> Oh come on, pull the other one.
> 
> Who said ideas have to be complex to be revolutionary? E = mc^2
> 
>> I am not really surprised :( IMHO it should have been a recurring 
>> theme in your CS education. The fact that it wasn't confirms any 
>> prejudice that they still mainly teach technical subjects but fail to 
>> teach what *programming* is about.
> 
> Oh, sure, he had lessons about how to write reports. It just didn't make 
> a lot of sense to me. (Why would you tell somebody something thrice? 
That is the second time you mention that. I don't think I ever did that. 
Besides we are often required to tell about our research within 10 
minutes. Telling the audience once is already difficult enough.
> That makes no sense.) Well OK, some of it made sense. (Like, write it 
> for the correct target audience.)
My guess would be that this teacher couldn't write a decent report 
himself. And boy did he miss all those opportunities to discuss 'divide 
and conquer' in the context of writing reports, and all those strategies 
to start writing something like 'bottom up', 'top down' etc, etc. Not 
even being able to use a flowchart to analyse why a report was good or 
not. Pity.

Post a reply to this message

Orchid XP v8 wrote:
> 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.

Generally, you should cut about 2/3 of your first draft, no matter how 
good it is.  Whatever fluff you come up with on the first write, you 
have better stuff inside your head waiting for the second draft.

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

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> 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.

  OTOH, starting too low can lead to what I call the C-hacker syndrome.
(It doesn't have to necessarily be a C coder per se, but the vast majority
of these people are.)

  The "C-hacker" wants to control every single clock cycle his code
requires. He only sees low-level inefficiencies everywhere (and will
often completely overlook the big picture, ie. the *real* bottlenecks).
Often they will fill their code with obfuscated "cool tricks" they have
learned from other C-hacker friends and websites.

  The C-hacker will have a very strong prejudice against higher-level
programming paradigms and languages. Especially object-oriented
programming is the most prominent red flag for the C-hacker. He'll ramble
all day long about how OOP sucks big time. None of his arguments will make
the least amount of sense, though (all of the arguments will be irrelevant,
exaggerated, or in the vast majority of cases, just plain false).

  The C-hacker will have a very strong prejudice against any features
and libraries which work like a "black box", ie. doing things inside
that the C-hacker has no control over. He wants everything to be open
and controlled by him. He prefers writing 5000 lines of code to create
his own (often inefficient and unsafe) implementation of something rather
than using an existing library.

  The C-hacker emphasizes the so-called "hacker optimization", even to
the point where it becomes completely counter-productive. His "hacker
optimized" code will usually be an obfuscated and unmaintainable mess
which nobody can read (not even himself after a year). He has the false
notion that low-level programming, "close to the hardware", somehow
automatically makes the code faster. Quite ironically, in many cases his
"hacker optimized" code will actually be quite inefficient because he's
using the wrong algorithms and data containers for the job.

  The worst trait of the C-hacker is his inability to learn proper
programming principles and techniques. He *fights* against them instead
of wanting to learn them. Resistance to change is deeply ingrained.

-- 
                                                          - Warp

Post a reply to this message