Dark secrets of developer motivation

Human resources has long understood that money is an inadequate motivator. We know that because workers don’t simply operate according to market conditions, always favoring more money above all else.  Instead, people are looking for something more ephemeral, which we’ll call meaning. 

Developers are also looking for meaning, the sense that their work has purpose, but they have unique ways of finding it that may not always obvious.  If you yourself are not a coder, then much of what you think about the unique nature of development work may be incomplete.

There is, for example, far more creativity involved in building software than is typically imagined.  The programmer is driven by and dependent upon this creative aspect of coding.  As Dan Moore writes in his “Letters to a new Developer” blog, “Even as a new developer, you’re constantly making small creative decisions (naming a variable, for example). This is part of what makes software development so fulfilling and fun.”  It is also the aspect most often neglected in the care and feeding of developers.

Balancing the productive and creative drives is the key to long-term developer success, and it is the aspect most often neglected in the care and feeding of developers.

The following insights into the developer mindset, the dark secrets of what truly motivates (or demotivates developers), will help IT leaders find the balance the productive and creative drives that is key to long-term developer success.

Measure the right outputs

Nobody likes to be treated like a line item on the budget.  X amount of pay for Y amount of output and if the lines cross in the wrong direction you are out.  But it’s especially dangerous to look at coders this way because the output is very hard to quantify.  If you task a developer with building a widget, the time they spend fretting about how to make it reusable can net unpredictable benefits down the road.  The sudden insight they get in the shower when thinking about how the software components fit together is quite possibly more valuable than the thing you paid them to build.

To illustrate this another way, the worst possible way to think about developers is as typists: more words equals more value.  This understanding is completely wrong.  The minimal amount of code that accomplishes the requirements is the best.  The more distilled to the essence, the better.  But even worse, this way of thinking will alienate developers by supporting policies and decision-making that is anathema to their constitution.

In his classic book Code Complete, Steve McConnell describes the WIMP (Why Isn’t Mark Programming) principle.  It refers to the phenomenon of a coding leader (an Army colonel in the book’s example) wondering why the programmers don’t appear to be working. 

Of course, the industry has matured a lot since McConnell’s book was released in 2004, and everyone pretty much understands the need for the cogitating phase of software development. Many practices in the agile programming line of thinking explicitly incorporate design and planning into the lifecycle.  Most approaches these days benefit by pushing for tighter feedback loops that integrate thinking into the process, while avoiding waterfall-style flows. 

Allow space for innovation

Running a strong process that helps your developers perform is essential.  But beyond that there is a lot of room to cultivate developer excellence.  Matt Raible, developer advocate at Okta agrees, saying  “I think passion and opportunities to learn are a big deal to developers. Having the ability and space to innovate is awesome too.”

Passion and space to innovate.  It’s a curious truth about innovation that oftentimes the breakthroughs come not from directed, goal-oriented activity but something more akin to play or free-experimentation.  In turn, that breathing room, ability to think and work towards something beyond the immediate bottom line fuels the passion.  Passion and innovation exist in a positive feedback loop, a cycle that does not turn for an external purpose, but rather for the thing itself, the building and sharing of beautiful software.

Practical, even revolutionary applications can be seen as the byproduct of that more central process.  It can be hard to perceive it from the outside, but programmers see the elegant software systems as something worthy in themselves. 

And now I will immediately restrain myself with this caveat:  All virtue is in balance.  Developers are liable to go too far in the other direction, falling for the technologist’s classic blunder—building solely for the sake of building without returning to the utility of the thing. 

But likely I don’t need to tell you that, because you are looking at the budget and your mind is alive with the life of the business.  You don’t need to be reminded of the business side if you come from that camp; you need to be reminded that the way you get delight and gratification from a healthy running business, engineers get from healthy running software.

Creativity is its own motivation

Many developers (dare I say most) are highly motivated by the creative payoff.  This is part of the reason social coding is so popular.  Coders want to share their work, their expression, with others who can see and appreciate what’s worthwhile about the code itself, not just the end product, but the internal design.  Similarly, it’s gratifying to look at what others have done and be struck by the ingenuity of another person captured in the medium of code.

This positive, motivating feeling of coding is very similar to that of music and creative writing.  In all cases there are benefits to be had, but there is also something inherently worthwhile about the thing itself and in sharing it with others.  There is an artistic side to the endeavor, you could say.  Indeed, developers are as varied a bunch as anyone else, but in general they are part artist, part engineer.

“Development is a bit of a black box for those on the outside,” says Ryan Carniato, creator of SolidJS. “It’s easy to see it as an input/output machine. And because the range of what can be taken from conceptualization to implementation, it’s easy to see it as ideas in and results out.”

“I’ve never felt a lack of respect for my own creativity, just sometimes a lack of appreciation for what goes into designing and building something—and of course the need to occasionally remind people we create software, not results, says Carniato.

Tech culture has come a long way in acknowledging developer creativity as essential.  Still, this remains the critical gap between the developers and the business.  Probably because of the programmer’s medium—it seems so very hard-science-and-math, and yet is so ephemeral—we have to continually remember the creative, human side of it.

The leader who can help channel that creative drive towards the business ends, giving the sense of working towards a worthy cause, while nurturing the sense of possibility that feeds developer’s souls—that is the leader who will reap extraordinary returns from developers.