Epistemic status: I am thinking through a possible position out loud. While I believe the argument I am making in this post, I am not totally convinced by it. I am aware of a number of counter-arguments that I do not touch on here.

There’s a rather annoying attitude that often comes up: Software Developers are special and you should treat them differently from everyone else when designing how your organisation works.

I don’t think this is true. Software development is knowledge work with a fairly logical (though less logical than we like to pretend) basis, and most of the specific features of it as a profession just emerge out of that.

But I am starting to think it might be useful.

There is a category of argument I have often encountered in negotiation (not at all coincidentally, usually right before I turned down a job offer or shortly before I left a company). I call it the “We can’t treat you fairly because then we’d have to treat other people fairly too” argument. e.g. I’ve seen this in requests for flexible working (I like four day weeks a lot, and will in general happily take 80% of the salary for a 4 day week) where the response to the request is “But loads of people want that and if you had it they’d ask why they can’t have it too.”

My attitude to this in the past has always been “Well, why can’t they have it too?”

This is, of course, still my attitude, but I’ve come to accept that it will win the argument precisely 0% of the time.

The problem with accepting arguments of the form “Why should you get this treatment if everybody else does not?” is that they remove all possibility of incremental change. Even when everybody should get something, there’s probably no route to that that doesn’t pass through some people getting it and not others.

One example of where this comes up in a more explicitly developers vs non developers scenario is in responses to things like “Why you should not interrupt a programmer“. Every time this or similar is posted, a lot of my friends become angry and say “Programmers aren’t special! You shouldn’t interrupt anyone!”.

This is more or less true (there are large categories of jobs where it’s not only fine but desirable to interrupt them because that’s what their job is. But for basically all knowledge work and a whole bunch of adjacent jobs it’s true). You shouldn’t interrupt anyone.

But it’s a lot easier to win arguments about not interrupting programmers.

And, perhaps, it’s a lot easier to win arguments about not interrupting other people once you’ve established a norm that it’s not OK to interrupt programmers?

And this is why I think developer exceptionalism might be useful. Not because developers are exceptional, but because it is a place where we can put the thin end of the wedge.

A lot of how business is run is very dysfunctional, and exceptionalism gives us a convenient way of side stepping that.  If your business is very interrupt driven but you can establish a small island of uninterrupted calm around your programmers, maybe later the designers can come join you on the island? And maybe after that marketing can note that actually a lot of their work involves pretty intense thinking like that and they’d like to be uninterrupted at least some of the time and…

I can’t promise that it will work, but I’m pretty sure it won’t work without. Systems are quite stable without something to shake them up, and without some specific argument that you should be treated specially, you’ll be treated the same way as everyone else: Badly.

Exceptionalism and solidarity feel fundamentally at odds, and perhaps they are, but perhaps solidarity without the permission to occasionally engage in exceptionalism is just a crab bucket, and the best way to get everyone to where you want them to be is to let some people get ahead by whatever means necessary and then pull the others up behind them?

Of course, if this is going to work you have to actually pull people up behind you.

The correct progression is:

1. “You can’t have X”
2. “But developers are special!”
3. “OK fine developers can have X”
4. “You can’t have X”
5. “But the developers have X and it worked really well at improving Y which is also our problem”
6. (Developers chime in) “We can totally back that up. This is what we’ve seen out of X and it really does help with Y”
7. “Oh OK, you can have X too”

An incorrect progression would be:

1. “You can’t have X”
2. “But developers are special!”
3. “OK fine developers can have X”
4. “You can’t have X”
5. “But the developers have X and it worked really well at improving Y which is also our problem”
6. (Developers chime in) “No! X is only for developers! You are not a developer and thus are not special and cannot have X”
7. “You can’t have X”

If developer exceptionalism is to be a useful lie then we need to do two things:

1. Never forget that it is a useful lie and not actually the truth.
2. Have other peoples’ back when they try to follow our lead.

Otherwise it’s just developers being privileged jerks, which we have quite enough of already.