I was first introduced to the idea of microtransactions as a negative thing. Back in 2011, any number of games were popping up across the interwebs which were harnessing the buzzword ‘microtransaction’. For those who don’t know, microtransactions are a business model where users can purchase virtual goods with micropayments. Five cents here, ten cents there, a dollar here, a dollar there. Rather than paying big sums, gamers pay tiny amounts to buy googahs and upgrades of this or that.
Now, many people think microtransaction is a fancy term for ‘bleed the player dry’, with which I can’t say I entirely disagree. The basic model of a ‘microtransaction’ is that most of a game is free to play, but if you want the bumps and extras, you have to shell out dosh to get them. This concept has grown over the years into ubiquity, and now I’m told it’s quite common. As I’m not here to debate whether this is an ‘intriguing business model’ or a means of scamming people, I’ll digress, but what I will say is the idea of microtransactions appeals to me as a software developer. And here’s why.
The Context Switch
Many devs often liken themselves to a PC. It’s a tired metaphor, but somehow one which never seems to die. Devs like to throw around terms like ‘multi-threaded’ or ‘multi-tasking’ when talking about how they work, and in my mind, this is nonsense. Human beings are NOT multi-threaded. We do not complete multiple tasks at the same time. The human mind is single-threaded, but with an insane capacity for task-switching. We are really good at doing one thing, then jumping to another, then another, etc. It might feel like multi-tasking, but it’s really jumping around really quickly.
The issue, of course, is that jumping between differing tasks (to carry on with the PC metaphor, known as ‘context switching’) means dumping memory to disk, loading the next task’s details into memory, and then starting to perform whatever task is in front of us now. Anyone who has been working for any length of time knows that switching between contexts is costly. “Wait, what was I doing?” is a common enough phrase one hears, and with software developers, this can be time-wasteful, if not downright dangerous. Going from one task to another means picking up where you left off. The bigger the tasks you are jumping between, or the longer period of time you spend on another task and then jump back, the harder it is to get back into the stream, to switch contexts back to where we were on our earlier task.
Joel Spolsky has an excellent post on how long-running context switching is terrible for developer productivity
Microtransactions: How developers work
Devs tend to focus in on a task, and devour it until it is complete. A code review, a bug fix, kicking off a build, a debugging session. Any of these are part of a dev’s day-to-day life, and in most cases, we perform these tasks to completion because it requires so much of our concentration, and that’s how we’re wired. There is a fundamental glow one gets from task completion. We enjoy the satisfaction of finishing something, and then of moving on to the next challenge. I liken it to gaming. Clearing a level in an RPG, completing a combat round in a FPS. I love the feeling of finishing a unit test, running the suite, then checking in the code, only to go on to the next such action. There is an endorphin rush from such completion. Even if what I’ve done is quite small, I take satisfaction in the completion.
Now, by and large, most devs have one task which is their primary, with a lot of other tasks over the course of the day which are secondary. The secondary tasks are like sub-quests to an overall quest. We know we must complete them, but if the sub-task gets too big or takes us too far from our primary task, we tend to lose focus, to context switch for too long. Indeed, when pulled away significantly from the primary task in progress, most devs are irritated. “I got knocked out of the flow” you hear a lot. “I was riding the wave, and then someone bugged me, and I lost it.” Devs want the ability to focus in on a single problem, solve it, and move on.
There is an exception to this, of course. If the secondary task to which we are switching is extremely small, if the context we switch to is momentary and fleeting, then there is no real reason for us to really ‘drop what we were doing’. We simply rapidly do what is needed to be done, then return to the more important work we were on in the first place.
When you watch devs in action, switching quickly between a main task and tiny, inconsequential tasks is very common, and how most devs seem to like to work. This kind of working to me seems to be an example of microtransactions. Devs can deal with microtransactional switches to other tasks, and actually can thrive on the rush they get from tiny secondary tasks (like helping teammates or fixing a small merge conflict). If I’m working on complex code, I can jump to kicking off a build, or pushing some code to origin, because the amount of brain power and concentration necessary to switch is minimal, so it doesn’t break my flow. I also get little bumps in endorphins because I’m completing tasks quickly, all the while keeping the main body of work flowing nicely.
Microtransactions and communications: How devs interact with each other
When it comes to communication between developers, we have all kinds of ways this is done presently, and many of them are quite terrible to this kind of microtransactional behaviour model. Long meetings, constant shoulder taps, people pestering you for a giant review, and so on. The more we break one another’s flow, the less capable we all are of doing our jobs.
Yes, at times, we do need to look up and go “AFK”, but is it as often as we think it is? Much like we once created monolithic applications, we now know that modern computing theory points to microservices. I contend that long detours away from a dev’s primary task is the collaboration equivalent of these old monoliths. Developers are far better off communicating in microtransactions, keeping the interactivity but without the excess of distraction and context switching.
I think it is best to follow some simple rules to ensure that any communications are microtransactional
- Asynchronous: As outlined by Petri Kainulainen in his post, devs interrupting each other is a big issue. If a dev needs something from me, I’d prefer to be contacted via chat or IM or a collaboration tool, and when I am ready, I can switch to that, see your message, and rapidly respond.
- Quick and clean: If you need me to review something now, don’t send me 40 files in a review. I want to look at one file, with as much context as possible, so that I can approve or decline nearly instantly. Too much code or having to reconstruct context for your review is not microtransactional. It’s a big drag away from what I’m trying to do.
- Integrated: If I have to jump over to other programs all the time, or to look up from my IDE to do what you want from me, this is asking for a pretty significant context switch. I want to help you with a task if I can, and optimally, I want to do so without changing to another program. My IDE is my workspace, so interactions and communications should take place there as well.
- Noninvasive: If you need to communicate or collaborate with me, I don’t want some alert popping up in my face all the time. This is just as distracting as trying to code through the three fire trucks blaring past with their sirens on. Invasive communications or notifications are those which regularly nag or distract my attention. I should know that you need my attention, but I should just as easily be able to ignore it until I’m ready. Too many popups or bleeps mean I hate the notification tool, and ultimately, I start to begrudge you.
- Configurable: On any given day, I may be in a helpy kind of mood, and I might be in a “Do Not Disturb under penalty of death” kind of mood. I want the ability to configure this based on my mood or workload. I might have a tight deadline to complete some code, or I might be up for pairing sessions quite regularly.
- Automatic: If something can be done automatically, with only a quick scan and an ‘approve’ on my part, then all the better. I don’t want to have to deal with every last issue if a machine can do it for me. Unlike so many people out there, I trust computers to do right by me, particularly if I’ve seen previously that they know how to do things the way I want them done.
Coactive: A platform for development using microtransactional thinking
Over the last couple of years, we’ve been developing Coactive with these very goals in mind. We‘re engineers as well, and we know how developers work. Coactive is a messaging and collaboration platform for software developers. It is the result of our experiences as developers, and some heavy thinking of how development can be streamlined and improved for teams and individuals.
Creating a collaboration and communications tool inside your IDE is not simply about an extension or a plugin. It’s about looking at how we work today, and what aspects of this process can be made better based on how real-world developers think and act.
For those who are interested in helping us explore and grow this idea, we are eager for users to join Coactive, and work with us to grow the next generation of developer collaboration tools.
We’d love to hear from you