During my day job I get to work with many fantastic developers and help bring their codebases into an effective means of source control, to build their code and help package it sensibly and deploy it in reliable and repeatable ways. The point of this exercise is to bring control to situations that otherwise could get very much more complex. If you want to build reliable software and systems it’s always a good idea to be work in a controlled and orderly environment. A lot of developers are very good at this realising this themselves and don’t really need any help but yet most prefer, and in fact thrive, when they can work within a delivery framework of some kind – and by that I mean a set of tools and way of working that is meant to help the code find its way to the user. Even the most keen developers often don’t really want to build and package stuff themselves most of the time let alone be responsible for rolling it out and supporting multiple environments. This is where build and config people come – we can build it, configure it and set up those sacred pillars of our modern IT world – Continuous Integration, Continuous Delivery and DevOps.
My work brings me into contact with a range of different skills – system admins, network people, software developers, project managers, testers by the bucketload, DBAs, architects – you name it – everyone. Although this is a function of my role, it’s also a function of my interest. I like that software based organisations or delivery departments can be messy and complicated places and that it takes a lot of orchestrated effort from many different people to get success. This is my challenge and I relish it – it’s a niche job, you get to work with clever people and deliver complex stuff and then have to demonstrate it repeatedly.
Despite my general enjoyment of the many wonderful experiences I have had working with teams from all sorts and sizes of organisations – I still have moments where I am completely lost for words. And that happened to me just today as I was talking with someone at the water cooler about the various benefits of various source control systems – distributed vs centralised, Git vs A.N.Other. If you have ever been a professional software developer you will have probably heard passionate debates in favour or against certain version control systems. I learned to ignore then after a few years as a developer as you will hear the same arguments coming up time and time again – RCS blends into SCCS, CVS, SVN, Clearcase, Perforce, Git, Mercurial. They all have strengths and weaknesses, plusses and minuses but it’s one of those developers hobby horses alongside debates about which editors suck the most. It’s one of those long standing discussions for which there is no right answer and so, for the most part, I tend to stay neutral. I know that opinions vary and developers can be passionate creatures.
And so today I carelessly made the point to one developer that I didn’t really mind what source control system he uses because my concern is for the delivery of the software. Apparently this was the wrong answer because for my troubles received a tirade of the strangest language in return apparently for not actually having any preference or emotion about the subject at hand. That, for me, was a first. I’ve had plenty of run-ins with developers during my time but never over a lack of opinion.
Developers can suffer from some social awkwardness – they can be unable to express themselves socially in the ways that others feel comfortable with. I realise this, I’ve done it myself and I always take this into account but companies like the one I currently work in are very much more organisationally sophisticated than they were ten or twenty years ago. Staff are asked to treat one another with respect – to listen, to answer thoughtfully, to take emotion out of the discussion. Long ago, back in my first job in the mid 90s, I would regularly witness people hectoring others based purely on their experience or perceived seniority in a role. In this job I once took a senior engineer to task for having left the ‘default’ catch all off a C switch statement in a piece of core library code. He didn’t like that at all and tried to pull the ‘Do you know how I am?’ card – to which I replied that I’m terribly sorry but I didn’t, I had just pulled his name out of the version control system. I stood my ground and a week or two later I received an email from him saying that I was right, he had been wrong and he shouldn’t have taken that aggressive stance and he was re-evaluating his work and his attitude to work. Whether or not I believed this is another matter entirely but in a work context it’s good to (even eventually) gain a perspective on one’s opinion. It’s not that important – take the ego out of it.
But, at the same time, this homogenising of response – this smartening up of our attitudes and showing proper respect to one another in a work context – does it mean that we lose the essential combative nature of discovery and invention? Should we keep true to our reactions in order to make great leaps forward?
Computer science is after all, not a science and it’s not really about computers. It’s about writing inflexible segments of instructions and somehow breathing life into them – it’s about creation and engineering all rolled into one.
Sometimes it is good to be challenged, and it’s great that people are passionate about things but isn’t this kind of behaviour exactly what puts people off working in IT?
And so this is the point – it is work – it is not (usually) a life or death situation. It may seem important to you but even in the relatively small scale of things that you are operating on – it doesn’t matter. So why can’t we leave it, why do we feel we must have an opinion? And more importantly why do we feel we need to have an opinion right now?
So – be a dick or not? That is the question.