"Developers" AND "Programmers"

A recent (uncredited) article on Hacknot discusses the terms Programmer and Developer.

A modern programmer loves cutting code - and only cutting code. They delight in code the way a writer delights in text. Programmers see their sole function in an organization as being the production of code, and view any task that doesn't involve having their hands on the keyboard as an unwanted distraction.

Developers like to code as well, but they see it as being only a part of their job function. They focus more on delivering value than delivering program text, and know that they can't create value without having an awareness of the business context into which they will deploy their application, and the organizational factors that impact upon its success once delivered.

Ok, so far I am with this (mystery) author.

I look at these two roles and I can think of many examples of people I have worked with who fit into one of these molds, or somewhere along the spectrum in between.

Is there anything wrong with either of these two roles?

Well, read the article further, and you'll see considerable derision directed at the "modern programmer". There are several examples before these...

...programmers would be the hares, and developers the tortoises. Programmers, prone to an over-confidence resulting from excessive faith in technology's ability to save the day, will find themselves facing impending deadlines with work still to go that was meant to be made "easy" by that technology, but was unexpectedly time-consuming. Not surprisingly, the technology doesn't ameliorate the impact of too little forethought and planning...

Programmers often view their user base with disdain or even outright contempt, as if they are the ignorant hordes to whose low technical literacy they must pander. They refer to them as "lusers", and laugh at their relative inexperience with computing technology. Their attitude is one of "What a shame we have to waste our elite programming skills solving your petty problems" and "You'll take whatever I give you and be thankful for it." Programmers delight in throwing technical jargon at the user base, knowing that it won't be understood, because it enables them to feel superior.

...Programmers tend to rush headlong into tasks, spending little time considering boundary conditions, low-level details, integration issues and so on. They are keen to get typing as soon as possible, and convince themselves that the details can be sorted out later on.

So, according to my interpretation of this article, what differentiates the developer from the programmer the ability to communicate with the business/client/user, professionalism in coding practices, and some sort of social maturity.

Is there nothing good about being a programmer?

My dad owned a construction business for 35 years. His workforce varied over the years from a dozen or more hired men to just a couple. He built mostly residential homes and some farm and commercial buildings in a small rural Prairie town. There was usually one or two other small construction businesses in town that was his competition. He basically ignored them and focussed on producing high-quality work for a reasonable price. He didn't care about the volume of business he did, so long as he could pay the bills and raise his family. One of many things I learned from him was that the quality of work was directly related to the attitude of the worker towards the work, and not necessarily the attitude of the worker towards the client. Some of his workers could relate well to the customer, others didn't do so well that way. The ones that didn't communicate so well, it was important that they kept busy and kept their mouth shut when the customer was around. But many of them could produce really excellent results - fine finish carpentry takes skill and care, for example, that not everyone has. Other workers could talk and joke with the customer and yet not be the best person to build the kitchen cabinets. In the end, there wasn't really any particular correspondence between those roles. Some could do both, some could do one better than the other. It didn't really matter. There was room on the crew for anyone who cared about their workmanship.

What's good about a being a "modern programmer", to me?

Deep understanding of a technology

I would say a programmer has a deep and broad understanding of one or more particular languages or frameworks. In the .NET world, that would be someone who has a great understanding of lots of the .NET Framework, and probably has gone deep with some areas of it that aren't necessarily mainstream, like System.Security.Cryptography, or System.Reflection. As a result, they understand how best to use the language or framework to get the results they want. In other words, they "embrace the technology" and can code something the "C#-way" (or the TSQL-way or the whatever-way).

A developer doesn't always have the time nor interest to go deep with a particular technology, or perhaps what they knew deeply has now moved on (like, they were really productive in Visual Basic 5, but haven't kept up and aren't intimately familiar VB.NET for example). So, hand a coding task off to a "developer" familiar with VB5, and ask them to produce code in VB.NET, that code will probably work, and look remarkably like VB5 code. And probably not take much advantage of the VB.NET language features nor the .NET Framework.

Forward-looking

A developer, according to the article, has "a much more cautious approach to new technology" than a programmer. A healthy dose of salt is required when looking at new technologies, of course, and I think mature programmers understand that as well. However, if programmers are more interested in new technologies than developers, are there benefits to that? I think so - one being the ability to see what is coming on the horizon and be ready for that wave when it arrives. If a programmer sees a particular feature in a new technology that could solve a problem, then they may be able to see how they could be ready to take advantage of that when (and if) the new technology can be adopted.

Elegant Abstractions

I am convinced that one person's abstraction is another person's voodoo. Some people are hugely productive with EMACS and VI, not me. As I have been teaching .NET languages over the past few years, I see that some people can understand abstractions in object oriented languages, others find it more difficult, or just not natural. Some students ask me, "do I have to use inheritance in .NET?" and the answer is "yes and no". Really, you ARE using inheritance whenever you build a Windows Form or an ASP.NET page or an XML web service. But you don't have to create a large (deep and wide) class hierarchy to code your requirements. However, often a well designed and implemented class hierarchy can introduce layers of abstractions that are truly elegant and flexible and simplify the code, but might be daunting to the maintenance programmer.

When I first heard about Generics in the .NET Framework 2.0, I thought they would be interesting to use for strongly-typed collections, but beyond that they wouldn't be of much use to me. Now that I have used them more, I have seen more patterns of classes that can be elegantly implemented using generics, and they're not just collections. In the project I last worked on, we based all our interactions between the .NET world and the Biztalk world on message classes (schemas) that were implemented using generic base classes.  It's an elegant and surprisingly simple thing now, to create a new message class to converse with a Biztalk orchestration, and by using the generic features, we enforce a corporate standard in the message schemas easily. The point is, until I had a deeper understanding of how generics are implemented in the .NET Framework 2.0, I didn't understand how to use the abstractions they provide.

I'm not going to say here that Programmers understand abstractions better than Developers. If Developers are "closer" to the business/customer/user than Programmers, then I would say that Developers would better understand the abstractions of the business domain while Programmers might better understand the abstractions of the technical domain. It's just different viewpoints in my opinion. Both views are important.

I probably differentiate Programmers from Developers differently than the author of this article. But I value both of them on a team. If there's someone that can easily talk to the customer and come to understand their needs and pains, I want them on my team. If there's another person who I would never put in front of the customer, who only eats flat food, and who creates vast amounts of great code in a short period of time, I want them on my team too.