» Curmudgeon Coding >> The Retrospector

Curmudgeon Coding

Posted June 30th, 2006
Categories: Technical, Programming

I recently read an article by The Curmudgeon Coder that kinda hit home for me in some respects. I can’t agree with everything said in the article, but the 5 reasons stated on why he’s a “Curmudgeon Coder” sort of made me laugh, so I suppose I can at least relate to a lot of what he said regardless of whether I agree entirely or not.

Here’s the 5 reasons he’s a curmudgeon coder:

Unnecessary meetings, i.e. SinkHoles of Evil
Coding is becoming simpler
XML
The coders aren’t in charge anymore
Fixing the affect of the defect, not the cause of the defect

The list itself isn’t very explanatory. The comments made to describe each one is where the meat of the article is. I thought I’d go ahead and share my thoughts on each topic anyway.

Meetings

I can relate to being forced to sit in unnecessary meetings quite well. I’ve been exposed to very large corporate environments where I simply couldn’t get around at least 1-2 meetings a day with people I hardly interacted with at all. The key is to only make time for the meetings where it really matters that you have something to add or gain from. If you’re not getting anything out of it, and you’re not really adding any value…don’t go. Easier said than done for some, but I’ve found my days far more productive when I simply stopped going to meetings that didn’t seem to add value to my workload or deadlines in any way.

Coding is becoming simpler

He’s referring to the fact that coding has left the arena of bit-shifting and pointer & memory management being part of programming and is moving more toward a framework-based and more automated environment where more and more people are able to make things work with less effort and training. I’ll certainly agree with this point almost entirely. I think it’s very easy for those that think they’ve got a handle on things to fall apart and make big mistakes if they don’t have the fundamentals down though. There’s something to say for the people that not only understand how to use the frameworks, but also know how the framework works under the covers in case something doesn’t go perfectly right the first time around.

XML

I’m not really turned off by XML as much as he is, but I can certainly agree that it’s limitations can be frustrating at times. Some people I know are just so put out by having to learn what a few XML files do when after just taking a couple hours to really learn how to use them and what data goes where, things aren’t so bad. I think XML is too easily applied to things where it doesn’t really belong though, to give the author credit. I really like what Ant can do, but I almost wish it wasn’t XML instead of just some other syntax like he says. Nevertheless, I’ve never really had any bad experiences with it.

The coders aren’t in charge any more

Some of the comments on this article’s page hit this point some. More specifically, the author talks about the good ol’ days of when other business units come to IT for possible solutions to a problem instead of integrating themselves into power-positions within IT and dictating how things are done without understanding much beyond management.

I must admit, finding people in management that truly understand how IT works is rare…but there are some out there. Having someone in management that can understand and relate to what you’re going through is one of the best things besides having them roll their sleeves up and diving in to help out where possible and actually get something beneficial out of it.

I think the argument that coders aren’t in charge anymore isn’t the issue, it’s more than management needs to become more familiar and allow the technical people to participate in the process that drives the IT side of the house for goals, timelines, and direction as well as the implementation details. The IT people aren’t just gumball machines where you can insert coins once in awhile for a flavor of the month. Let them be involved in deciding what flavors to put in there, how many gumballs the machine can hold, and how many you should put in there. See my article about How to Motivate Geeks, and apply what makes sense for you to keep them excited and involved.

Fixing the affect of the defect, and not the cause of the defect

This is truly the root of many evils in my experience. Patching up a bad job just sucks after a good half dozen patches or so. The second point really lines up with this one pretty well. I think Martin Fowler’s articles about continuous integration really helps with some of the preventative things you can do to make sure major issues don’t go unsolved for a long time so you’re not tempted to make big mistakes. I think that good programming practices and the ability to refactor occasionally can help prevent too much patchwork from taking over the design of a project before it’s too late.

So there’s what I have to say on the matter anyhow. I don’t really think I’m much of a Curmudgeon Coder as I might have been a couple years ago in a different environment and a much lesser understanding of a few frameworks and environments, but I can certainly relate enough to this poster’s thoughts enough to write about it here.

So what type of things in your environment make you a Curmudgeon Coder? Anything really push your buttons and make you feel like you’ve just been around the block a few too many times?

Tags: programming, coding, software+development