Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

mothra (1667)

mothra
  (email not shown publicly)

Journal of mothra (1667)

Saturday June 08, 2002
01:47 PM

Too old to code?

[ #5510 ]
Hmmm...I find Moshe Bar's comments a little odd, a little awkward.

Back when I was in my early twenties nobody could beat me at programming.

Excuse me? What the hell does that mean? What constitutes "beating someone" at programming? What language must we be coding in for you to "play against us"? What must the task be so that you're familiar enough with it not to need 2 years of research time to catch up to knowledge we already have? (I'm not necessarily in the group referred to by "we" or "us"...just raising the questions to make a point).

A glimpse of how Mr. Bar might answer that is seen in a later quote:

Nowadays, when I sit next to people like Andrea Arcangeli, I realize that programming, too, (even considering the advantage of experience) is for the young. Perhapes extreme programming, ie good quality, high speed programming, should be considered a sport and not an art or science or a skill.

Ok...so it's all about how fast you can churn out code? Well...I certainly agree that timeliness is important. For example, what good would it be if all the XML::* branch didn't come out until 20 years from now? Clearly, accomplishing tasks in a reasonable timeframe (where "reasonable" can have a pretty open definition depending on who's the judge of "reasonable") could be the difference between getting your paycheque, or getting fired (if "context" means "job", for example).

But...have said that, is that the only measure? Hardly.

What if:

  • you churned out 500 lines of code in 5 hours, but any programmer who had half a clue could have done the same thing in 30 lines of code? Would that still mean you're "good"? Is that a good kind of "fast"?
  • you wrote 500 lines of code in 5 hours, before you checked CPAN and found that someone had already done it?
  • you wrote 500 lines of code in 5 hours, before probing the users enough to ensure that this feature even makes sense to add to the program, or if perhaps the issue could be solved without having to add another line of code at all?
  • you wrote 1000 lines of code in 5 hours, but it could have been done in 250, and didn't even solve the problem for which you wrote the code in the first place?
  • you wrote 1000 lines of code in 4 hours, it solved the problem...for the first 3 weeks, and then the user entered a letter in a numeric field, causing the program to crash, and the user to lose half a days work?
  • you wrote 1000 lines of, say, XML in 5 hours without actually knowing that Emacs (your editor of choice, for argument's sake) can know about DTD's and automatically insert elements for you? Is doing tons of manual work that can easily be automated still a sign that you're "good"?
  • What if you ripped off 200 lines in 20 minutes, but not even The Damian would dare think of trying to actually maintain such disgusting crud?

One might say "well, I think he meant you churn it out fast, and don't make any of the mistakes suggesting in the above list", but how easy is it to measure that? If you ask me, what consitutes "skill" in programming is a grey art at the best of times.

Point being, Mr. Bar has a point that how fast you can churn out code can matter in context, and might adjust how you write it.

But programming has many traits analagous to, say, being an author of a novel. There's so many more factors involving in judging what makes you "good" than speed. Sadly, these all become skewed when you're paid to do the work, and have to meet deadlines imposed by people who have zero idea of what's actually involved in accomplishing the objectives.

Also, his belief that being a programmer doesn't "age well" is a bit silly too. I think few people's intellect gets sharper and sharper as they ascend their 50's and 60's...but who cares? That's nature at work, and it affects your performance in any profession. Just because it's not as noticeable when your job is a bullshit arti^W^W lawyer, doesn't put that profession on some higher plane than "merely" being a programmer.

His comments seem amazingly shortsighted.

Thoughts?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.