When to Forget

It is well-known that we programmers fill our brains with a lot of complex details while we're working on a problem in code. Some time later, due to our sadly finite brains, we go through the process of forgetting most of these details. Paul Graham, in his essay "Holding a Program in One's Head" summarizes this process nicely: "You can start to treat parts as black boxes once you feel confident you've fully explored them."

This forgetting is important! Software is complicated, and trying to hold all of the details of even a modest body of code will easily outstrip any programmer's mental capacity. We must forget things! But when? When is it safe to forget the details? When is it reasonable to feel confident you've fully explored them?

The No-Cry Software Development Methodology

The programming section at the bookstore is jammed with prescriptive "methodology" books like these:

• "Continuous Integration: Improving Software Quality and Reducing Risk"
• "Rapid Development: Taming Wild Software Schedules"
• "Implementing Lean Software Development: From Concept to Cash"

Likewise the parenting section:

• "The No-Cry Potty Training Solution"
• "The Attachment Connection: Parenting a Secure & Confident Child Using the Science of Attachment Theory"
• "The Successful Child: What Parents Can Do to Help Kids Turn Out Well"

I want to talk about two such books that I didn't write:

Debugging and Science

I just finished reading Richard Feynman's collection of autobiographical sketches, "Surely You're Joking, Mr. Feynman" which is a lot of fun. He was a first-class kookball.

At one point Feynman talks about the moment when he figures something out: a new theory or insight or solution that neatly explains some previously mysterious behavior. And I recognized some of the feeling he was talking about, surprisingly enough, from the feeling of recently rooting out the causes of a years-old mandelbug at work.

This got me thinking about debugging, and programming, and complexity, and finally about mysteries...

Vendetta

Yesterday, my boss noticed that I have already (6 months into the job) accumulated at least a years' worth of future work in trac tickets under my name. And he helpfully suggested maybe we could reassign a few to someone else. So I helped with the triage, right up until we got to #178. He suggested we give it to Mr. Black, and at that moment my head started spinning around, green foam spraying out of my nose and mouth (this was over IM; I used the old-fashioned emoticon *@#$*$@#*%! to convey my feelings).

"THAT ONE'S MINE!" was the best I could do to justify my response.

When perl is too fast

The idea for this post has been brewing for a few months, but I was inspired by this post from David MacIver to get on it.

I like Perl. From a trendiness standpoint this falls somewhere between admitting that I like peanut-butter-and-pickle sandwiches and admitting that I like clubbing baby seals. I understand and can appreciate the common complaints: the language is too big, its syntax is baroque, it is write-only, TMTOWTDI is a bug rather than a feature. But I want to talk about something else that has been irking me.

Code Review: MySQLDAO.java

(DRY, bottom-up programming)

The Code

Today's review is of a Java class called MySQLDAO.java:

Code Review: Constants.pm

(cohesion, scope, laziness)

The Code

Today I took home a chunk of code to review. It's a chunk of code which I've run across, in one form or another, for 10 years now, and it drives me around the bend. In Perl: Constants.pm. In Java: Constants.java. In C/C++: constants.h.

Let's have a look at the perl module KitchenSink/Constants.pm:

tactics, tactics, tactics

One of the challenges for professional programmers trying to advance professionally is simply deciding what to study. We each have a limited amount of time to invest in improving our skills. Should we spend those hours reading about architecture? Computing theory? Lambda calculus? Discrete mathematics? Complexity theory? Compilers? Should we get involved in local user groups, or toy around with new programming languages? Join the IEEE Computer Society? It's easy to find folks who will advocate any of those, and they're probably all correct, in the sense that any of those things help. But we can't study everything, so what is the best place to focus our limited time?

Well, I think I have an answer. But first, a detour into chess.