inky has a blog inky writes about stuff

December 20, 2009

Do or do not

Filed under: Uncategorized — Tags: , — inky @ 11:15 pm

We hired a new junior dev at work recently, which got me thinking about what pearls of wisdom* I have to impart to new programmers (not that anyone is asking, but maybe I can slip them into fortune cookies or something).

Some things to know as a programmer are general tips, like “if you don’t know what to do with a problem, throw a hash table at it”. Some are things about human fallibility, like “if you find you wrote a bug somewhere, look for where else you might have made the same mistake” and “if you make a change and then the system mysteriously stops working, it’s your fault, even if you don’t think there is any possible way your change could have broken things”. That kind of stuff will get you up to being a pretty decent midlevel programmer.

But when you master the basics and start getting into architecture work, I think the most important skill to learn is when not to do stuff.

If you’re not a programmer you probably don’t think this is that hard, but the thing is that programmers like to write code, which is why they’re programmers. Code is very cheap to produce, so there’s a constant temptation to write down whatever thing you think of. There’s also the Ozymandias thing — if you can write down anything you can think of it’s tempting to create something big and flashy (whether because you want to create a monument to your own awesomeness (a good sign of this is you name all the functions in the project after yourself) or because you genuinely want to help people by solving a big problem which includes the thing you were tasked to solve as a particular case).

Most of the failed (or, let’s say, partially successful) projects I’ve seen or been involved in over the years have suffered not due to lack of coding ability on the part of the people involved but due to excessive breadth of vision. The result is inevitably something that’s so heavy-weight none of the users of the system want to learn it, and also too heavy to change to fit their needs when it turns out they aren’t exactly as originally thought (or when their needs change over time). The best hope for survival with a project like this is to carve off a chunk into a standalone library that does a few things well, and just never touch it again and hope it never breaks, and do all the modifications with wrappers around the outside.

Of course, the flip side of all this is, sometimes it’s less work to do some work. Like, there’s this interview question which I’ve heard about but never actually seen, where the interviewer says “ok, draw me a house,” and if you draw a house you get a lecture about not asking for requirements before starting to build. The thing about this is, if you were going to build a real house, you’d be making some drawings and models of houses to show the person. Why? Because conversation is all well and good, but if you want to decide if a house is going to suit you, you want a house to look at. Furthermore, drawing houses (unlike building them) is extremely cheap — if they look at your house and say “that house sucks, my football team won’t have anyplace to sleep, let alone practice” you can redraw a new house that fits those requirements in about as much time as it took them to express them.

The importance of this depends on what kind of programming you do, of course, but in my line of work (Web-based business-driven stuff), maintainability and change are so important, and the cost of deploying new features is so small, that the goal is really to do as little work as possible. And sitting in meetings hashing out requirements is work, and, worse yet, it’s work that is likely to be wasted since as soon as the customer sees the actual product they will see all the reasons why their original ideas were dumb and wrong.

(N.B.: Hardly any of these gripes apply to my current project at work.)

This is probably one of those things that seems trivial when labelled, but it’s interesting to me because, despite knowing that it’s an issue, I keep doing it — I’ll see something that needs to be fixed and start fixing it and before I know it I have a massively overgeneralized solution that touches a dozen files. Then I notice and delete it all and make the dumb three-line fix instead.

It’s also interesting to me in that it seems to drift into other fields as well. Like, there’s that famous quote by the Little Prince guy about perfection (in writing, I assume) being about taking away, not adding. Or the many-variants joke about the sculptor who says he works by taking the stone and cutting away everything that doesn’t look like a horse. That said, the sculpture one is obviously a joke — I do wonder how much of an issue this is for fields that do have a material cost, since that provides a natural counterbalance to the tendency towards overenthusiasm. I think a lot of the deal here is that code is free to write (except your time), and prose/poetry writing is much the same way — if authors had to pay by the word, I imagine there’d be fewer unnecessary adjectives.

Thinking it over, I don’t know what I’d actually distill out of all this to tell somebody if they asked for advice. I guess I’ll just slack off as much as possible and hope they get the idea.

*It didn’t occur to me until recently how apt this metaphor is. They’re formed over the life of somebody by slow accumulation, usually in response to an irritatant, and are totally useless to the one who creates them since they have plenty more of it where that came from.

I tried to look up the etymology of the phrase to see how intentional this was but didn’t have any luck — just some people claiming it was based off “casting pearls before swine” which seems a little unlikely to me.

1 Comment

  1. if authors had to pay by the word

    Comment by Adam Cadre — December 21, 2009 @ 12:14 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress