Are you there to ship, or write code?

Amro Mousa tweeted about a great post by Joel Spolsky about Duct Tape Programmers. Also known as hackers, rockstars, and problem-solvers duct tape programmers are the ones that just get it done. The line that resonated the most with me is the following quote from Jamie Zawinski:

But that’s not the point—you’re not here to write code; you’re here to ship products.

Unfortunately, I don’t think this is always true. In many organizations, especially the larger, more layered organization, the responsibilities of developing the software and shipping it are held by two different stake holders. The job is to write code, nothing more, nothing less. This can be the most infuriating and frustrating environment for a duct tape programmer. The metrics are all wrong. Number of test-cases, tickets closed, features on the box, length of scrums, etc, don’t matter if nobody is using the product. Thankfully, if you think your responsibility is really to make things that get used, there are some early signs that a position might or might not be a fit:

Things that should make you worry:

• Being asked for a BrainBench certification
• A 30-minute interview of nothing but syntax questions
• Lots of questions about keywords
• Greater emphasis on process than the problem
• Constant quizzing on the technology mentioned in your resume

Things that should make you feel good:

• The interviewer describes the problem and how they’ve solve some of it
• You describe some of the problems you’ve faced and how you’ve solved them
• You and the interviewer start brainstorming how you’d start solving the rest of the problem
• You and the interviewer realize that you’re both way over time and are missing something important

The first set of questions determine how well or quickly the candidate can produce code, but there’s nothing in there that explores whether any of that code ever did anything useful. The product is the vehicle, the code is the driver. The second set is for the duct tape programmer. The code might not have been the most idiomatic or the best covered, but this person has written code to solve the problem in the past and is already thinking about how solve the next ones. In this case, the code is the vehicle that’s driven by the product. Using these these lists as guidelines can help you find the right fit and place where you can be the most productive, while avoiding misery and a padded cell. Is there anything missing from the lists?