Can individuals write code?
Can individuals write code? I think that your answer to this question will, to a large part, predict your attitude towards software engineers being asked to return to the office for all or some of their working week. It describes two nearly-incompatible ways of working, and few people understand that the other way even exists.
The dinosaurs
Lets look at the clash. Many employers are asking their software developers to return to the office. A vocal and online group of these developers are angry, but most of all confused and perplexed about why their employer would sacrifice the productivity they can achieve by working from a beach villa or scrapping the daily commute.
The life they permanently want to lead is within grasping distance: Fully asynchronous, totally agnostic of their physical location, fitting around their hobbies and their family. Why would anybody take this away from them if they can sustain their output?
Big questions generate overly simple answers, here are some I see popping up a lot:
- The companies are dinosaurs, they cannot see that the world has changed, and they are making short sighted decisions because they don’t have the courage to move on.
- The companies want to observe and control you, to monitor your output.
- Immense pressure from commercial real-estate interests forced the decision.
No doubt there are some old fashioned, cynical employers who think this way. Maybe they are even the majority of mandatory return-to-office employers (though I find that a little hard to swallow.) I don’t want to talk about those organisations.
Occasionally, I see a Tweet or a comment on LinkedIn from somebody who is not a corporate director saying something like: “Co-located teams are always more productive than remote teams”, or “Remote teams are worse at innovating”. This person will be shot down immediately.
If you view this as a clash between cynical dinosaurs vs creative brilliance, then the developer taking the side of the dinosaurs must be a sell-out, or brainwashed.
Here’s another way to see the clash: Individual vs Group oriented production.
Individual oriented production
This is by far the most common way to organise people to produce software, and is the way I used to work back in 2011.
At the time, I was building ecommerce software using Hybris and Java. I was working in an office (with a nice view of Buckingham Palace), I had a desk and an iMac that were permanently assigned to me.
The work I was doing was often challenging, with complex refactors that made me sketch class diagrams to get right, but it was extremely well understood.
At the time, most brands we worked with just wanted a web shop. Occasionally they’d have a loyalty card system or something to integrate with, but more often than not it was search, carts, accounts, order management — and it all worked the same way.
I worked solo 95% of the day. Unless I was really stuck and couldn’t unblock myself, more often than not I’d work with my headphones on. I’d find it incredibly annoying if somebody interrupted me, breaking my flow. I hated meetings.
I think this is the most common way of experiencing offices as a developer. Your work is individual, focussed, and deep — and the office (especially the dreaded open plan office) is trying to fight against you, and distract you from doing your actual work. I believe that for many people engaging in the debate, this is the only way they have worked.
I’ll call this individual oriented production. There are lots of flavours of it, of course: Open source projects, fully remote asynchronous organisations, developers in cubicles in a shared office space, etc.
These are teams where people mostly work solo, where their time spent writing code is considered precious enough to protect it by defining requirements clearly in advance, where individual ownership of pieces of the solution is rewarded, and where uninterrupted flow is the ultimate sign of efficiency.
The defining characteristic of these teams is that the team’s productivity is equal to the sum of the outputs of each developer.
Group oriented production
By 2015, I had totally changed my outlook. The way I liked to work had become intensely conversational. I was in favour of two engineers working with one single keyboard, of doing requirements analysis at the same time as we were writing code to meet those requirements, programming was more about using my voice than my keyboard. I liked there to be other pairs of engineers working in ear shot so we could eavesdrop on each other and come in with helpful extra pieces of information.
I was pretty much doing a different job. While there are of course crossover skills between these two jobs, they feel as different to me now as driving a car and flying an aeroplane.
I’ll call this group oriented production. Again, there are many flavours: Extreme Programming, Mobbing, etc.
These are teams where people mostly work in groups, where there is intense resistance to attributing any success or failure to an individual, where developers only ever seem to spend 5–10 minutes actually writing any code before diving right back into a conversation again, and where the interface to developers is to tell them about a problem, not a requirement.
The defining characteristic of these teams is that the team’s productivity is equal to the successful facilitation of contrasting skillsets and interpersonal dynamics.
In short, they are teams where individuals cannot write code, groups write code.
Contrasting behaviours
These two archetypes require extremely different behaviours and skillsets to operate in. You need to know how to write code in both, but beyond that they are almost different jobs. It’s like seeing surgeons and playwrights arguing about whether or not working from home is viable.
Brain space
In individual oriented production, the most productive people often have an incredible capacity for in-brain working memory. The times I felt most productive was where I could have a huge system sketched out in my head, balancing on the edge of forgetting a little detail, figuring out where my change sits and what it might affect. This is a really fun skill to develop, and is directly connected to the idea of flow. If you’re visualising a big structure in your head, and then somebody comes to your desk and asks about your expense report, they destroy a huge amount of the time you have spent.
In group oriented production, you need to be good at choosing tiny steps and guiding the emergent design of a system, one little choice at a time. Are you going to build a system that does some complex financial settlement? You might start by defining a unit test for what happens if someone tries to input null instead of a transaction. Write a test, get it working, commit the change, move on. Your working pattern is a mini conversation, 5–10 minutes of coding and simultaneous discussion, rinse and repeat. You need to be masterful at predicting how these tiny changes will add up to the overall system that will eventually exist. Your brain space can be small (great news for me!), so long as you have some strategic patterns in mind to predict the likely emergent effect you are having on an architecture.
Requirements
In individual oriented production, you kind of need to know where you’re going before you start. Your working pattern should include flow, so you want to get all of those interruptions and distractions out of the way early. You need to be good at reading into the detail of requirements, and anticipating all of your clarifying questions in advance. If you do this well enough, you can get multiple hours of flow in a day.
In group oriented production, you aren’t optimising for flow at all, so getting everything clear right at the start matters way less. Instead, you need to be good at prioritising your questions: What are the fundamental questions that we need to even pick a direction? What are the questions that we can just figure out as we go? What are the questions that don’t seem to matter much, and we can just risk getting wrong? You also need to be good at bringing in the right people at the right time: Roughly when do we think an expert designer or product manager would be good to collaborate with?
Consensus
In individual oriented production, you get to make a lot of calls. While there will probably be a process of code review, your career progression will be partially down to how good you are at calling the shots when it comes to building the components you are assigned. The important thing here is to get good at making a call and documenting the call you made. One thing I sometimes observe here is that if you build a feature, commit to owning it, and continue to iterate on it as an individual — you have done a fantastic job. You solved the teams problem by yourself, freeing them up to solve other problems.
In group oriented production, it’s more about evolving your team consensus. A consensus might be something like “In general, we apply this pattern in this situation”. This might also include documentation, of course, but you might find that it’s more effective to use demonstrations or mobbing to spread consensus instead or in addition. Here I observe the complete opposite response to the same situation. If you build a fantastic feature, but there are not others in the team who came along the journey with you, who fully grasp each part of the tradeoffs made, the strengths and limitations of its design: You have completely failed to do your job, because you introduced an individual dependency, and harmed the teams ability to operate as a collective.
Isn’t this about asynchronous rather than remote?
Yes! As Allen Holub has pointed out a number of times, there is an annoying conflation between remote ways of working and asynchronous ways of working. In reality, remote synchronous teams (that is, where everybody collaborates using online tools in real time) are group oriented production teams.
These two issues have become deeply linked however, for two reasons:
- The loudest advocates of permanently leaving the office behind are also advocates of asynchronous development, to the extent that you cannot talk about a remote first plan without tackling the synchronicity problem head first. I see comments such as “If you’ve gone remote and you’re trying to recreate your old ways of working online, you’re doing it wrong”. I’ve seen remote working presented as a step on an evolutionary scale to fully asynchronous ways of working. This is almost received wisdom at this point, so if you want to answer the remote question you must simultaneously answer the asynchronous question for it to make sense to anyone.
- I think they are actually fundamentally connected if you see them as enablers of group oriented production, it’s just that one massively overshadows the other. If synchronicity gives you 80 points on the Group Oriented Production meter, physical co-location gives you an extra 10 points.
Is this an arbitrary choice?
Almost certainly not. Each solution has its advocates, and I suspect that as we see a strong bifurcation in the market (as the question is forced by the working from home debate) we will see people starting to understand more about which contexts highly collaborative or asynchronous problem solving is more appropriate.
I’m reminded of how Simon Wardley describes the people who break organisations by insisting on “Agile everywhere!”, whereas his maps show that there are some highly commodified, highly understood sections of the business where Six Sigma might well make more sense.
For individual oriented production, I suspect the office question is a done deal. There are very few advantages that anyone can point to of working solo in one place vs working solo in another. Companies that want to do individual oriented production but also insist on returning to work are probably going to be left behind.
For group oriented production, there are going to be a wider range of views. If collaboration in real time is the advantage, then clearly there will be some people who prefer facial expressions and whiteboards to zoom and miro, but equally there will be people for whom that difference is not stark enough to sacrifice the ability to spend some extra time at home. All points on the scale of fully remote to fully co-located feel like reasonable decisions for a team to make when they are working as a collective.
As I hinted at when describing my old ecommerce job, I suspect that how well understood a problem is might be a contributer here. My switch from favouring individual to group oriented production coincided with my switch from building things that my team and my customer fully understood, to getting building things by getting around a whiteboard and saying “What are we even trying to achieve here?”
There may well be other facets that we learn to consider, and we must learn to trade off productivity with other factors (access to talent pools, employment benefits, problems that require input from people in different time zones, etc.)
Above all though, we need to learn to ignore people selling real estate or remote working software and make our own decisions.
Feedback
I sometimes go back and edit these articles, so do feel free to tweet me some feedback.
