Friday, April 23, 2021

Flow

So if you've been around tech, you've probably heard of flow. You know, the state of concentration where you are one with the code, getting stuff done, and the code loves you back. This is also often said to be incredibly fragile: the slightest interruption will cost you 15 minutes, in terms of how long it takes to resume your concentration.

Although I've experienced this enough that I think I understand the process described here, my own experience of flow has much more to do with other people. I use the analogy of improv comedy - I suggest a thing, you say "oh, but what about this other component?", I say "well, let's try an experiment to confirm that idea", you say "ah, and that means we can delete this part of the code" and I say "oh and now that's gone, we can implement this other thing in a more elegant way". If you've heard of the "Yes, And" concept (which originated in improv and has been borrowed to workplaces) this may sound familiar. We're riffing off each other, we're generating ideas and figuring out where to take them, we're bringing in multiple perspectives about what we are trying to accomplish and how we are doing it.

I mentioned this analogy to a co-worker who is a musician in their spare time. And they immediately said "oh yeah, jamming with someone is definitely a thing" (and contrasted it with teaching, which can feel quite different).

Everything so far is based on my own experiences and folk lore within software companies. To write this post, I figured I should at least look a bit at academic or popular writing on flow, which seems to start with psychologist Mihaly Csikszentmihalyi who originated the term in 1975, and proceed to follow-on work in the following decades. Well, I've only read a few short summaries, but what I did surprised me a bit. It didn't neatly fit into the model of flow being all about being solitary and avoiding all interruptions. As far as I can tell it has just as much to do with whether goals are clear, whether the skills needed are within reach (with perhaps a slight stretch), and whether there is immediate feedback. And that flow can be either individual or group. I'd already decided that I didn't need to be threatened by the concept of flow even if it seemed to be promoting a working style which tends not to work well for me. That is, that I could redirect the concept to something which is recognizable but closer to what makes me thrive. It was nice to see that what is written on flow turns out not to be quite as different from my own thinking as I had initially imagined.

Wednesday, April 07, 2021

The four kinds of developers

I'm probably going to go to hell (or worse yet, business school) for presenting it this way, but developers (or probably more accurately development tasks) fall along two axes:

One axis is gregarious/solitary

One axis is coding/non-coding

  • Gregarious+coding: pair programming, code review, group debugging, hackathons
  • Gregarious+non-coding: standing around a whiteboard figuring out an architecture, reviewing an incident together, hashing out requirements via discussions
  • Solitary+coding: put on those headphones and make the software work. Make it beautiful. Make it sing to me.
  • Solitary+non-coding: think hard about some really tricky algorithm. Gather a bunch of written input and write a design document.

Disclaimers:

  1. Unlike the classic 2×2 matrix, no quadrant is better than the others. Individual personalities, whether people happen to click, and other factors will push in various directions or towards a mix.
  2. This describes various activities on a technical track. I'm not trying to describe management track.