
Developer Manifesto – You Are an Artisan, Not an Engineer - sanderson1
https://content.nanobox.io/the-developer-manifesto/
======
dctoedt
This reminded me of something written by noted surgeon (and Rhodes Scholar and
MacArthur Fellow) Atul Gawande [0]:

<blockquote>

 _If medicine is a craft_ , then you focus on teaching obstetricians to
acquire a set of _artisanal skills_ —the Woods corkscrew maneuver … , the
Lovset maneuver …, the feel of a forceps for a baby whose head is too big. …
_You accept that things will not always work out in everyone’s hands_.

 _But if medicine is an industry_ , responsible for the safest possible
delivery of some four million babies a year in the United States alone, then a
new understanding is required. The focus shifts. _You seek reliability._

You begin to wonder whether forty-two thousand obstetricians in the Unites
[sic] States could really safely master all those techniques. You notice the
steady reports of terrible forceps injuries to babies and mothers, despite all
the training that clinicians received.

After Apgar, obstetricians decided they needed a simpler, more predictable way
to intervene when a laboring mother ran into trouble. They found it in the
Cesarean section.

</blockquote>

Atul Gawande, _Better: A Surgeon’s Notes on Performance_ , at 192 (Henry Holt
& Co. 2007) (emphasis and extra paragraphing added).

[0]
[https://en.wikipedia.org/wiki/Atul_Gawande](https://en.wikipedia.org/wiki/Atul_Gawande)

~~~
jMyles
That is one of the most subtly disturbing snippets I've ever read about the
state of the medical "system" in the USA.

~~~
luddypants
Can you elaborate on what you find disturbing? The implication of high failure
rate, or the shift of focus to reliability?

~~~
spraak
If I had wrote that, it would have been about how it led to the development of
the Cesarean section operation. In the US, and many other places, the
prevalence is much higher than the medical need. When there is no medical need
for a C-section, there really isn't any benefit over the risks to the mother
and child. Also--and this will probably sound quite hand-wavy or too woo-woo
for most of HN's demographic (I assume)--there is great emotional benefit from
a baby passing through the vagina.

~~~
falcolas
And once a mother has a c-section, most (all?) future births are via
c-sections as well.

There is a cost to the mother - major surgery - to the benefit of children.
Modern society considers this a worthwhile trade, but it would have meant the
death of the mother not even a century ago.

I have no real way to tie this back to programming; other than perhaps to note
that we're likely still in the dark ages of programming; the programming
equivalent of a cesarean section is likely still years away.

~~~
pas
Well, not really.

Look at HTTP, WebSockets, NodeJS, JS! Docker!

Churning out "apps" and delivering deliverables is the focus, not engineering.
Ticking off boxes for enterprise is more important than product feel and user
satisfaction. And so on.

And once you got hooked on docker and nodejs (with typescript and VS Code) why
would you go back to hacking perl scripts that invoke long forgotten binaries
written in the darkest C dialects, darker than void* itself, even if that damn
docker image is 600MB, the runtime memory cost is not much less, and it's
managed by kubernetes which needs gigabytes of RAM just to run an apiserver
and scheduler and a kubelet (node/server manager).

------
throwaway2016a
I was expecting an article focussing on how making software is not engineering
said to myself, "not this again."

But the article isn't arguing that, the article seems to be arguing we are
something more than engineers.

There is a subtle implication that engineers are hyper pragmatic and the only
thing that is important is that it works. My wife who is a biomedical engineer
and makes robots might disagree. In fact, I don't know many good engineers of
any kind that stop at "just working."

I think this artisan argument could also be applied to other types of
engineering as well.

However, the title is slightly off, it should probably be "You Are an Artisan,
Not JUST an Engineer" \--- the two aren't mutually exclusive and the author
even acknowledges that in the first paragraph.

~~~
jacquesm
> But the article isn't arguing that, the article seems to be arguing we are
> something more than engineers.

But we are _not even_ engineers, let alone more.

There are some people active in the production of software that would qualify
as engineers but that's a tiny fraction and they're not going to be found too
far from medical devices and aerospace.

~~~
tjr
Aerospace software engineer here. :-)

I feel perfectly content to deem my work as "engineering". I can understand
why someone quickly whipping up a small web application (which is not to imply
that _all_ web applications are quickly whipped up, nor that _all_ web
applications are small) might reasonably feel that their work is _not_
engineering.

So since I've also done quick little web applications, what do I think the
difference is?

The aerospace work includes precise operational requirements. It includes
formal verification tests which demonstrate that the requirements are met.
Code is reviewed; documents are reviewed; reviews are reviewed (not joking,
though typically only a sampling subset). Code is subject to formal coding
standards; code repositories are subject to formal standards; tools for
testing software are subject for formal standards (and
documented/reviewed/etc. in their own right). Software that goes onto aircraft
is tested in simulations; tested in limited on-ground hardware scenarios;
tested in extensive on-ground hardware scenarios; tested on board flying
aircraft. The entire process (and the following of process) is reviewed. The
end product is signed off on, and, for example, in the case of U.S. commercial
aerospace, certified by FAA representatives.

Sounds nothing at all like developing web applications!

Or does it?

A consumer-facing startup web application might have little or no
requirements. Testing may be ad hoc. Nothing is reviewed. Coding standards
don't exist. Does the software seem to do what is intended? Ship it!

But what about web applications for banking? I've never worked in banking, but
I suspect the requirements are fairly robust. (And if in fact they are not,
they easily could be.) I suspect that tests are comprehensives, traced back to
the requirements. (And if in fact they are not, they easily could be.) I
suspect that the software goes through several rounds of testing, that code is
reviewed, that coding standards are adhered to. Maybe not to the same level as
aerospace, but probably pretty solid.

So what?

Is financial software engineered? I would imagine so. Maybe not as strictly as
aerospace -- or maybe stricter! I honestly don't know. But I can easily
imagine comparable scenarios.

So if we can engineer financial software, can we not engineer productivity
software? We sure could! How about social media software? You bet! Even games?
Why not?

I think that _all_ software _could_ be engineered. But in fact it probably
shouldn't be. If you want to make a change on software on an aircraft, it
might be five minutes editing code in Emacs, surrounded by a year of paperwork
and process. That'd be ridiculous for an iPhone game. It'd probably be
excessive for a financial application, but maybe some measure of that would be
appropriate.

Perhaps there is (or should be) a spectrum of software engineering. At one
end, we take extreme measures to ensure quality and process, because
(literally) lives depend on it. At the other end, we can hack out whatever we
want and it doesn't matter. Most software lies somewhere in between. Maybe
some of it should consider moving more toward one end or the other. :-)

[Incidentally, it's common to repeat the phrase, "never roll your own
cryptography software". I think it would be totally fair to say "never roll
your own flight control software" too. But the people actually writing flight
control software aren't necessarily top-tier 0.000000001% brilliant
developers. They are, though, surrounded by sufficient process and review that
their work is nearly guaranteed to be solid by the time it takes to the air.
We could probably do something similar with cryptography software, if there
were a model in place (and, I reckon, funding in place) for all of the
surrounding infrastructure to engineer it properly.]

~~~
falcolas
Personally, I've never even had to really consider working around issues like
those that are presented here:

[https://c3.nasa.gov/dashlink/static/media/other/ObservedFail...](https://c3.nasa.gov/dashlink/static/media/other/ObservedFailures1.html)

I also don't really consider myself an engineer: I'm self taught, I don't have
a degree, I've never had to formally prove my software, and the most failures
in my software can cause is some potential loss in revenue.

~~~
jacquesm
That's a fantastic link, thank you for posting. I spent an hour reading that.

~~~
falcolas
For your enjoyment (there's a couple of other good links in the discussion):
[https://news.ycombinator.com/item?id=14765868](https://news.ycombinator.com/item?id=14765868)

------
cortesoft
Oh my god this is such pompous article. None of these things are specific to
software developers, and 90% of the things it says are platitudes that mean
nothing.

There are even some that are just wrong, like the 'throw it away' section.

"It's not the code that is valuable. It's the understanding you've gained from
building it."

What? Maybe at some places, but where I work, the software I write is NEEDED.

And this:

"Never be afraid to throw something away and do it again. It will almost
always be faster to build and much better the second (or third, or Nth) time
around."

Has he never heard of the second system effect?

~~~
bluejekyll
> throw something away and do it again.

This jumped out at me too. This is such a HUGE fallacy. If what you have
written is core to or is the product you're selling, you can't just rewrite
it! Software evolves over time, and it can become difficult to replace it when
it gains features and bug fixes for random edge conditions.

Properly replacing existing software requires having a consistent API against
which you are developing and can test to make sure that it continues to work.
And then having the ability to potentially dark launch new software next to
old to see that it works properly. Even doing all of that, replacement
projects often fail, why? Simply because most organizations can't afford to
have a team that is not contributing to the bottom line of delivering features
to customers.

Doing a replacement project should never be started without a significant
amount of thought and attention. Software always takes longer to develop than
you think, I even underestimate "Hello World!" most of the time.

~~~
cortesoft
For sure - when writing upgrades to existing systems these days, 90% of the
work goes into the transition; how do you start using the new system without
breaking the thousands of people who rely on the old one?

But yeah, I kinda have a feeling I know where he is coming from with some of
his thoughts... my first few jobs were at startups that never went anywhere.
We made great software, but never gained any customers because there was no
real market for what we made.

After a while, you get REALLY focused on the craft of your code, because it is
all you have. You can throw out old stuff and rewrite it, because it doesn't
matter, you don't have customers depending on you. You already made what is
needed by the business, the problem is there IS no business.

My current job is with a large CDN, serving a huge number of actual real
customers with real demands. I don't have time to treat every piece of code I
write as a piece of art. It is simply a tool to further the business.

Personally, I much prefer my current job. I would rather create things that
actually matter, rather than amazing art that no one uses.

------
orthecreedence
No, an _artisan_ is an artisan. A developer is developer. That's not to say
some developers aren't artisans, but a lot of people are developers because it
pays the bills: they build things, and are good at building things, because
they see it as a means to an end. Some do it as a means of expression: it is
their medium for creation. Both modes of operation, and everything in between,
are equally viable and valid.

I guess my point is, it's fine to write code and NOT be an artisan. I'd argue
that most people who code are not as interested in the creation aspect of is
as much as "doing cool stuff" or making money...and that's fine.

But let's not paint all developers with an artisan brush.

~~~
dragonwriter
> No, an artisan is an artisan. A developer is developer. That's not to say
> some developers aren't artisans, but a lot of people are developers because
> it pays the bills

That's the norm for artisans (which is just a skilled worker in a trade
involved in making things, especially by hand), not a distinction. _Artists_
may be a different story, but artists aren't the same thing as artisans.

~~~
alexanderdmitri
I'd argue the diff between artisan & artist is semantics. Conceptually they
both yearn for the elevation that comes along with your output being
considered an art.

------
taylodl
The term _artisan_ always makes me think of pizza. How about referring to
ourselves as smiths instead? Imagine upon being asked what do you do for a
living and responding that you're a codesmith!

~~~
uberstuber
I like the term craftsman

~~~
cortesoft
I prefer the term 'code monkey'

~~~
Danihan
"IT guy"

~~~
cortesoft
I have personally been pushing for the title of "HerpDerpgineer"

~~~
MikeTaylor
My official job title is Software Guy.

------
anotherevan
While the article may be considered a bit trite, and people argue over the
word "artisan", there were a couple of points that brought salient anecdotes
to mind.

Own Up to Failure

I've worked in quite a few places where arse covering was a full-time
activity. Where, "I don't want to make a decision because then I can't change
my mind later," is and actual quote during requirements gathering.

For some reason, I've never been bothered being honest when I've screwed up. I
distinctly remember one time when one of the client's staff came to me about a
problem, loaded for bear, fully expecting a fight on their hands. About one
minute into the discussion, having got my head around the problem I said,
"Yeah, that was my stuff up. I'll get that fixed."

There was a palpable sense of shock, followed by delight and relief.

...and that leads in to...

Trust is Earned

Where I was brought into high-level management meeting with the same client
about some important issue, and my opening remark was, "That's not a bug, it's
a feature," as which point my project manager nearly had kittens on the spot.
But I then explained through the details of what was going on, agreed on a
couple of minor adjustments that would make things clearer in the future, and
everyone came away satisfied.

Don't know if I could have gotten away with that if I hadn't already had the
reputation for being straight with people and owning my own mistakes.

------
flavio81
I don't think this manifesto adds any kind of value to developers. The word
that come to my mind is "shallow". Pretentious, pompous. Of course "coders"
will love it.

Perhaps UI and UX design is an art, but at the end software requires
engineering.

The only manifesto i'd recommend is this one:

[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

~~~
brett40324
Upvote for Zed's link. I was pleased to see that!

------
falcolas
Our field may be grounded by solid engineering and conceptual foundations, but
we have much more in common with the medieval blacksmith than we do a modern
machinist.

For example: Given a bog-standard relational database and the requirement to
be able to create, read, update, and delete rows in the database, what is the
_best_ way to present that via an HTTP API? What language will be used? What
will the API look like? What edge cases will be considered? How long will it
take?

You'll probably get a unique answer for every dev you ask, even though they'll
all consider it to be a trivial task. You'll probably also get fairly unique
clarification questions about the spec from each one as well.

I'm not sure, when we can put the same task to 100 people and get 100 unique
results (and few (if any) would agree to monetary penalties for failures),
that we're strongly positioned within the engineering discipline.

------
treehau5
> Writing stable code and being available to fix your bugs, even sometimes
> after hours.

Nah I'd rather be available during hours to fix my bugs. Call me old
fashioned, but does anyone not believe your work should not follow you home? I
love what France is doing with the "right to disconnect"

~~~
LeoNatan25
Hear, hear!

The inabilty of the young folk to disconnect from their work is disasterous.

------
Splendor
> "Walking the trail of tears with each other..."

I know the historical reference but I'm not sure I understand what the author
is actually talking about here.

~~~
cortesoft
Me either, but it is pretty offensive to compare whatever it is a developer
does to an act of genocide.

~~~
jacquesm
Too busy changing the world to read up on Native American history. Think of it
as artisanal license...

------
jacquesm
Artisan? I wish. For the most part a plumber would be more appropriate. I'd
like to see a plumber marketing themselves as an artisan.

------
2_listerine_pls
What about just calling them developers, crazy idea.

------
chiefalchemist
Artisan? As in artisan breads? I'm not so sure that's the best fit. Yes, I
rise. But I don't want to be sliced and buttered :)

Ultimately, the issue for me is when people use the wrong title (?) to
describe their level of experience, skill and overall sweet spot.

For example, a programmer is not a developer, and a developer is not an
engineer. So when a programmer describes themselves as an engineer - to
someone who has no idea what the difference is - that just ruins it for
everyone. Not to point fingers in a negative way but the WordPress community
is notorious for such shenanigans.

------
alexanderdmitri
Hearing the word "artisan" is just a flag letting me know I need to switch
mental registers if I hadn't already:

if (inputStr == "artisan") { ENV = "MARKETING" };

------
UK-AL
I feel this is dismissing engineers. Most i know engineers also care about
elegance and asethetics.

You may not like it, but engineer is probably the closest match to an existing
profession.

------
em3rgent0rdr
The engineering debate aside, I don't even like how programmers fancy
themselves as "developers", which is very non descriptive, considering that
around half of all human jobs are about "developing" something. People who
write programs should just call themselves "programmers" for the sake of
clarity.

------
jv22222
Of course, the original comparison between coders and artists was made by Paul
Graham in Hackers and Painters:

[https://www.amazon.com/Hackers-Painters-Big-Ideas-
Computer/d...](https://www.amazon.com/Hackers-Painters-Big-Ideas-
Computer/dp/1449389554)

~~~
jacquesm
And then there was this:

[http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm](http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm)

~~~
jv22222
Thanks for that, good find. Pretty eye opening.

------
rb808
I'd think reality is more like tradesman or software builder rather than
engineer. Most devs aren't doing anything new or different. There are probably
guys in the building next door probably doing something similar.

~~~
throwaway2016a
Engineers of any kind usually aren't doing something radically different.

Even if you are building a robot, which is undoubtedly engineering, you
probably have a team down the road building something similar.

In fact, most software engineers I know are very interested in the cutting
edge and research pieces. You can make a living as a mechanical engineer
without using an equation newer than a few hundred years.

~~~
Animats
_You can make a living as a mechanical engineer without using an equation
newer than a few hundred years._

Have you seen what's happened to control theory in the last 15 years? There's
so much new math that new PhDs are having trouble deciding which parts to
learn. Control theory has imported much of machine learning in addition to all
the classic control theory, and they want bounds so they know the machine
learning parts won't do something stupid.

~~~
throwaway2016a
Sorry, that came out wrong.

I am absolutely not implying that there have been no advancements in
mechanical engineering. Just that it is possible to find a job where you will
not encounter them. I am confident you are right that PhDs are doing great
cutting edge stuff.

------
danielalmeida
This is all over the place and reads like a collection of random pieces of
advice.

Why not stop at "An engineer makes something work. You are more than that. You
are an artisan." and present a reasonable line of argument?

------
BurningFrog
This whole discussion is about the meaning of the words "artisan" and
"engineer" far more than it's about programming or anyone's professional role.

------
diyseguy
reminds me of this:
[http://manifesto.softwarecraftsmanship.org/](http://manifesto.softwarecraftsmanship.org/)

------
Cozumel
This is why I never touched Laravel, 'The PHP Framework For Web Artisans'. I'm
not an 'artisan'. I just code.

~~~
spraak
See other comments in this thread clarifying that `artist !== artisan`

