I’ve not called myself a software developer for at least thirty years. That’s not to say I’ve stopped coding. Far from it. But the end in mind has changed. From “developing software” to “attending to folks’ needs”. Seems to me that latter frame offers far more potential for satisfaction – both for me and for those I serve – than coding ever did. See also: #NoSoftware and the Antimatter Principle.
After all these years, I still love coding (as in writing software).
It’s just that it’s tainted by the certainty that there’s so many other more effective ways of adding value and meeting folks’ needs.
Spending time coding feels so… self-indulgent.
Scope of Ignorance
Most of the developers and development teams I used to work with when I was a software development consultant had a relatively narrow view of the skills and knowledge necessary to be “competent developers”. Here’s an illustrative graphic:
Generally, to make progress on improving things, and to earn the moniker of “software engineers”, a wider scope of skills and knowledge was necessary. Not only did these development teams lack this wider scope, they were both ignorant of the many additional areas of knowledge and resistant to learning about them. The common response was “What are all these strange topics, and NO WAY! do we need to know about them”:
Aside: Now I’m an Organisational Psychotherapist, their ignorance is no issue – and no stress – for me. They can learn or not learn in their own time. Progress is on them (and their higher-ups).
Excolat in Pace
There’s a common idea which has been doing the rounds, ever since development (coding) first became a thing. We might sum it up as:
“Developers just want to develop in peace.”
As someone who spent more than a decade in the development trenches (and still does development today, occasionally), I can instantly relate to this issue. Indeed, focus is the key question. Any kind of interruption or distraction whilst reading or writing code can suddenly evaporate the evolving mental model of the inner workings of that code, a model built up painstakingly, with deep concentration, over twenty minutes or more. So three for four interruptions or distractions, however trivial, can wipe out an hour of otherwise productive effort. And that’s before we get to the question of frustration, the impact of frustration-induced stress on the individual, and the stress-related impairment of cognitive function more generally.
On the other hand, having developers separated from the folks that matter introduces other productivity-sapping dysfunctions, such as misunderstanding folks’ needs, building the wrong things, and reducing the joy of getting to see how the developers’ efforts make a difference to others.
So, how to ensure developers have the peace they need to focus intently on their coding efforts, whilst also ensuring they have sufficient interactions with the folks that matter – sufficient to ensure that needs are understood and the right solutions get built?
In the past, specialist intermediaries a.k.a. Business Analysts and Project Managers have served to address this conundrum. And solutions (including the role of specialists, and the workplace environment) have been imposed on developers without much consultation. Rarely have developers, or the folks that matter, been involved in finding a way forward together.
Personally, and in the context of self-managing teams in particular, I’m all for the teams and their customers (both internal and external) getting together and thrashing out a way forward. And then having regular check-ins to improve those ways of working together.
As an example, BDD (Behaviour-deriven development) is a current set of practices that offers one such way forward. Customers and suppliers sitting down regularly (as often as several times a day, for maybe twenty minutes at a time) and working through a User Story, Scenario, or Use Case, together.
And let’s not forget that the other folks involved, aside from the developers, also have their day jobs – jobs which require them to focus and spend time on things other than working with the developers.
How do you, your teams, and their folks that matter, propose to tackle this conundrum? How are you handling it at the
Another option that comes to mind is mob programming a.k.a. mobbing, particularly with the involvement of folks having in-depth domain knowledge (i.e. customers and users).
The Future of Coding Environments
How would Scotty or Geordie go about writing code for the Starship Enterprise? Would they write code at all? Would they just interact with the Computer via speech or holodeck, or would a keyboard of some sort still have a place?
In any case, my interests have always stretched beyond matters of organisational effectiveness, beyond matters of human and humane relationships, and beyond matters of how the work of software and product development might better work.
One of my other abiding interests has been the nature of programming. Indeed I spent more than two years, decades ago, on conceiving, designing and implementing a proof of concept for the kind of development environment I’d like to use myself, when writing code. At the time, the work was codenamed “Simplicity”.
My core feature set / wish list includes:
- Editing source code directly in the AST, rather than editing source code in text files
- Direct and incremental compilation of source code as it’s being entered
- Multiple coders editing in the same AST concurrently
- Live editing of the AST “in production” (with appropriate safeguards built-in)
- One homogenous AST for each entire (live production) system
- Source code control / version control features built right in (and automated away from distracting the coders)
OK, so this may not be the kind of development environment Scotty or Geordie would recognise. But it’s a world away from all the crap we have to put up with today.
So why don’t we see more movement towards the emergence of some of these features in our development environments today? In a word: conservatism. Developers en masse seem disinclined – or unable – to look anew at their tools, and dream.
“The future is a foreign country; they do things differently there.”
The Mjølner Environment ~ Görel Hedin, Boris Magnusson