DR Griffin|PostsAbout

Cracking the developer code: Flow

I’ve been thinking a lot lately about what motivates software developers. If you believe that Developers are the new Kingmakers, then this is an important subject!

It's certainly true that developers can be opinionated, but I’m not sure I agree with statements like the following;

“[a developer] typically just wants to use the best tool for the job”1.

Throughout my career I’ve seen it over and over that developers want to reinvent the wheel instead of talking to another team, or using a pre-existing solution. Sometimes it seems like the primary goal of developers is to find excuses to write a lot of code. There are so many examples of developers picking things that let them muck around with code, instead of making the best choice for the business.

Code, rather than results has this mythical status in the industry. Candidates for highly-paid developer jobs, like the one I used to hold, are tested on their coding ability first, and other skills second. These skills, like communication, and listening are often derisively referred to as soft skills. I've seen interview debriefs where interviewers act like being able to code trumps all other skills. The reality is that those "soft" skills are the most important skills, and they only get more important as you progress in your career. The technical leaders that I admire the most, like James Hamilton, or Heidi Howard are great communicators above all. Those are the people who change industries, and upend the status quo.

So why is it code and coding that holds this mythical status? Why are all the hopeful university and bootcamp graduates studying Cracking the Coding Interview in the hopes of landing a six-figure salary at a tech company?

Two things finally made it click for me. Firstly, I listened to a podcast about achieving flow state, and how it applies to climbing. Secondly, I finally watched the 1995 cult-classic Hackers. In that movie, the main character Dade is basically addicted to his computer. He stays up all night, much to his mother’s distress.

In positive psychology, a flow state, also known colloquially as being in the zone, is the mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by the complete absorption in what one does, and a resulting transformation in one's sense of time. (Wikipedia)

Hacking movie collage A selection of scenes involving coding, or 'hacking', from War Games, Hackers, The Matrix , Swordfish , The Girl With The Dragon Tattoo, and Halt and Catch Fire.

People like me love to deride ‘hacking’ scenes in hollywood movies as being unrealistic. But after watching Hackers I realised... I have behaved like Dade, many times; and not just recently during this pandemic.

Me playing my GameBoy That's me engrossed in a GameBoy sometime in the 90s.

When I think about it, that search for flow has had a huge impact on my life and career. It was while I had some spare time2 as a ski-bum that I did Zed Shaw's Learn Python the Hard Way. That, along with my Electrical Engineering degree is what lead me down the path towards Amazon, and Seattle. You could argue that I spent two (Australian) summers as a ski-bum, and learned a new programming language in search of that flow state. Some other examples of things I've done over the years perhaps in search of flow are sailing, hiking, climbing, and weightlifting. In that context, those hollywood scenes of caffeinated hackers staying up all night don't seem so far off the mark.

This got me thinking about a stereotypical software developer, what were they like as a child? Did they love LEGO? Did they play computer games? Did they read lots of books? Are they into comic books? Did they excel at math? The list goes on.

My first lego set? How many engineers began their journey with a set of LEGO?

It turns out that the people who defined and researched flow, like Mihaly Csikszentmihályi, and Jeanne Nakamura outlined some specific conditions that need to be met to achieve the flow state, again from Wikipedia:

  1. One must be involved in an activity with a clear set of goals and progress. This adds direction and structure to the task.

  2. The task at hand must have clear and immediate feedback. This helps the person negotiate any changing demands and allows them to adjust their performance to maintain the flow state.

  3. One must have a good balance between the perceived challenges of the task at hand and their own perceived skills. One must have confidence in one's ability to complete the task at hand.

These principles have been used pretty heavily by games, and the techniques of game designers are now common in everyday life, sometimes with questionable outcomes. But bringing it back to developers, many things you can see in the software industry look like attempts to find flow.

Firstly, a clear set of goals and progress? Hello tasks. From Agile, to Scrum, to Kanban, most software development methodologies are built around the task. Tasks are created precisely to set goals and measure progress.

Secondly, feedback. One of the key things that attracted me to software, over the other branches of electrical engineering was the immediate, almost addictive feedback loops you can get while coding.

And thirdly, endless ink has been spilled over the years about aligning challenges with skills. Every discussion you’ve ever seen about organizational structure has some element of trying to align the challenges of the organization with the skills of it's people. All the work I've done around mentoring and growth, from when I was a 14 year old Patrol Leader in Scouts, to Amazon, was about finding the right level of challenge for people.

Maybe they weren't crazy after all

So now when I think back to my first job, the way I ended up owning a bespoke "distributed lock service" built on top of NFS3 makes much more sense to me. It makes sense why my predecessor chose to build this instead of using some simpler, or off-the-shelf solution. When Csikszentmihályi describes flow state as the “optimal experience”, he's giving us a clue. People probably aren’t optimizing for making money, or increased feature velocity, or more reliable software, or better customer experiences, and your employees are especially not optimizing for shareholder value. People are optimizing for their own happiness, which often involves finding ways to reach a flow state. Of course, often we pop out of that state to align our work with the customer, with making money, or other external factors. Just like whales, we must come up for air. But people certainly enjoy it more when they get to spend as much time as possible approaching flow.

Hopefully by now you’re convinced that the flow state, or optimal experience is a real thing, and that many developers are searching for this state through coding. Being in a state of flow has the potential to make people both happier, and more productive. If you’re an employer, it can be a win-win.

But I'm not (currently) an employer. Although I am building some things aimed at developers.

Can we design for flow?

I think the answer is yes. A slightly bolder claim would be that developers only truly love products that help them reach a state of flow.

There are two extremes from which developers will critizise most products. Some lucky products manage to get both criticisms at the same time.

The first is if the product is incomplete, too low-level, or difficult to use. This often results in large amounts of yak shaving to get anything useful done. You can't get into a flow state if you're staring into the abyss of errors, or constantly having to RTFM. Here are some examples of things that fit into this category, from my personal experience:

The other extreme from which developers will critizise products is being too high-level, restrictive, or not having enough options. You can't get into that flow state if you don't get to engage your brain! As an example, the Wikipedia page for software frameworks has some hilarious "[citation needed]" back-and-forth about the pros-and cons of frameworks. The interesting thing is that both sides of this debate want to write lots of code and be productive. They're just looking at it differently. The OG framework demo was all about how quickly you could start writing code. Meanwhile opponents of frameworks say that they spend more time learning how to use the framework than coding.

Another area where I wonder if the products are too high-level, or restrictive is the so-called NoCode space. There are a bevy of well-funded startups, like AirTable, ReTool, and Webflow that claim to eliminate the need for coding to build websites. The thing is, I have tried a couple of them, and the UIs aren't as intuitive as you might hope. I also can't imagine myself achieving a state of flow with them. I've spent many, many hours in my life writing things like this blog post, or programming in Java and Python. To me, graphical UIs don't get you that feeling of building that you get from typing at a command line, or even typing up a document.

I can imagine people reaching a flow state if they're really proficient users of, say, Photoshop. But I'm not sure that these NoCode tools encourage the high level of mastery that a professional photographer, or editor might have. As such, while they're interesting tools, I struggle to see them catching on in a way that justifies the kind of valuations that VCs are looking for. But it's still early in this space, the jury is still out. Maybe I'll be proven wrong, we shall see!

Conjecture: Flow = developer love

To me, if you're trying to build something that developers truly love, I think you need to answer the following question: Can you imagine some skilled hacker spending all night working away with your product, emerging into the morning light having built something nobody has ever seen before?

I can imagine Dade from Hackers spending many hours using these products.

Conclusion

Concentrating on a game

Firstly, next time I see developers apparently acting irrationally, I'll be asking myself: Did this person once reach a flow state using a certain language/framework/whatever? Maybe they're searching for yet more optimal experiences, just as a jazz musician, surfer, or artist might be. I'll also try to remember that it can seem quite idiosyncratic at times. One persons optimal experience could be another persons nightmare.

Secondly, when building products for developers, perhaps LEGO is the best example to keep in mind. You want to let the user get building as quickly as possible, and instructions are helpful. But you want them to actually build the thing. That's the fun part. Also, you want to let them put the pieces together in any way they like. The instructions are just a suggestion.

Once I hit publish on this post, I think I'm going to go for a run. Maybe I can stop thinking about how many people are needlessly dying due to Murdoch-owned media outlets being xenophobic, and anti-science long enough to achieve a state of flow.

P.S. Thanks to my parents for finding the old photos I used in this post.

If you're interested in building things that help developers reach a state of flow, then please get in touch! I'm building a company, and looking for like-minded people.

Footnotes

1: The New Kingmakers: How Developers Conquered the World, page 22.

2: Rumours that I was fired from my ski-shop job for being late too often are entirely baseless and unsubstantiated. The fact that I went into software engineering, which famously allows late start times5 is entirely incidental.

3: If you're reading this and know anything about distributed systems, or NFS, you might be thinking this sounds like a bad idea. You would be right.

4: Don't even mention xorg.conf (shudder). If you do mention xorg.conf in my presence, you have to buy me a beer.

5: I've heard rumours of engineers being late to 11:45am daily meetings.