Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
Here’s an elegant restatement of the battleship gray syndrome in pen and ink, provided by It’s Just a Bunch of Stuff That Happens.
Found via ReadWriteWeb.
Here’s a cute doodle captured from the large whiteboard in the infovark burrow.
It sums up how I feel on this rainy Saturday spent working on the infovark API.
I’ve got a bad case of “code head” at the moment. We’ve been working non-stop on our prototype for the last week, and after spending all that time in deep conversation with my computer I find it hard to communicate with ordinary people.
It’s hard to describe what programming feels like to someone who’s never written code. My best analogy is that it’s like trying to give instructions to your annoying kid brother, who happens to be a bit forgetful, somewhat hard of hearing, and very lazy. A typical conversation might go something like this:
You: Hey computer, I’d like you to add something for me.
Computer: Add what? I can’t add just anything.
You: I’d like you to add a number.
Computer: What number?
You: Five.
Computer: What about five?
You: Add five to something.
Computer: What do you mean something? What kind of something?
You: Add five to another number.
Computer: Which number?
You: Any number. It doesn’t matter. I’m creating a routine.
Computer: Oh. I see. You’ll want a variable, then.
You: Yeah, a variable. So I want you to add five to this variable–
Computer: Can we give it a name? I don’t remember things very well unless they have names.
You: Oh, OK. Call it
x.Computer: Call what
x?You: Call the variable
x.Computer: What kind of variable is it?
You: It’s a number. We’re going to add five to it.
Computer: Is it a big number?
You: [confused] I don’t know… No. No, it’s a small number, OK?
Computer: Does it have decimal points in it?
You: What does it matter?
Computer: I’m curious.
You: [slowly] No, it’s a very small number without decimal points. It’s an integer, OK?
Computer: What is?
You: The variable. The variable is an integer.
Computer: Which variable?
You: The one we were talking about before:
x.Computer: What about
x?You: [frustrated] Look, the variable called
xis an integer, OK?Computer: Oh, right. Gotcha.
You: OK, now I want you to add five to it.
Computer: Add five to what?
You: Add five to
x.Computer: You didn’t say, “Please.”
You: [angry] What? Why you little…
Computer: And I’m doing this in my own language, so you have to use “semicolon” for “please”.
You: [resigned] All right. Fine. Have it your way. Here you go:
5 + x;Computer: OK.
You: Now if
xis20, what’s the answer?Computer: What answer?
You: The answer to the question I asked!
Computer: Oh, you’ll want another variable for that.
You: Huh? Oh, fine… call the answer
y. And before you ask, the variableyis an integer, too.Computer: OK.
You: So, I’ve got an integer called
x, which in this case happens to be20.Computer: OK.
You: Now add five to
x.Computer: OK.
You: Now what’s the value of
y?Computer: Zero.
You: [incredulous] What?
Computer: You didn’t assign a value to it.
You: I want
yto be the answer!Computer: The answer to what?
You: [exasperated] Look,
y = 5 + x;OK? Have you got that?Computer: Yes.
You: And in this case
xis 20, which makesy…Computer:
25.
This is the sort of dialog that occurs between the computer and the programmer all the time. Getting into the appropriate mindset to deal with a computer requires a lot of concentration. Programmers call this a state of flow, or being in the zone, where the programmer is able to think like a computer does, so that the conversation above never happens and instead the programmer just types the lines:
AddSomething()
{
int x, y;
x = 20;
y = 5 + x;
return y;
}
Sometimes it’s just as hard to get your mind out of a state of flow as well. That’s part of what makes working at a small software startup like infovark challenging. We have to toggle between pedantic, logical computer mode and natural, relativistic human mode. In one minute we can be thinking about strategic marketing campaigns and the next about how to explain to our idiot kid brother exactly how to do the next step in the task without him messing it up again.
In a way, it’s this frustration that drove Gordon and I to start infovark. We’ve seen far too much software that passes the frustration of being a programmer on to the end user, forcing non-programmers to go through painful, time-wasting conversations like the one above. Right now, we’re going through the tedious process of telling the computer exactly what should be done when so that our customers can get on with the important things in life.
Hi. I’m Dean, and I was a maintenance programmer.
I’ve just spent the last two days refactoring the infovark storage and retrieval API. It wasn’t that anything was broken, exactly, it was just that it was… messy. There are a lot of things I should have been working on instead, but I couldn’t resist tidying up the object model a bit. It’s a weakness of mine.
You see, “maintenance programmer” is generally considered a pejorative label in the software development industry. Programmers that do maintenance — minor bug fixes, performance improvements, functionality tweaks — are generally on the lowest rung of the development team.
That’s how I got my start in software. My first coding jobs were technical support and troubleshooting gigs. You can ask anyone who’s worked with me on a development project, and they’ll tell you I’m fastidious — some might say fussy — about the structure of my code. And, truth be told, I’m picky about everyone else’s code as well. Since my first experiences with programming were maintaining large codebases written by other people, with no specifications or even a user manual to go by, I’ve developed certain habits of mind.
If great hackers are the poets of the software world, then maintenance programmers are the copyeditors. Great hackers produce elegant code. Their deeds are legend in the computer science community, and some have passed into history. Some are so good they’ve been celebrated in free verse. Their code soars in cathedrals of light, pure in its mathematical beauty.
By contrast, the code churned out by the maintenance programmer is solid, workmanlike, and perhaps unimaginative. But it works and will continue to work. There won’t be any odes sung to the maintenance programmer, but at least a few respected developers out there, like Eric Sink and Jeff Atwood, have spoken up for us. There’s even How to Write Unmaintainable Code, a humorous treatise on the many ways to drive a maintenance programmer crazy — and a tribute to all of us that have suffered at the hands of sloppy development techniques.
So we’re beginning to get some respect. And I’m proud of the work I do. I realize that being a stickler about naming variables properly or commenting logical branches only slows down development. But I take comfort in knowing that my code will stand up to some abuse out there in the real world.
Do you think you might be a maintenance programmer, too? Here are the seven warning signs:
Sound familiar? If you get the same feeling of delight at sorting out spaghetti code as you did reading Eats, Shoots, and Leaves, you might be a Maintenance Programmer. There’s good news for you, however: You’ll always have a job to do. Because no matter what happens in the computing world, there will always be code in need of a rewrite.
If you’re following the world of Enterprise 2.0 closely, you might want to take a close look at the results of this new study on office productivity
“According to a groundbreaking new study by the Department of Labor, working—the physical act of engaging in a productive job-related activity—may greatly increase the amount of work accomplished during the workday, especially when compared with the more common practices of wasting time and not working.”
I think there’s something in that for all of us…