Developer or Programmer? Why it matters.

By: Seattle Municipal ArchivesCC BY 2.0

For nearly 25 years, I have been writing some form of software code or another. For nearly twenty of those years I was paid to do it. When I started I was called a ‘programmer’. I don’t know exactly when everyone – including myself – started using the term ‘developer’ as a synonym for ‘programmer’, I do remember spending all 12+ years as a Java programmer being called a Java developer. But really I still just programmed – this time in Java.

Then along comes all these fancy shmancy process frameworks that talk of teams. One in particular – Scrum – boldly calls out the ‘development team’ as a cross-functional group who deliver an increment of a product at regular iterations.

Now as I help teams and organisations be more effective by applying Scrum (amongst other things), I am often asked who is in the Scrum development team. Typically I say:

Developers, testers and everyone who can carry out the required functions needed to sustainably deliver a working product increment

Often this response gets some push-back along with a sense a alienation – “But I’m a QA, I’m not a developer – am I in the development team?” or “I’m an Interaction Designer, am I in the development team?”.

My revelation

These questions left me puzzled and during one of my thinking sessions it dawned on me that:

Yes, all those people are in the development team and they are all expected to be developers. The problem is not them. The cause of the confusion is not their function, it is the hijacking of the term ‘developer’ and making it mean the same as ‘programmer’.

Being developer is not a function, it is an attitude.

Programmer, tester, UX, cryptologist, devops, CM engineer and other similar things are specialist functions. You can have a group full of these in your ‘cross functional team’ without them being a development team. Likewise, you can have them all in a group and they can simultaneously be developers with certain functional expertise.

About programmers

Programmers like to program. Actually let me rephrase that. Programmers love to program. It is our passion. We love to play with code for no other reason that it makes us happy and it fuels our curiosity.

In programming, we push the boundaries of our knowledge, gain skills and explore a world where we make things – sometimes pretty cool things – happen. Programmers are curious people – not about everything – but certainly about how computers tick and how we can make them tick differently. I say again – it is our passion. The thing that makes our eyes light up in an otherwise uninteresting conversation.

As a programmer, I don’t really care whether what I wrote is marketable or whether it is usable by anyone but me. Even broken code is interesting to a programmer and as for tests – screw them – I know how this sucker is put together and where it breaks and how to avoid it. Also, I don’t care if it solves anyone’s problem other than mine – even if my problem was “I was bored”.

Programmers are not lone wolves or billy-no-mates. We have friends, not many and typically they are other programmers. Programmers are collaborative even if sometimes a little competitive.  Our focus is inherently narrow, oh but what focus. We think deeply about the problem and delight in reaching a state of elegance and great technical design that makes our every future move in the code sublime.

Now, please don’t misunderstand me. Programmers are vitally important. The World is deeply computerised and will continue to be. It needs people who are curious about computers and passionate about making them do things. The World also needs at least some of those programmers to apply their skill to developing solutions for the challenges that face us all.

Expanding this further, let me say that functional specialists are vitally important. That is where expertise is created and boundaries of the possible are pushed out further and further. Functional specialists are driven by the curiosity and fulfillment that their specialisation provides.

There is no shame in wanting to remain only a programmer or any functional specialist. Personally I would be delighted to simply code stuff in my study all day and all night and never attend a single meeting about any damn thing. In fact I would like to not talk to anyone and have no one talk to me. My brain gets shafted with all the things I have to hold in it as a developer AND as a programmer and I would be quite content not having my brain shafted. Luckily the stuff I know as a programmer is pretty much instinctive now, but nevertheless, being a developer is still hard work.

Whilst there is no shame in choosing to be only a programmer, there is pain and suffering in privately and silently choosing that but publicly being expected to be a developer. Choose who to be and be who you choose.

About developers

If programmers are focused intently on a narrow and often technical problem, developers focus on much broader and often business-centric problems. The broader problem that developers are challenged with may need nothing to be programmed nor tested or designed. They care that the solution meets the need. They care that it is usable and valuable and they seek feedback to those ends.

There is always a big picture and developers make time and head space to understand it and be part of evolving and delivering it.
Developers seek feedback and are prepared to do whatever is needed to get to it. Developers seek collaboration with other developers because they realise it takes more than their specialisation to deliver a solution. This collaboration takes behaviors often missing in certain functions and developers seek to gain those behaviors so that they can collaborate better.

Critically developers recognise that the most functionally correct thing is not the same as the most effective solution. They know when enough is good enough.

In my line of work, I come across many functional specialists who complain they often do not have enough to do during an iteration. They often say this when there is an abundance of work to be done to deliver the solution. They argue that it is inefficient or ‘poor resource utilization’ for a programmer to test or get involved with elaborating requirements. A developer contributes in whatever way they can to develop the solution.

Re-defining the development Team

A development team contains developers. A cross functional development team contains developers who together are able to perform all the functions required to deliver the solution.

A developer is, almost always, also a functional specialist. That is they have the attitude and have deep skills in one or more functions.

A development team is fundamentally a learning vehicle. Its members recognise that in order for each person to consistently and effectively contribute to the solution that they must they learn from each other. They know that sometimes the nature of the work needs different measures of the functions and they adopt behaviors – like pairing – to create that learning towards helping each developer contribute as much as they can. So programmers learn to test and design and do configuration management – at least a little. Testers learn to code and design and manage configuration. At least enough to be useful.

Why I wrote this

I wrote this post because it I consider it to be cruel to expect people to be what they don’t want to be and worse still, to penalise them when they do not meet those expectations. This cruelty saddens me deeply.

I wrote this because I witness the violence that is done in the name of delivering software and I have unwittingly been part of that violence. From the sense of exclusion encouraged by functional silos to the treating of certain functions as second class citizens, peoples’ feelings are marginalised and their needs ignored.

I wrote this because I sincerely want organisations and specifically their management to understand the distinction between the attitude and the function. I want them to act more humanely when they hire and when they reward. I want them to explore more non-violent ways to design an environment that encourages developers AND functional excellence.

I wrote this because I want programmers to understand what is expected of a ‘developer’ and to make an informed decision whether they want that. I want them to make that choice without coercion.

If they choose to be a developer, they accept that they may be called upon to do things not in their expertise and they do so happily. I want them to fully realise that their choice means they are interested both in the joy of programming as well as the satisfaction of developing something that makes a difference.

Finally, I wrote this so that the word ‘programmer’ is no longer considered synonymous with ‘developer’. I believe that, by breaking this defacto equivalence, programmers will be happier people and simultaneously other functional specialists will feel equal and included partners in delivering a solution that meets a need.

What do you think?

If you are a developer, do you recognise that it is an attitude and not a function? If not, why not?
Do you disagree with the distinction between developer and programmer? I’d love to know why you think they are not different.
What are your experiences of one being confused with the other?

I’d love you to drop me a comment below or let’s chat it out on Twitter.

11 Replies to “Developer or Programmer? Why it matters.”

  1. Interesting article, thanks for sharing your opinion. I think I can see the distinction you’re making between the two figures, my question would be: why a programmer shouldn’t feel the needing of being a developer? I mean, unless you do programming just for fun, a programmer (as a professional) always works for a product (even if open source or simply not for a business) so the reach of the perfect code is useless if you’re not trying to make the best for your product. Of course sometimes you need to improve your programming skills, studying and trying to make your code better. In a few words, to be a good developer you need to be a good programmer. But a good programmer who doesn’t aim to be a good developer will end up being concerned only about code, which is not useful if you’re not thinking what’s best for your product.

    1. Hi Luca – thanks for a reading and for a good question – which I think you actually answered yourself 😉

      You might be surprised that there are good programmers out there who suck at being good developers. They are in teams and are paid too. Sometimes they might be the ace hot programmer with zero collaboration skills but whose every word is worshiped. Sometimes every one else has to endure abuse so that such geniuses are accommodated. I have seen this happen.

      Like I say, being a developer is a mindset. It doesn’t matter whether you are paid or called one or any other indicator. In fact I think that paying someone to be a developer is making things worse, especially if this distinction is not acknowledged and explored. Imagine a programmer who really does not want to be a developer now being offered money to be one. It’s like paying a vegan to eat steak and not acknowledging they are vegan.

      Also I have found cases where a programmer does want to be a developer and contribute to the solution, but the team and organisation are so process mad that they overburden the developer with stuff – meaningless meetings and reports and so much more that the noise puts them off. So they withdraw and disengage.

  2. I think it is a mistake to attach your definitions to the terms “programmer” and “[software] developer”. The words don’t have the meaning you attach to them and it is more confusing to re-purpose these terms when they are currently interchangeable.

    Other than this, I agree with a lot about what you say in terms of Agile teams, I just can’t agree with the terms being linked to these concepts at all.

    1. Hi Steve. Really appreciate your view on this and especially about the confusion that may result from re-purposing the terms. I agree they don’t currently mean the concepts I set out. It is my view that they didn’t mean the same thing starting out and by that, the popular meaning – though popular – is itself flawed.

      In the order of things I want to happen, separating those two words is last because I don’t believe simply calling them different things is going to make the situation any less violent. How people see themselves and others and the expectations in force is what I want to see addressed first. If that happens, I believe the terms will ‘naturally’ come to mean different things.

      Incidentally, I also believe this interchangeable use may be the reason why the Software Craftsmanship movement sought to differentiate itself. I do not see a distinction between a programmer and a software craftsperson. In my understanding they are driven by the same ideals of learning, passion and continuous improvement of skill and craft. But I still see a difference between both of those and ‘developer’ as I explain in the post.

      Thanks for helping me be clearer too.

  3. Hi Mike (we met at Agile in Chicago in October 2009),
    As a multi medium artist employed by the patterns’ community in USA and Europe, I loved your use of the Amish image as header. I was intrigued as to how you incorporated that architecture / building collaboration so I scan-read your post to see how you referred to it. I could not spot it ! Maybe my scanner was out of alignment ! I am always looking for visual (or other) metaphors to describe complex ‘patterns’ systems so please help me out with your use of that fantastic image. (Maybe the only downside to the image is that it is all Caucasian guys !)
    George Platts (Bristol UK) Tangential Thinking Co-ordinator (PLoP) / Querdenker Koordinator (EuroPLoP).

    1. Hi George,

      I definitely remember you! Your facilitation of the Human Rain Storm is still absolutely pitch perfect in my mind.

      So I rarely make reference to the images on the blog in the text – so your scanner is perfect! What I intend on is that my posts are seeds that cause people to think over time. Some of the feedback I have recieved seems to validate this intent is fairly successful.

      So let me ask you this – what do you see when you look at the picture? Do you see programmers or do you see developers?

      (I did try to find one that was more racially diverse – it’s not really the Amish way!).

      And actually there are no women in the construction either – which is all a rather Amish thing. That is not to say women do not contribute – actually *everyone* is expected to contribute in whatever way they can. In Amish life the women would keep the refreshments flowing and the big community feed at the end.

      1. Whilst reading the original post, I thoroughly read the section headed “Re-defining the development Team” to see how this related to the image. My only knowledge of the Amish is the movie “Witness” where the day long barn building section, with the whole community contributing, is most impressive. What I most enjoy about your response to us, Mike, is how you fold our response back on itself, asking us to think deeper.

        1. Hi George. So what drew me to the image was that inasmuch as all the people on the structure were very similar, they were each distinct. Being in a development team is about an attitude that recognizes uniformity of purpose but encourages individuality of function. You might think that everyone on the structure is qualified carpenter – that would not be accurate.The more skilled carpenters would separately have made up elements of the structure before hand and on the ‘raising’ day, the entire community – the team – would gather and every one contribute to get it raised.

          So back to my question – Do you see developers or programmers? I actually see both. The programmers may be the experienced ‘functional’ experts – carpenters, painters and other craftsmen – even the inexperienced at these functions. At the same time they are also developers, collaborating with each other on the development of the barn and continuous strengthening of their community through the shared experience of co-raising it.

  4. I’m a software developer, and a programmer, and a coder, a hacker, a software engineer, and a software architect. I’m a project manager, a tester, and a software manager.

    I understand the distinction you’re making, and I’ve seen these kinds of arguments before, but I think that the particular label you choose to apply to the separate concepts is arbitrary, and that it’s semantics to a lot of people.

    I think you’re talking about two different styles or types of developer (or coder… etc) and that’s the real crux of the issue. It’s an interesting discussion.

    1. Hi Alastair and thanks for reading and taking the time to comment.

      I think the trouble is precisely what you identified – semantics. If ‘developer’ and ‘programmer’ mean the same thing then the expectations that they infer must also be the same. In my experience this is plainly not so.

      So they are different styles – but not of the same thing. In many ways that point is moot because the emphasis is on the behavior one wants to see. Collaboration, awareness of the big picture etc. Regardless of whether the person is called a ‘developer’ or a ‘programmer’.

      It is interesting 😉

      An umbrella creates the expectation that it would prevent one from getting too drenched by the rain, but then a folded newspaper is not an umbrella even as one might try to make it function as such.

  5. Hi Mike. Thanks for sharing your thoughts. At the very least I find it thought provoking. I probably fit in to your description of the developer. And I’m happy about that!

Share that thought!