brilliance or... easy erasure?

I spent this weekend doing 'home improvement' projects. You know, the sort of thing where 'measure twice, cut once' ends up saving your @ss more than once. In my case, 'measure many' would be more appropriate, since I still screwed up more times than not. =8^%

It got me to thinking about programming in general, and how often I rely on ^w to hide my sins. Am I really brilliant, or do I just cut things many, many, many times while relying on the fact that I can run it again and again without being found out? <red>

I was just whacking a simple CGI to replace an old Korn shell routine with one that would build an e-mail attachment from a data set as an .xls file, and the shell script didn't have any ¶m=value sets, only space-delimited values. I went around and around with $q->param and $q->keywords and perldoc CGI, trying to figure out why

#! /usr/bin/perl
use warnings;
use strict;
use CGI qw/:standard/;
my $q = new CGI;
my @a = $q->param('keywords');
print $q->header;
print $q->start_html('Export Data to Spreadsheet Format');
foreach $a (@a) { print $a . "\n"; }
my $s = @a;
print "$s\n";
print $q->end_html;
[download]

gave me back one string on one line. Now, of course, all youse script kiddie geniuses out there immediately pounce on me and say "Doofus! you need to use <BR> tags to separate lines in HTML!" And, of course, I know that, too. My point isn't to show the finer nuances of HTML formatting and CGI.pm, it's to laugh at my own ability to go round the mulberry bush waaay too many times before I sit down and think about what I'm doing.

But then, looking at the neat stuff I do create in oh-so-many different application areas, I have to give myself a little credit. Yes, I use the delete key a lot more than I use the structured analysis portion of my brain. Truth is, most often the SA part of my brain is more focused on the bigger picture of what I'm trying to create than on the nit-picky details of how it gets done, and I don't want to bail out of my cloud just to see if it's raining down below. Yes, I lost ten minutes to a silly mistake, but, when considering that I'm decoding and updating a web system designed and implemented a long time back in languages I don't use by somebody who's too busy to explain (or remember) it now, that's a small price to pay.

So, I guess I'm not so red-faced after all, when thinking of my programming style. It's not like I'm still coding in the Dark Ages of overnight batch jobs and punch decks. I certainly wouldn't last long as a nurse in a cardiac ward or as a cabinetmaker, but, as a programmer who gets thrown a lot of the challenges others duck, I do all right. It's just that sometimes my socks don't match... :D

Comment on brilliance or... easy erasure? Download Code

Replies are listed 'Best First'.
Re: brilliance or... easy erasure? by xdg (Monsignor) on Sep 06, 2005 at 15:12 UTC
In my intro comp-sci classes years and years ago, my professor used to describe this as the difference between "hacking" and "software engineering". "Hacking" was the interative try/fail/fix cycle, driven more by intuition than by design. "Software engineering" was supposed to replace that by designing it right the first time so that debugging was errors in coding, not errors in design. Ironically -- or maybe intentionally -- test-driven-development is just a structured (software engineering) approach to the "try/fail/fix" cycle: Write test Fail test Write minimal code to pass test Refactor to cleanup ugly code -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^2: brilliance or... easy erasure? by samizdat (Vicar) on Sep 06, 2005 at 15:50 UTC
Indeed. I have only ten credits of CS to my name, so I would definitely fall into the 'hacker' camp. This also speaks to the argument that's often raised of whether one should specialize in one language and learn it well or be adept at switching gears and contexts so that one can solve many problems using the tools at hand. Could I be better if I were more disciplined in my analysis? Perhaps so, but I wonder if I would have developed the abilities that I have to hold many levels of a problem in my mind at once. One could say that -- using my example -- a more disciplined, careful coder would not have made that mistake, and, thus, would have been ten minutes more productive. Yes, indeed, he would have. Could he even be tackling that task, though, if his experience was only in Perl and HTML? There are environments where expertise is important, and careful craftsmanship. Certainly, middle managers of big corporations like to hire such programmers. Certainly, CS professors are drawn from these ranks. However, who makes more money? The problem solver or the detail-freak? The entrepreneur or the academic? There's an interesting parallel that showed up at a conference I attended of professors of MBA schools. One of the more controversial, but well-documented, papers presented was a paper that examined the correlation between years of business school completed and business success. The paper embarrassed the heck out of the professors, of course, because it showed an inverse correlation. That is, the more years of business school completed, the less likely the sampled group was to be successful in business. :D	[reply]
Re^3: brilliance or... easy erasure? by GrandFather (Saint) on Sep 06, 2005 at 22:09 UTC
To speak just your first muse: the more languages and ways of doing things you have learned, the better able to solve problems you are likely to be. Different languages have different strengths and weaknesses and tend to encourage using different techniques for solving problems. For example, in Perl we often reach for a regex (in one of it's many guises) or a hash to get the job done. Those tools provide a completely different way of thinking about problems than languages like C++ where hashes and regexs are way down the list. However, having used Perl somewhat, I now have a slightly different approach to writing C++, and I really miss modifiers! Bottom line: if you have the opportunity to learn a new language, do it - you will benefit from the effort. Perl is Huffman encoded by design.	[reply]
Re: brilliance or... easy erasure? by zentara (Archbishop) on Sep 07, 2005 at 09:35 UTC
*the iterative try/fail/fix cycle, driven more by intuition than by design* Yes but there is a great advantage to doing it that way....you uncover unexpected bugs in a step-by-step process. Whearas the CS approach of designing, can leave bugs deeply nested, only to be discovered later.....which then forces you to "rewrite-and -debug" stepwise....basically doing it twice. It's probably why Java takes so long to develope stuff compared to Perl. Nature and evolution use the iterative try/fail/fix cycle, so maybe the "evolutionary approach to design" isn't so bad after all. I'm not really a human, but I play one on earth. flash japh	[reply]
Re: brilliance or... easy erasure? by jhourcle (Prior) on Sep 07, 2005 at 15:01 UTC
"Doofus! you need to use <BR> tags to separate lines in HTML!" Or, you just send the correct headings, so that it's intereted as plain text, and not HTML. If you wanted HTML, you'd also have to supply the correct body, etc. (unless you were explicitly trying for HTML1 conformance.) `print $q->header('text/plain');`	[reply] [d/l]
Re: brilliance or... easy erasure? by Cap'n Steve (Friar) on Sep 08, 2005 at 06:16 UTC
I think on the one hand, we all know it would be better to have everything perfectly planned and plotted before even typing the shebang line. On the other hand, my brain just doesn't seem to work like that. I've tried to organize everything with pseudocode, but I never get very far without actually being in the thick of the code. I'm even surprised when a moderately complicated regular expression works on the first try. This leads to code that evolves over time and includes lots of quick workarounds that I promise myself I'll fix later. Not exactly the best, most professional way to code, but it's the only one that seems to work for me. And judging by the TODO comments in things like the Quake 3 source, I'm not the only one. :)	[reply]