robdickerson.net

One of the disadvantages — pretty much the disadvantage — of working in a cube farm is that you have to listen to every conversation that any one of about seven or eight people participates in during the work day. Every conversation they have, all day long, you have to listen to.

It pretty much sucks big time for programmer productivity. (Fun fact: did you know that a programmer’s job revolves around spending long stretches of time concentrating?). On the up side, though, listening to coworkers talk all the time can reveal some interesting things about the people you work with.

This morning I was enjoying my mandatory eavesdropping privileges, and caught part of a technical conversation between two of my fellow programmers. Coder A had come to Coder B to ask if there was a way to schedule a task with a certain piece of software. By cleverly analyzing vocal cues (Coder B said, “ummm…”), I was able to determine that Coder B probably did not know the answer.

In a situation like this, some people in Coder B’s position would say, “I don’t know,” and let Coder A get back to finding a solution to his problem. If you think the story ends this way, you probably haven’t spent a lot of time with programmers.

Programmers like to help people. Not for altruistic reasons, but for prove-their-intellectual-prowess reasons. If you come to a programmer for help, they won’t send you away empty-handed. They’ll help you. They’ll help the bejezus out of you. The rest of the day, you’ll be walking around in a daze because of how hard you got helped, and when you finally snap out of it, you’ll tell all your friends how wonderfully helpful Coder B is, and how smart and handsome he must be to have been so helpful, and everyone will love Coder B. At least, that’s the idea.

In practice, though, sometimes you don’t know something, and you can’t help someone who asks about the thing you don’t know. So how do you escape this situation while still maintaining the illusion that you are the most helpful (and intelligent and handsome) person in your company?

You do what Coder B did. Pick a related problem, and help solve that one. Did you pick a related problem that Coder A has already solved? No problem! Offer alternate solutions and explain the extremely subtle pros and cons of each one. Basically, if you’ve managed to talk about any technical thing for at least five minutes… mission accomplished.

In this case, Coder B said something along the lines of “well, if you wanted to schedule the task, it’d have to run standalone, so you’d have to modify the code in X way so it didn’t depend on thing Y.” Coder A flat out said, “I’ve already taken care of that,” but Coder B launched into a description of the different ways you could modify the code; how you could make it a command object which would take more code re-writing, or how you could write a macro to call it, which would be easier but would be kind of ugly, or blah blah blah.

Basically, Coder B started brainstorming for ways to solve an already-solved problem.

Programmers are good at finding alternate solutions and weighing the pros and cons of each one — it’s an essential skill for a programmer to have. But the dark side of that skill is situations like this. How many times have you heard a programmer ramble about the relative merits of different solutions, when a perfectly acceptable solution has already been chosen?

So how do you get a programmer to shut the hell up and move on? The problem is that once the brain train gets rolling, it’s not stopping until it runs out of brain, uh, coal. If you ever find yourself watching precious minutes dissolve as a programmer brainstorms extraneously at you, my advice is to just turn around and run away. The more tenacious coders will follow you, running down the hallway shouting about run time efficiency versus code complexity. To ensure your getaway succeeds, kick the programmer in the shin before you flee.