This year my IT career is coming of age. In the year 2000, when URLs were still awkwardly pronounced double-you-double-you-double-you-dot, I quit an uneventful tech support job in Edinburgh to code in Perl and DHTML, cursing the incompatibilities between IE and Netscape. But I never regretted the career change. Eighteen years have passed and I’m happier and fitter then I was at age thirty, believe it or not. I thought it would be a fun experiment to rank all major projects and companies I worked with over the years in terms of overall satisfaction (without too much regard to pay or perks). You can make such a list intuitively, but I wanted to formulate the criteria which in my experience make a software project enjoyable and then give marks for each.

So I came up with the following four criteria, from most to least important.

Healthy team dynamics

There is nothing more important than a healthy team atmosphere if you want to build anything, and software is no exception. You need mutual acceptance of each other’s qualities without envy and respect for each other’s shortcomings without disdain. You must be able to assume that everybody in the team is sufficiently skilled and dedicated. Once these values are implicitly felt it is much easier to offer constructive criticism, preferably done with humour.
I have narrowed down the team to you daily work mates, including any non-tech people, management or possibly clients. There are of course more people to contend with:

Organisational support

Teams do not exist in a vacuum. There is upper management and corporate politics to deal with. There are client and other stakeholders, who can’t and shouldn’t be ignored, as they pay your wages. These are the ones you don’t see on a daily basis but still heavily impact the smooth running of the project.

How much do I care for what we’re making?

Don’t get me wrong: I always care about doing the best possible job, but I’d be lying if I claimed that all projects matter equally. Sometimes there’s a lot at stake. I have worked in projects where late delivery would have bankrupted the company, or a few hours of downtime would have cost many thousands in euros, not to mention embarrassment. Let’s call this the negative incentive to care, but you can also have a natural affinity with the industry or the end product which works as an extra incentive.

Code, architecture and tool stack

I deliberately put this last. While I’m a firm believer in clean code, testing and all the other good habits of healthy development, I have also come to the conclusion that people always matter more than tools. That’s why I find most programmer job adds uninformative and uninviting. “Join us and you can work with <INSERT FRAMEWORK>”. I want to know who I’ll be working with rather than what I’ll be working with. I care little for the rockstar attitude. No random group of rockstars is guaranteed to form a great band. Au contraire!

So without further ado, here’s my top fourteen, carefully anonymised. Note that the projects with the really cool tech don’t even make it into the top six. It wasn’t the tech that created the team atmosphere for me.

This little exercise has taught me that successful software development is way more than programming skills or tool knowledge. I’ll always prefer obsolete tech with great people over hacking Kotlin with jerks.
(Just kidding: there’s only cool people doing Kotlin)