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