Does your process involve invention? If so, please describe the three most recent things you have invented and why it was necessary to invent something new.

That’s it. As an interviewer, you can ask this question of a candidate. As a candidate, you can ask this question of the team you are considering joining.

The results are really easy to interpret. Does your team invent new things in the course of its work? If so, what are you to make of a candidate who doesn’t invent new things and believes that software should be built by integrating tried and true existing components? Such a candidate is not wrong, but are they a good fit?

Even if you invent and the candidate invents, discussing their inventions drives directly to the core of what kind of developer they are. Are their inventions part of the core value proposition of the software they develop? Are their inventions focused on developer productivity but invisible to users and stakeholders? Do they prefer novelty to reliability?

Likewise as a candidate, what are you to make of a team that invents when they could integrate? Do you want to be the newest member of “The Knights Who Say NIH?” Do you want to wrestle with somebody’s home-brewed framework that implements an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp?

Software Development is a tremendously large subject. No one question, not even this one, is going to get to the heart of everything you need to know about a person or team’s character. But deep at the heart of what we do is the difficult question of when and why one creates something new instead of using what already exists.

types of brains

Some teams go out of their way to avoid invention. If faced with a requirement that seems to demand nerd sniping, they will renegotiate the requirements, educating stakeholders on the non-trivial risks that wait for the project like icebergs awaited the Titanic.

Other teams embrace invention for competitive advantage. They will use an existing plug-in or gem for user authentication, which they consider a solved problem, but will happily create their own code—and possibly open sourcing it as a gem or other package—for something central to the value proposition of the application they are developing.

Likewise, some developers strongly prefer the conservative approach, avoiding invention. Such developers are not laggards, we are not talking of COBOL programmers. Instead, we are speaking of developers who have discovered that tremendous value can be created by managing development successfully, and especially by avoiding catastrophes. Such developers are often motivated by results: They like to deliver working software, and see invention as a fickle mistress that can delay and derail delivery far more often than she assists it.

Others are eager to find a place to create value though differentiation. Such developers have realized that if you never invent, your code cannot be better than anybody else’s. This might be fine for some internal HR workflow management application, but when building anything that is part of their employer’s core value proposition, you cannot add great, disruptive value without being prepared to take the road less traveled somewhere in the code base.

I will not suggest that one or the other approach is the best way forward. I think that for each person, there is a natural affinity to invention or a natural dislike of the risks and time sinks involved. Some people feel deeply rewarded giving birth to something new after a long, arduous period of research, trial and error. These developers can often be insanely smart.

Other developers feel deeply rewarded when they can travel in a direct line from conception to execution to delivery, with as little uncertainty along the way as possible. These “results-oriented” developers want to get things done.

In theory, we all want to work with people who are smart and get things done. But in practice, what we want are people who are smart in a way that complements our own approach to solving problems and who get things done in a way that helps us rather than hinders our own efforts.

what to do now

Despite my admiration for both types of developer and both types of team, I am keenly aware that culture clashes can and will cause stress and unhappiness on any project, which is why I value this question so highly.

Even if you aren’t looking for a new place to ply your trade, I suggest that if you haven’t thought about your personal bias with respect to invention before, you take some time to work out how you really feel about inventing new things. It’s important to come to grips with your true feelings, not what you think other people want to hear or what would get upvotes on Hacker News.

Likewise, if you aren’t interviewing candidates it’s still important to truly understand your team’s dynamic so you can understand how you fit. if your team has a bias toward invention while you are conservative, that doesn’t mean you should quit, but perhaps you should think of yourself as the team’s conscience and look for ways to steer it away from invention for the sake of invention and towards invention for the sake of competitive advantage.

This question has no right answer. But it may suggest the right way forward for you.

(discuss)

p.s. The chapter of Programming Perl regarding software libraries starts out with a discussion of Laziness, Impatience, and Hubris, but more importantly, it also explicitly mentions the ideas of False Laziness, False Impatience, and False Hubris, which each in turn lead software developers [into] making poor choices as to whether they should build a new software library, reuse an existing library, or just get on with their damn job, and write something easy... But this essay gets right to the same core here. How is it that we do our jobs as software developers? What is the right way to approach a particular problem? These are hard questions to answer in abstract, but thinking about the nature of invention is a pretty good proxy.—Ted "knowtheory" Han

p.p.s. Fascinating: The C2I2 Hypothesis