Previously I talked about the concept of flow.
In this post I'll talk about why, specifically for software developers, flow conditions remain painfully absent from today's working environments. (1)
Like so many things it all comes down to perception. That's where we'll start.
Developers are sexy (it's just hard to tell sometimes)
Let's face it - from the observer's point of view, developers sit at a keyboard and type.
Observers can watch painters paint. Observers can watch architects draw and chefs slice and dice. But they only can watch developers... type. Typing is just not that sexy - or revealing. But ostensibly that's what developers do.
"But what about authors (novelists)? They're also ostensibly 'typing' - but they're sexy!" Authors are 'sexier' than developers because the finished product still resembles the "source code" - the thoughts from which it came - and it's in a shared language, about familiar topics, and still enjoyable atop its abstractions. The readers get a window to the author's soul, and a human connection is formed as the reader climbs through it. (2)
Using a developer's software isn't equivalent to reading a writer's thoughts - the human connection is far less apparent. Readers can imagine and romanticize about an author's creative process in a way that software users largely cannot. Software requires a far greater abstraction to create desirable and usable things.
Managers and users
The creative process behind software development can be as opaque to managers as it is to users. A big reason we don't see a lot of flow in the workplace is because it takes management support to bring about change - and managers don't fully understand the creative challenges developers face and why our work requires so much imagination.
This isn't to blame managers - the developer's process, as I mention, is largely mysterious to the observer. It's not hard to understand why coding doesn't look or seem all that glorious in the way art, design or physical science does. But it is :) The responsibility lies with the developer to communicate that - he or she needs to open the dialogue.
Yet I worry that developers are still commonly seen as builders - not creators. And it's hard to make a case for creative-level support if you're seen as just a builder.
The (dreaded) annual review
Developers are notoriously hard to review and compensate accurately per their skill level. This is also because observation is hard. And the ensuing confusion and tension is another reason why flow-like workplaces seldom materialize for developers.
Here's an example: Our example developer comes in late, is moody and highly opinionated, and has headphones on nearly 100% of the day, talking to no one. (3) Notwithstanding, the other developers still come to him or her with questions, and he or she personally tackles the heavy architectural challenges that come up.
How does this developer's review go? In progressive tech companies it might go well. Maybe peers will have a say like in Google's process. But in other environments it might end poorly. The reviewer might not be aware of the engineer's less visible, yet highly valuable, technical contributions. Another developer on the team might be sleeping under their desk every night, right after they break the build. A big raise for their 'loyalty' may be granted, but often to the chagrin of the rest of the team.
It's a hard problem. How can a manager who doesn't write code gauge who's really doing what? Classics have been written about this. Menacingly, traditional measures like punctuality and attitude don't correlate well with contribution or intelligence, nor do programming 'metrics' like lines of code, # of commits, etc.
But... what about mind reading?
If only the manager had a dream-exploring machine - like the one Leo uses in Inception to interview Ellen Page. During the interview she architects dream mazes Leo can see and participate in. Consequently, he can evaluate her ability first-hand. Sadly, this machine's not invented. Yet.
Until it is, (4) my advice to developers is to work hard at explaining what you do, and allow your managers and colleagues insight into your thought process. And if you're a developer who really needs flow time to get the most from that process, ask for it.
My advice to managers is to observe developers in their natural habitat - sharing GIFs in chat rooms - without being intrusive. Find and reward and find the leaders. Look out for developers that are talented but not hitting their potential. Give them creative work, space to do it in, and then see what happens.
The difficulty of accurately observing the development process makes another very critical, very personal process - assessment and compensation - that much harder.
Together these challenges, along with baggage built up from years of tension and misunderstanding around them, help illustrate why managers and developers have yet to come together and change the workplace into something more amenable to the developer's process. The way forward requires developers to speak up and explain their process. It requires managers to listen and respond - and to take on the creative task themselves of restructuring work to maximize output from developers working in peak conditions.
- If you've only worked at startups or in Silicon Valley you might think that developers are highly respected creators the world over, endlessly pampered with free food, high salaries, lavish environments, open-ended time et. al. But, um, most developers still get treated like a commodity at small and large companies. And it's for those companies I call attention to this matter.
- This isn't a perfect analogy. A writer's finished book is still different than the 'source code' - it's often been edited in some way, compiled from notes, outlines, experiences, etc.
- e.g. me. jk. ok sometimes.
- ...and putting all the other wildly creepy implications aside...