Some programmers are like carpenters and some are like architects, but most I know burn the candle at both ends - we like to think big and plan out all sorts of swell high level object manipulations and software interfaces but we also take pleasure in polishing off the corners on the indents and the idioms in the code itself.

But society doesn't like these things mixed. According to THE RULES (sorry, I lost the URL for the rule book) the specifics should be left to the low level drones. Higher level managers should only concern themselves with the big picture. This means that programmers get treated like craftsmen regardless of their skill level and managers ignore the programmer's planning advice as too specifics-oriented to be real planning.

I'm not sure I follow your analogy.

Craftsmen build things? Non-craftsmen don't build things? Craftsmen don't plan? Architects aren't good at specifics?

What if you hired a painter to design your housing development? Would he be as bad at it as your carpenter might be because a painter is a craftsman? Can an architect not be a craftsman?

Let me be specific: I believe that the source code is the design. Compiling is the manufacturing. Engineering is, what, measuring the tensile strength of a stable quicksort algorithm?

Yes craftsmen design things, but the nature of what they design is different from what engineers design. A carpenter is expected to be good at designing and creating objects like cabinets and doors, using primarily the single material of wood and a few screws. If the carpenter is also good at designing and creating complex multi-object, multi-material things like houses and housing developments, that's cool, but it's not something we'd assume from knowing they are a carpenter. Some architects can build cabinets, but that doesn't neccessarily relate to whether they are good architects or not.

A webmaster who has become proficient at CGI scripts to do simple tasks might also be able to design an enterprise-wide software strategy, but it's not something we'd assume from knowing they are a webmaster. Most of us here at the Monastery can take potshots at particular bits of how PM works, but it's gods like you who have the whole picture.

An engineer is someone who understands how a complex group of things built from a diverse set of materials work in conjunction with each other and who is capable of designing and planning a system that will safely perform the functions it needs to. I'd say some programmers could be described the same way.

Let me be specific: I believe that the source code is the design. Compiling is the manufacturing. Engineering is, what, measuring the tensile strength of a stable quicksort algorithm?

I think it is a serious mistake to equate code with design. Granted, an agile methodology intermixes design and coding in an iterative and mutually informing process, and the final code (and documentation) may be the only tangible artifact produced, but that still does not mean the code *is* the design.

As for engineering, yes there certainly is engineering in software development, running the gamut from the ad-hoc or experiential engineering that any builder / tinker / craftsman etc might display, to algorithm analysis, to the design of language features that increase assertions of correctness (within particular domains of correctness).

I think this is what I was getting at. I get the sense that the different types, maybe they can even be called factions, of programmer are slowly diverging. I'm not a historian, but I have an inkling that this mirrors similar trends in any newly emerging industry.

There is a difference, though, that it seems chromatic has been trying to articulate: software plays by different rules, because it is not tangible. It's generally not practical for the person drawing the designs for a housing tract to actually build the houses, but with software, the code is the design. The design and the implementation are essentially the same thing. Sure, people have come up with many methods of planning and designing software before the code is put in place, but at this stage in the game the code is the blue print. The planning and design that goes on in the software world is very general and high level. The true design, in the real sense of the word, is in the code.

I think this might change in the future, as we keep going higher and higher level, but even then it won't be the same as with physical production. The intangible nature of programming just makes it different. Perhaps I am undermining my own analogy here, but I think, in the software world, engineers and crafstmen can be one in the same.

I think there is definately an engineering component to programming. Engineering is essentially applied science. So a software engineer is a programmer who is extremely knowledgable of the science of programming, yet has considerable knowledge of the practical side. Personally Id put a programmer who designs CPU micro-code in the engineering side. As I would probably put many embedded programmers and OS programmers. They may be craftsmen as well, but i suspect that on the whole there are broadly identifiable skills and training that are not generally shared with other types of programmers.

But of course all of these definitions and concepts are misleading. IMO this is one of those situations where Kuhn got it right. Software engineers are those people doing things that software engineers consider to be software engineering. Coputer scientists are thos pople doing things that other computer scientists consider to be computer science. And the rest of us, well we are as the OP says, probably best described as crafts people. Not quite engineers, not quite artisans, not quite scientists, but a happy amalgamation of the whole lot.