Both. Neither. Either-or. Both of these terms aren't just titles. They carry connotation and history. When we pick a side on "craft vs engineering", we're also picking a philosophy of software development. We're picking a social context. Let's talk about what those are! https://twitter.com/davefarley77/status/1280897179809247232

So Software Engineering came first, from Margaret Hamilton's work at NASA in the 1960s. It was a term to legitimize software development (at the time "women's work"), which was seen as less important than hardware engineering (where all the men were). https://www.nasa.gov/pdf/251093main_The_NASA_Heritage_Of_Creativity.pdf

No reasonable person today would disagree that Hamilton was an engineer. But can we devs still call ourselves engineers? "Engineering" brings up a lot of images. Bridges. Airplanes. Rigor. Math. Licensing. Serious Business. Compared to that, software doesn't seem to hold up!

One problem: these images are what we IMAGINE engineering to be. Most developers have never worked as a "traditional" engineer and don't know what it's ACTUALLY like. We're comparing the idealism of the engineer-image against the messiness our software-reality.

Last summer I interviewed 17 "crossovers", people who switched from trad engineering to software. Through them I discovered that traditional engineering is just as messy, ad-hoc, and chaotic as software is. We're not all that different.

(I'm writing a full series of essays, too, but keep getting distracted. So I made a Toxx clause: if I don't have a first draft by end of September, I'm giving 1k USD to a random newsletter subscriber.

So, uh, sign up if you want to maybe win money!) https://buttondown.email/hillelwayne/ 

The "engineering" stereotype has a dark side, too: it calls to mind stodginess, bureaucracy, inhumanity. The "craftsmanship" movement is a rejection of that, an attempt to center the individual and make software artisan. The main proponent of this is Pete McBreen.

(Quick aside: a lot of the current objection to "craftsman" is that it's gendered and exclusionary. I agree with this critique, but 'software craftsman' is the term the _movement_ historically used, so I'll refer to it by that name for now.)

McBreen wrote about this in his book "Software Craftsmanship" ( http://www.mcbreen.ab.ca/SoftwareCraftsmanship/), specifically in contrast to "software engineering". While I have an ACM Safari subscription I can't use it due to a 3 month cutoff thing, so what follows is from secondary sources.

He compared craftmanship to small teams of expert programmers versus large projects of average programmers. Craft meant artistry, intuition, hands-on experience over theory and rigor. This tied into the growing Agile movement, and many Agilists also called themselves craftsmen.

The big popularizer was Robert Martin in a 2008 keynote, which lead to a "Craftsmanship Manifesto" a year later. ( https://8thlight.com/blog/paul-pagel/2009/03/11/history-of-the-software-craftsmanship-manifesto.html). This leads to a problem people have with the movement: it's tied too much to Martin's theory of software development.

People hear "Software Craftsman" and assume it includes things like pair programming, Clean Code, TDD, and general disdain for rigor. It doesn't help that Martin is himself a notorious figure and has mocked people concerned with the gendering of "craftsman".

(Disclosure: I hate the man, too, and think he gives bad advice that makes people worse programmers.)

The other problem with putting "craftsman" and "engineering" in conflict is more essential and ties back to the "theory" vs "reality" thing I mentioned earlier.

As with before, nobody in the craftsman movement has worked experience as a trad engineer. When they talk about why craft is more accurate to software than engineering, they're using a stereotype of engineering.

...But they're also using a stereotype of "crafting"!

McBreen was _always_ a professional programmer. Same with Martin, same with most of the other people I checked. We're comparing a stereotype of engineering to a stereotype of crafting!

Now I've not done either, but I *suspect* the two have more in common than people think.

Engineering has a lot of qualities of crafting, and crafting has a lot of qualities of engineering. Software's like both. Software's like neither. Pigeonholing is using metaphors as categories to _rationalize_ software instead of as lenses to _understand_ it.

Can software be rigorous? Of course it can. Can software be creative? Of course it can. Can something be both rigorous and creative at the same time? Of course it can!

In conclusion, we should all call ourselves Code Clowns.