Re: Portrait of A Noob

["Michael Tiernan" <user=1580@nabble.blu.org>]

 On Tue, Mar 4, 2008 at 9:09 PM, Kristian Erik Hermansen 
<[hidden email]> wrote: 
> Interesting article.  I like some of his points, but disagree with 
>  dense code, even if I am perhaps still a teenager in his eyes. 

I suppose I qualify as a teenager in this respect (or even a toddler) 
but I kind of disagree with his view of commenting code. 

Too often, and his example seems to be one, the code being written 
(regardless of language) is a niche of it's own. No one will be 
reading it who hasn't been reading it for the equivalent of years. No 
one will be maintaining it except for the small group of robed jedi 
who already know the mindset of the original author as well as the 
subsequent construction crew who created this monolith to brilliance 
and efficiency. Additionally, most of the code we see today is as 
disposable as the punch cards of yesterday. Either the code is rock 
solid (as in his compiler example) or disposable modules that when 
they don't work, instead of being understood, they're deleted and new 
code put in it's place. 

I used to work with a guy who wrote code on a 24x80 screen. To him, 
whitespace was a waste. He could fit, oodles of code into that little 
space. A big piece of his work would be 80 cols wide and many many 
screenfuls of text. Sometimes broken at the right margin and picked up 
again at the left. By the way, he was brilliant. His code was a study 
in brilliant thinking and amazing implementation. 

Oh, his code sucked. Why? Because, it was completely unmaintainable. 
In most cases, it was faster and more economical to rewrite what he 
did in a much more simplistic form so that any junior engineer could 
maintain the code. 

I learned a number of valuable lessons from him. One was to try and 
see things as he did. I was and still am in my infancy in this regard. 

Another was "white space isn't a bad thing and it's free." 

Also, if my code is to be used beyond the time I have my hands on it, 
it must be maintainable by someone else who, because of any number of 
factors, doesn't have the time, ability, or desire to become one with 
the metacode and my mind. If it isn't, it's a one-of-a-kind 
demonstration of (some of) my skills akin to a woodworker spending ten 
years of his/her life creating a unique 'doo-dad' that has no purpose 
other than to demonstrate his/her skills. 

The code we are paid to produce isn't done (usually) for the sake of 
doing it. Our skills are applied to solve a problem that, if solved, 
means we make more money and the company grows and proposers. In doing 
that, if we don't make our work maintainable, we've failed. 

At my current engagement, I was chided by someone who felt that the 
shell script I'd done to solve a series of problems was juvenile, 
simplistic and in need of serious rewrite. I used discrete steps at 
each point in the code. I 'cut' data out of a program's output, I ran 
it through 'sort', and did a number of other processing steps. I 
turned to a non-UNIX geek, a guy we work with who supports MS-Windows 
machines, who's knowledge of UNIX is very limited and I asked him if 
he could understand what my script did. He read it for a few minutes 
and said "Yes". I then said "If you run it and it didn't work as you 
expected, what would you do to figure out why?" He pondered the 
question for a moment and said, "I'd look at the output of this step 
here. Then this step here. Then this step here. Until I found where 
things weren't as expected." I turned to the guy who started this 
conversation and said "I win." 

If the code is for my machine, under my control, and will never be 
used by someone else. Hell ya, I'll get creative and flex my mental 
muscles to do things unique and elegant. But if I'm writing code 
(scripts or otherwise) that will be read by someone else, I'll go back 
to the "juvenile" means of writing because I have found that this too 
is a skill that requires exercise. I will put comments in my code that 
include juvenile warnings about the value of a counter NOT being tied 
to the value of a specific buffer maximum or such. 

My commenting isn't just for "them", it's also for me because I am 
going to be dragged away to work on another problem and will have to 
return to this task and I prefer that after a context switch, I know 
where I left off. There are those who measure the code to comment 
ratio as a guideline to proper commenting. Me, my test is if someone 
else can do the work without me. 

So, call me juvinile, unsophistocated, inelegent but don't tell me 
that I waste time putting explainaitions into my code. Any one of us 
could get hit.... win the lottery and disappear from the planet. :) 
-- 
    << MCT >>   Michael C Tiernan. 
    Is God a performance artist? 
    EGO hack vivo quod ago accido. 
    http://www.linkedin.com/in/mtiernan

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss