Confessions of a Dumb Programmer

I’m a dumb programmer. I’m not even vaguely detail-oriented. I’ve been forced to rely on all sorts of crutches to prop up my weak mind. Things like:

  • good design
  • comments
  • automation
  • unit testing
  • refactoring
  • source control
  • well-named modules, files, classes, functions, variables, etc
  • pair programming

If I were smarter, I would consider modern software engineering “a bunch of useless hooey”.

Advertisements

1 Response to “Confessions of a Dumb Programmer”


  1. 1 Jonathan Gilbert March 27, 2007 at 11:30 am

    Different people mean different things when they say “Software Engineering”, but I’d just like to state my strong opinion that the use of gray matter and tools does not constitute software engineering.

    * good design

    ..should be obvious (but isn’t, in my experience). At least for me, designing things well is mostly a matter of common sense. Does that make me an engineer?

    * comments

    ..are a necessity even when you’re the only person on a project. One also needs to know when not to add comments, of course — there is an ideal level of commenting, and if it is exceeded, readability goes back down. Again, all that’s needed is a brain capable of looking forward and saying, “If I hadn’t written this, would I understand it? Will I understand it a year from now when I have only half as many active brain cells?” Perhaps this is a form of engineering, but I’m not convinced.

    * automation & unit testing

    This depends on how far you take it. Certainly, if you start following prescribed formulas for doing it, you are committing the crime of software engineering. You will probably also end up with subpar tests. The best tests come from a) identifying boundary cases with your brain, and b) collecting actual problems that occur in the Real World and specifically testing that they do not recur.

    * refactoring
    * pair programming

    Okay, I’ll give you these. Anything beyond renaming of symbols and factoring code into new methods is verging into the territory of patterns and rules, and that most definitely is software engineering.

    It’s also hard to argue that pair programming isn’t part of software engineering. Where I work, we do not use pair programming, but I find I can get a similar effect by allowing changes I make to build up for a few days and then going through the compiled differences from the base copy I started with. I frequently spot small errors and correct them before actually checking in the code. Heck, sometimes I even spot big structural errors. I think this works because the original patterns and assumptions in my brain at the time I wrote the code have had a chance to be displaced by other thoughts, so I’m looking at the changes with fresh eyes. Does self-review count as software engineering?

    * source control

    ..is just a tool. This is like calling a person who can make effective use of a tool shed a mechanical engineer.

    * well-named modules, files, classes, functions, variables, etc

    This goes in with “good design” and is mostly a matter of using the brain for a bit before one starts typing. đŸ™‚


Comments are currently closed.




%d bloggers like this: