Programmer vs Developer

There's been some debate about the difference between programmers and developers, it's even been the topic of a question on Stack Overflow. Over the last few years, I've lived on both sides of the fence and I think understanding the differences between programmers and developers might help us find the working environment that's right for us. So, for the record here's my opinion based on my experience writing applications in the UK.

In a large company, with a lot of development resource, you might find dev teams that include junior & senior programmers, technical leads, a QA, and overseeing them, an architect, a PM and perhaps a scrum master. In my experience, the job of the programmers is to take a ticket, cut the code, run unit tests & check in the source, resolving any merge conflicts on the way. I've worked in teams like this and in a lot of ways it's very cool. I sat down in the morning, tore through some tickets and two things happened as a result. Firstly, perhaps obviously, it was very satisfying to see all those tickets in the QA column come the end of the day. Secondly, because I was just writing code, that's what I talked to my fellow programmers about and as a result, my programming chi increased by the day.

In contrast, in a small company, you rarely find someone who writes code all day. Often the developers job includes talking to the users, agreeing a spec, writing and testing the code, deploying the solution, discussing the infrastructure and most importantly choosing the development methodology. Quite often developers are working on their own or in a team of two, so if they want to work to a waterfall type delivery, they can. There are no procedures saying that it must be Agile, or lean, or TDD, mostly because if there are even any written procedures, they were written by the developer in the first place. In many ways this suits the needs of the small company, because someone who can do a bit of everything, is more likely to do whatever it takes. However, it makes you a generalist who's target is the development of a system, rather than a deeply technical guru. Developers tend to study just the pieces that they need to, rather than memorise entire namespaces.

It's important to recognise which situation best describes you, because a senior programmer who's used to a highly focused role might take some time to adapt to life inside a small company. Likewise, developers might struggle technically if they find themselves in a large, organised development team.

Fate, and positions in a string of small companies has led me down the developer path. Sure, there are lots of programmers out there with deeper technical knowledge than me. Guys that can explain in detail the first few milliseconds of an http request. But over time I've been part of small (max 4 person) teams that have delivered platforms flexible and robust enough to be entering their second decade of service. They didn't use IOC containers, ORM or MVC, so some might scorn, but, much like the arguments about c# vs VB, or java vs .net, I think what you ship is more important than what it's written in.

From small acorns...

I've had this blog registered for a while now, and I've finally got around to dropping some content. What's JABOC all about? It was a phrase that I coined with a few colleagues back in the early years of .net. Basically it tries to express that the hardest part of development is the requirements gathering / spec interpretation / clients moving goalposts etc. Once you know the architecture, and the form / function of the application, the rest (the easy bit) is just a bit of code. As a developer it's what we're supposed to be good at.

What's the blog going to be about? I'm a web developer, and I mostly use microsoft technology, so there's going to be a lot of that, and some other gadget / geek / tech stuff, as and when.

I've been lucky enough to work with some really good devs recently, in a scrum environment, and hopefully some of their focus on productivity has rubbed off. It was inspiring stuff.