Just a techie? – Techies, Devs, Boffins and Geeks.

As soon as I hear the word 'techie', I feel an emotion-cocktail of frustration and despair, with a sprinkling of betrayal. Subdued through repetition this negative response may be, it’s nevertheless a call to action. A call to protect the techies (myself included), and a requirement to be vigilant about the state of the project.

I recall decades ago reading a 'red-top' newspaper in the UK called "The Sun", and whenever it talked about a scientific matter (rarely), it would refer to the scientists as 'boffins'. It was a mechanism to dehumanise this class of people, so that the fact that they are clever and coming up with ideas, doesn’t matter on a personal level. They’re not like you and me and we’re not inferior to them - in need of being challenged on our life-choices - as these people are simply just boffins!

So it goes with techies. This is a bunch of people who just love to geek out and play with computers. Just make sure you’ve got adults in the room to shepherd them and to talk to them on your behalf. There’s a knack to it.

It’s not simply the insidious dehumanisation and the patronising that bothers me - which to be fair, is a human condition - rather it’s the attempted commoditisation of what is a highly specialised trade. When you trivialise a trade, you make the trades-people interchangeable.

This isn’t a them-vs-us thing, because inside of our collective profession, we regularly do it to ourselves. There’s a destructive pattern inside of Agile software development of squashing individualism. Devs can’t be trusted to work solo, so pair them up. Devs can’t be trusted to think holistically about the problem at hand, so each 'story' needs to be written child-like. We demand TDD, a convoluted code-review and branch process, and antipatterns such as 'the big ball of mud' terrify us, so we must insist on nano-sized microservices to promote code shared ownership and polyglot diversity, so that each service can be rewritten at any time in any language, and no single developer can possibly ever become a bottleneck.

This is at the grass-roots level. The problem gets worse when the 'scrum masters' are landed, promoting slogans such as 'my job is to make myself redundant' and 'I want to create self-organising teams', and then they do the exact opposite. I’m not sure who coined the term 'story drones', but it neatly portrays what is so common on large projects with all the trimmings of project managers, business analysts, iteration managers, architects, and then finally the developers.

In the morning a soul-crushed developer will be paired up with another - perhaps using 'pair stairs' - then will be given a story of 2-3 velocity points worth, will have a 'story huddle' with all the senior project cast, will have a coffee to take a breath, will open the JIRA ticket and read the acceptance criteria, will have another huddle to correct the assumptions made in the first huddle, will correct the JIRA ticket, will go to lunch, will get another coffee, will glance at the build monitors, then will finally start engaging in 'ping pong' TDD, where one person writes the unit-test, and the other makes the test pass. Later, a solo developer will refactor most of it.

What’s the solution? We could start by giving up on the dream of developers all being equal in ability, who can then be traded as commodities. Developers have different strengths - some are fantastic systems thinkers, some are drawn towards architecture, and others possess a laser focus on delivery. Some are better at communicating, whilst some just want to think deeply about the problem and to ponder every edge case.

If developers are recognised as individuals and emboldened with trust and freedom, then they will play to their strengths to give an overall multiplying effect. We can embrace individualism rather than chasing it away, by celebrating and raising up the role of the software developer.

I want my boffins and techies to be seen as surgeons. They know what they’re doing and you’re in safe hands. We’ve got junior doctors in there also to learn, but the junior doesn’t become the senior overnight. When we’ve got top surgeons the results will speak for themselves, and the good news is that the top surgeons aren’t required in such large quantities. This can make everyone happy.

Published: 2018-11-09

Privacy policy

Our experiences of selling Clojure jon
by Jon Pither
Published: 2015-03-30
The case for adding ClojureScript to your project jon
by Jon Pither
Published: 2015-06-29
Software is a difficult business jon
by Jon Pither
Published: 2018-07-25