If you’re like most people, you probably have a lot of unfinished projects. Pick one of them, close your eyes and try to think of all its moving parts. If you’re really good, maybe you can keep it all in your minds eye for a minute or so. If you’re like most people, probably less than that.
Which is a problem, because all the stuff that we can’t keep conscious about will mess with our ability to stay calm and productive. That’s why we need to externalise our thinking.
Distributed cognition is a fancy term for that, and it can take many forms. When you forget the details of some complicated concept and have to consult an external resource, or when you write down all your todo items, those are examples of distributed cognition. Simply put, it’s the notion of not having to keep everything in our heads all the time.
Higher education is largely a matter of creating systems for distributed cognition. The point is not to make everything stick, but instead to learn the lay of the land and understand where to turn for reference.
I’ve come to think a lot about the interplay between different modalities of distributed cognition. I think there are three important ones:
- Virtual
- Tactile
- Three dimensional
Externalising ones thinking into a virtual space is pretty much the default mode for many of us. We put todo items into Trello or GitHub and design documents on Drive, Notion or Evernote.
This is certainly convenient; everyone can access everything from anywhere. The drawbacks might not appear initially but they tend to crystallise as a team expands.
A fully virtual workflow seems relatively forgiving to the quirks and whims of individual team members. Why invest too much in staying organised, when everything is version controlled and you can roll back if something goes wrong?
Well, if you’ve seen this play out in real life, you know how hard it can be to keep entropy from seeping in.
The first counter-measure is usually to create guidelines that nobody will stick to, then to assign someone with the thankless task to police said guidelines.
When all else fail, you resort to printing todo items on pieces of paper.
In one instance when I did this, I ended up covering a whole wall, floor to ceiling, with catalogue cards representing user stories, each of which were colour coded to indicate forks in possible product roadmaps. Taking a step back to look at that wall together with my team was a pretty sobering experience. It clarified the fundamental condition that is true of any software project: there’s always more to do. That is to say: no matter your capacity, you can never tick all the boxes of everything that “ought to be done”.
Which forces the realisation that you need to be very mindful of your priorities.
An exercise like this also usually results in a new iteration of translation work where you rescope and go back to digital formats, only to again start over with papering that wall.
This cyclic process of moving between virtual and tactile formats will seem time consuming until you take into account the enormous gains that is to be made by simply de-scoping entire branches of a future development roadmap. That’s when you realise that you’ll never have better leverage over the outcomes of a project, than when decisions are made at the drawing table. Hence, switching back and forth between virtual and tactile formats will be worth your while, simply because it improves your cognitive powers.
I find this logic also applies beyond situations of collaboration. In my daily casework I take copious amounts of paper based notes, only to then feed them into an online database. This process is not mere transcription, instead it’s a step that requires me to stop and reflect. What gets stored in virtual format is an interpretation of my physical notes. As such it inherently adds value and helps me making sense.
The same is true for reading. Most my books are full of underscoring and scribblings in the margins. This physical metadata is soon rendered opaque, so I’ve gotten into the habit of immediately capturing them to a a digital notebook. This format is somewhat more persistent, but still coded in my own stream-of-consciouness-like mix of quotes, insights and associations. In order to really make sense of what I’ve learnt, I’ve got to rinse and repeat, which usually means I have to make the effort to publish a blog post, since there’s nothing like the prospect of a reader to force discipline to my thinking.
One of the most powerful modes of distributed cognition means externalising your thought process in 3D. My own hobby-grade carpentry provides an example. Being that I’m an amateur, I can rarely formulate the end result when I set out on a new project. It’s not that I couldn’t produce a sketch in either virtual or tactile format, it’s just that I lack the power of imagination – a skill that can be trained – to visualise where I want to go.
So the only way to avoid ‘analysis paralysis’ is to get going. I simply start building, to let my hands show me what I have in mind. Then after spending weeks and months on making a cupboard, a cabinet or even just a bird house, I often come away with the feeling that it’s only now that I know how it really should have been done.
(I think most programmers can relate to that feeling. It’s really not the right approach, but often the only feasible alternative given the levels of complexity in most software projects.)
(I also think it’s the unfair advantage of any hardware-centric project that you’re simply forced to engage in this mode of distributed cognition)
The problem with externalising your thoughts in this way of course, is that it’s slow. But the way to tackle that problem is to ackgnowledge that velocity is always relative. Even if you end up tearing down your first attempt, you’ll eventually have saved more time than you’ve wasted when you get to building ‘the real thing’.