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.

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.

A Structured RFC Process by Phil Calçado

When I wrote Technical design: whether, who, how, and what it was partly because I haven't seen a lot of guides of this sort. I'm pleased to say that Phil Calçado has offered a similar how-to at A Structured RFC Process.

Some of the key similarities between A Structured RFC Process and my post are: (1) a discussion of who should be involved, what kinds of topics need this sort of process, what to include in such a design, and what it looks like to solicit and get feedback, (2) the focus is on the higher level or more important aspects, not specifying every detail, (3) the emphasis is on feedback and discussion, not on formal sign-offs, budgets, or other things which might be worth nailing down, but not in this sort of design, (4) relatedly, documents (and other artifacts like presentation slides or videos) produced during technical design have a relatively short half-life. They sometimes can be helpful well into the future but that's not their main purpose. Their main purpose is is to flesh out a change and organize writing code and whatever documents you have to describe "this is the current state of our system" (API documentation, wiki pages, or whatever you find useful). As Calçado says, "once an RFC moves away from Feedback requested, it is considered a historical artifact".

A few differences between my post and A Structured RFC Process are: (1) although I started thinking of a document with comments (as described in A Structured RFC Process), as I wrote I realized that most of what I was saying also applied to hallway conversations, presentations, or other modes of communication, (2) I include a list of technical issues you might want to address (or might not).

One interesting observation was "It is not uncommon for engineers to try and use the process as a way to sell an idea that hasn’t been approved by their stakeholders or managers" which I certainly have seen. Depending on how much of a power vacuum we are talking about (or, relatedly, lack of clear priorities), this could be a large or a small problem, but approaching design deliberately is not a substitute for making choices. It is at best a way to help clarify what choices the organization is facing.

And my favorite quote from the whole article is "The more polished a document looks, the softer and less impactful reviews tend to be". I love this. Not only does it match suggestions I've heard in other realms (for example, "to get good feedback on a user interface, show someone a napkin sketch, not a pixel-perfect mockup"), but it helps clarify one of the reasons why I've not always seen good results from highly formalized documents written in very structured and detailed ways. Not only is the content of such documents sometimes buried in a lot of boilerplate and irrelevance, but the very form discourages the kind of engagement which would make them seeds for raising issues which might be otherwise missed.