Afterwood

As a child, I loved playing football (nay, soccer). Every waking moment was an opportunity to get outside and play football. At school, lessons and lunch were merely a chance to catch my breath before heading back outside again at break or lunch time to play another game. The school holidays were a Utopia where football could be played from dawn to dusk with no pointless interruptions, like lessons.

The first real distraction to put a significant dent in my football time was when the father of a school friend built himself a ZX81 from a kit and we got to play on it one summer. The discovery that my next-door-but-one neighbour had a ZX80 sitting idle in their attic nibbled into more of that time, while the remainder slowly became a victim to an increase in swimming training until football became the exception instead of the norm. It wasn’t until starting my first proper job at a software house where they played football together after-hours that I got my boots down from the attic and rekindled my love for the beautiful game.

I never played as a striker, even as a child, so I resumed my previous position in the defensive line, sometimes as a left- or right-back, but mostly as a centre-half or sweeper. This position tends to be frequented by players who are tall and reasonably well built and hence it can earn them the somewhat dubious title of ‘Big Man at the Back’. Naturally, from such a central position you have a good view of the field of play and can coordinate the surrounding defenders and mid-fielders. Each player acts with a high degree of autonomy, adapting to the local conditions as the opposing team surges forward, but the centre-half also has one eye on the rest of the field so that the defence can adjust itself to the changing face of an attack.

Having never played (adult-wise) at anything more than Sunday League football (i.e. ‘pub’ football) I have no idea if this is how a real centre-half plays or is even supposed to play; it just felt natural to play that way. As a professional programmer, I have found myself gravitating towards a similar role with the various teams I’ve worked in over the last couple of decades. If we consider the goal to be the delivery of bug fixes and new features – the crowd-pleasing items – while the opponent is the background noise of complexity, tooling, deployment, documentation, process, etc. then you’ll usually find me tackling the latter rather than ramming home the former. Naturally, I’ll surface around the 6-yard box every now and then for corners and free-kicks but I’m just as happy with an assist as a name on the score-sheet.

While in the early years my own skills were growing in many directions as I uncovered the mountain of things to learn, once I had a grasp of the basic mechanics of programming I found more time to comprehend many of the more peripheral duties which make the sustained delivery of software hard. While it was never a conscious decision at first it always seemed more important to help colleagues out, where possible, rather than plough on with my own assigned work uninterrupted. Before I’d even heard of pair or mob programming I was in no doubt that I had a far more enjoyable time working with other people and so to be more knowledgeable in those areas that others were less interested in gave me an opportunity to work more closely with other people. Naturally, it’s a two-way street and, much as I enjoy reading, learning from other people feels far more effective.

While I’m happy to ‘watch their backs’ and help the team and, by extension, the company reach a global maxima it’s not a position that sits well within many large organisations due to the way they assess progress and performance. When working in a small team that sits together where the management can see you physically wandering around the desks or standing debating with colleagues across the partition it gives a very concrete view of collaboration which no doubts helps promote your value to the team, even if your personal goal tally for the season is a little on the low end.

When working entirely remotely this advantage disappears – out of sight, out of mind. With no physical presence to rely on, a management team that relies solely on metrics, perhaps one metric in particular, like the number of JIRA tickets closed, is likely to form a less-than-flattering picture of your productivity or ‘value’ to the team. Lest you think an organisation would be foolish to consider this approach any more valid than counting lines of code or number of commits; trust me, it happens. Hearing phrases like ‘they have their own work to do’ should be considered a free-kick on the edge of the penalty box. Ultimately such times of madness demand us to summon Charles Goodhart and game the system.

As a proponent of the Russian proverb ‘trust, but verify’ I do not expect anyone to blindly trust me any more than I expect someone to be watching my every move. Trust is also a two-way street and I expect any verifier to look past arbitrary metrics and find the fingerprints that the team leaves behind in the commit log, meetings, documentation, chat channels, etc. If someone is having an impact, their presence will be observable despite the best efforts of some products to cling to the outdated notion of one person one task.

I might have finally reached an age where nature has convinced me to hang up my boots again for good but it’s not changed my position. Software teams run more smoothly when they have someone that can read the game well and provide backup and support when necessary to help them get the results they’re after.

Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros. These days it’s enterprise grade technology in plush corporate offices. He also commentates on the Godmanchester duck race.