
Programming is not a craft - mmariani
http://dannorth.net/2011/01/11/programming-is-not-a-craft/
======
hcarvalhoalves
Yes, it is a craft, as in crafting:

\- It is labor-intensive

\- It is creativity taxing

\- It produces better results the more skilled the craftsman is

\- It can only be learned by practicing

That extends to all professions that can't be automated and benefit from
highly-skilled labor. They are all crafts.

The author is just confusing craft and art.

~~~
shantanubala
I'd also argue that it's also art, just with a smaller target audience. Open
source software is a great example of this. A lot of open source projects are
really just experiments in expressing an idea in a new way, or basically
saying, "hey guys, check out this cool thing I did." _why was the trademark
example of taking this concept and constructing an entire persona around it,
but art is about expression, and programming allows for some interesting forms
of expression.

Just like it takes a little training to appreciate the intricacies involved in
the construction of a piece of literature, classical music, painting, or other
work, it takes training to appreciate beautiful software.

Code is just a much newer canvas for ideas, so it's not as mature.

~~~
michaelochurch
Art is a poor metaphor for software. A bad painting just looks ugly. It
doesn't hurt anyone.

A better metaphor is a block of Legos, but where none of the pieces fit
together well and 2/3 of them are of such poor quality as to make them almost
worthless and, worse yet, you can't choose not to use them because the people
setting requirements don't know or care about block quality and "just want it
to work".

I'm experienced both in software and creative writing. I've read (and written)
some awful short stories and poems. Bad writing is embarrassing. Bad software
is a much higher dimension of evil. Bad code kills businesses.

~~~
shantanubala
So the question could be rephrased to a better analogy: is architecture art? A
faulty building can kill people, but buildings can be expressions of ideas. In
other words, there is a utilitarian form of architecture, which involves
making the most efficient/simple/effective solution to a problem. But there's
also the side that produces iconic and truly beautiful buildings for no other
purpose than beauty.

------
columbo
This is a fantastic title, right up there with 'Dynamic typing is 1000x better
than static typing' and 'Tabs vs Spaces: winner spaces'.

It really just leaves us arguing the finer points of what the definition of
craft is. Could you argue that knitting isn't really a craft as most people
just want sweaters _that work_ over sweaters that show some amount of
professional craftsmanship quality? What about coffee tables since Wal-Mart
sells cheap coffee tables and people generally own cheap coffee tables that
must mean that woodworking isn't a craft.

ugh... we may as well argue the merits of calling something 'Art' with one
side holding firmly to the position of _since I consider it art it therefore
becomes art because art becomes art once someone identifies it as art_.

As for the artistic nature of code I'm reminded of reading someone's quote
years ago "On a whim one afternoon I decided to browse the source-code for
Nethack. I looked at it, and it looked back at me, and I was afraid"

------
joebadmo
I find it interesting that the two examples he gives of "proper professions"
are highly regulated guild-like professions whose values are artificially
inflated, at least to some degree.

I'm only a very new programmer, but I'm reading Martin Fowler's _Refactoring_
and, even from my limited experience I'm finding that one of the differences
between software and other products is that software must be maintainable. So
the end user isn't the only end user. Software has to be read and worked on by
other programmers in future, and most of the _craft_ involved is not in making
a program simply work as it's supposed to, but making the code easy to read,
easy to maintain, and easy to modify.

So the aesthetic quality of the code and the craftsmanship involved is very
important, for pragmatic and eventually end-user-facing reasons.

But hey, what do I know? I haven't gone to programmer's school or gotten a
programmer's license or anything.

------
lomendil
I remember seeing a shift in CS student populations, say around 1999, from
people who already had a self-developed interest in computing to people who
wanted to learn programming as a trade to make money. The first group had
probably taught themselves programming and had already been tinkering with
system internals and hardware. They were programming because they were drawn
to it for whatever reasons.

I think the author of this piece is from the latter group. To that group,
software as craft just doesn't fit into their world. Whereas I think the first
group has an understanding that beauty on the inside of a program shows on the
outside too, especially over time.

~~~
leoedin
It's the same in a lot of technical fields. In my mechanical engineering
courses there was a minority who truly loved everything to do with machines.
The people who work on their car at weekends or build projects in their spare
time. They were truly excited just to be able to do what they loved and get
paid for it.

The majority though are people who have some affinity for maths and sciences
and have made a career choice to study engineering. They put in the hours to
do the coursework, but if it's not proscribed in the course they simply won't
do it. They go home and don't think about engineering at all. Big companies
are full of these people, chugging away at their job but not particularly
interested in spending their spare time honing their skills or working on
other stuff because it's actually pretty awesome.

------
finnw
> _non-plumbers don’t care about the aesthetics of plumbing_

Of course they do. Nobody wants crooked pipes in their house, or pipes visible
where they need not be.

~~~
eventualEntropy
To make the analogy work I think you have to assume he's referring to the
complex of pipes hidden in the walls.

~~~
joesb
Pipe hidden behind the wall still has to be beautiful in relative to how the
plumber have to work with it. If some plumber hide pipe behind the wall in a
way that makes any maintenance impossible, then it's probably "ugly" for
plumber standard.

------
BasDirks
"PROGRAMMING IS NOT A CRAFT"

And then the TLDR basically says: "Non-programmers just want programs to
work". As if the two are mutually exclusive... as if craftsmanship forbids
pragmatism.

No, just no.

------
kevinpet
Carpentry craftsmanship risks putting the furniture at the centre rather than
the benefit the furniture is supposed to deliver, mostly because we are
romantics with big egos. Carpentry is about having a place to sit, a place to
put your coffee cup, and a place to store things that fits in with the
client's desired style and other requirements.

Non-carpenters don’t care about the aesthetics of joinery in the same way non-
plumbers don’t care about the aesthetics of plumbing – they just want their
furniture to support their weight and drawers to not stick.

End of parody. If software isn't craftsmanship, then the only reasonable
alternative is that it's a branch of engineering, but most software is
developed in an environment and via a process that is much more like a
customer furniture maker's shop than a proper engineer.

It looks like what he actually wanted to argue was something more like "we
should learn lessons from other more developed craft professions" but I didn't
read beyond the link bait title and inflammatory introduction.

------
10098
I don't think we admire good engineering because it has some "aesthetic"
merits. It's beautiful because it fits its purpose.

Planes are beautiful, but if they looked differently, they wouldn't be able to
fly. Cheetahs are beautiful, but every feature in their body has been designed
by nature to make the fastest animal on earth.

I think it's the same with software engineering. We don't think a program is
"beautiful" because the author decided to use that particular algorithm or
fancy data structure, it's because this algorithm or data structure allows
them to solve the problem at hand correctly and within imposed limitations on
resources. It fits nicely with the overall purpose.

~~~
Mz
My remarks here: <http://news.ycombinator.com/item?id=4906217> probably should
have been posted as a reply to this comment, which is what inspired it. The
rest of the remarks here make mine seem out of context, but there were a lot
fewer remarks at the time I started my reply.

So, basically, I was agreeing with you.

Thanks

------
zeteo
>It would be great if programming were a proper profession, but it isn’t. A
profession has a structured model for advancing [...] We need some sort of
apprenticeship model, and a way to identify masters, both to apprentices and
other masters.

Bullshit. It is precisely because programming is not straitjacketed in such
medieval rigidities that it can create so much value these days. Forcing
today's youngsters, who may be like Gates, Zuckerberg or the Collison
brothers, into an X-years long "apprenticeship" program before anyone takes
their code seriously is a spectacularly bad idea.

~~~
michaelochurch
Proposed compromise:

1\. Anyone can write code. 14 years old? No school? Fine. Doesn't matter. If
it's good, people will voluntarily use it. Absolutely anyone can write code,
and if it's good, people will use and pay for it.

2\. No _manager_ can make _me_ read your code as a requirement of my job
unless you've proven (by certification) yourself to be at a level where less
than 5% of professional programmers currently are.

This would work for me.

~~~
randomdata
No manager can make you read code as it is. There is said to be an
unprecedented shortage of developers. It is easy to walk to another company
who has code that aligns with your beliefs.

I don't see anything wrong with companies that want to have bad code. They'll
probably suffer for it, but that's not your or my problem.

~~~
michaelochurch
I'm not talking about "me" here, except rhetorically. Yes, _I_ can walk away
from bad code (although I might be walking into worse code). I don't think a
junior developer in Iowa City can.

What I'd like is a world where as few people as possible deal with bad code,
and no one is stuck with no other options, because bad code tends to beget
more bad code, and because it's wasting time that could be spent writing a
bunch of new good code.

The evil of bad code isn't that unskillful code exists. The problem is that
there are plenty of managers out there who don't know any better and will
insist that people use it, and who never learned the processes that lead to
good code (most important: keep program size _small_.)

Also, my experience is that over 90% of corporate code is absolutely
terrible-- unusably, mind-stoppingly awful. Rolling the dice doesn't have the
best odds.

~~~
randomdata
> Also, my experience is that over 90% of corporate code is absolutely
> terrible-

Which is kind of funny because those are the businesses who rely most heavily
on vetting done through colleges and universities. They have, on paper, the
very best programers available. I guess that goes to show how poorly
credentialing actually works in the real world.

~~~
michaelochurch
+1. You win this one. At least, we haven't shown that we have the machinery to
build a _useful_ credentialing system for software quality.

I think the pain of what we do in the software industry, from the low respect
to the bad code, goes back to the fact that our work is extremely difficult to
measure, although the importance of quality could not be higher. Corporations
have traditionally responded with a 3-4 year bug-fixing evaluative spell, but
that's now leading to adverse selection because people like us (as you noted)
won't stand for it.

------
sdafdasdfasdf
> Software craftsmen should be egoless, humble, with a focus on the outcome
> rather than the code or the process.

That sounds good. But developers aren't like that. We are concerned about
getting the job done in a way that promotes our career and/or keeps us from
getting fired, well- most of the time.

> I also think there should be a way for passionate, skilled programmers to
> differentiate themselves from the mainstream commodity bodies, and also to
> recognise one another, and demonstrate their value to potential employers.
> What could that be, and how could we make it work?

These are called certifications, and their value has diminished. Here's why:

Many of us survive by Google searching, using stackoverflow and better
documented frameworks. And, there still aren't enough of us. Many of us feel
we are overpaid, but most would never admit it.

By deciding on a way to determine who is proficient and who isn't, you risk a
lot of people not being able to find work, and for what goal? Right now
programming is an art. If you make it into a trade with the federal, state, or
county regulations saying that the developer must be qualified in X, and they
have tests for X (that become irrelevant daily), then you are going to (1)
eliminate a lot of developers from the workforce and (2) stagnate the art
because right now it develops at a faster pace than any of us can keep up
with.

~~~
paulhauggis
"Many of us feel we are overpaid, but most would never admit it."

Really? I've always felt underpaid. Most business owners don't understand
software or deadlines and me (and my developer co-workers) have always had to
suffer as a result of this by working insane hours for weeks at a time to get
things done.

But keep thinking this way. It will only help me when I need to hire
developers for my own business.

~~~
nthj
> Really? I've always felt underpaid.

I think the sentence before the one you quoted clears things up:

>> Many of us survive by Google searching, using stackoverflow and better
documented frameworks. And, there still aren't enough of us. Many of us feel
we are overpaid, but most would never admit it.

If you're shipping real software for real businesses that weaves a half-dozen
technologies together in a way that none of the business guys knew was even
possible, and you proposed and executed on the idea.

If you're in a large corporation working 40 hours a week, always clocking out
at five, and there are no consequences for dates slipping, then yeah, I could
maybe understand feeling overpaid.

But if I'm building the systems that make the business? The business could not
operate without this software? About to make 5 salaried employees 1.4x
productive? Yes, I'll charge a lot, and yes, I'm worth every penny.

------
tytso
Although it's true that people want programs for their functionality, not
their beauty, there _is_ a reason why it's a good idea to focus on the
"beauty" of the program that lies beneath the functionality, and that's
because unlike bridges, which rarely need to change once they are built,
programs often do need to be improved and modified after the 1.0 release.

More importantly, other people will need to be able to revise and extend upon
your work, and if it is easy for other programmers to understand your code,
and be able to work on your code, this makes your code far more valuable in a
way that might not be visible to a customer who is only interested in the
functionality.

Now, there may be cases where this doesn't matter. If it's a startup where
it's not even clear whether you're going to get the next round of funding,
maybe taking the time to invest in making your software more maintainable
doesn't matter; letting technical debt build up might be acceptable.

But there is a reason why open source projects care very much about the
underlying quality of the code from an aesthetics point of view, and that's
because we need to worry about the long-term maintainability of the code after
we accept a code contribution. Even if the startup goes belly up, you can
reuse open source code. Proprietary code is much less likely to be reused, and
besides, once the startup fails and you are fired and the assets get sold off,
why would you care about how maintainable the code will be? It's very unlikely
you'll ever get the chance to work on it again....

But in the case of open source code, caring about the craft of writing good,
maintainable, elegant, easy-to-understand code _is_ important. And in that
way, I do respect programmers who respect their work as if it were a craft.

------
elchief
T-12 hours before "Programming is a craft" post on HN

~~~
Mindless2112
That timer is long expired. This article (which uses "craft" as a synonym for
"art") directly opposes Knuth's [1] from 1974 -- I'll let you guess which one
carries more weight.

[1] <http://www.paulgraham.com/knuth.html>

------
EliRivers
Anyone who chooses to use "TL;DR" at the start of an article where
professionals put "Abstract" or "Synopsis" (or, God forbid, "Introduction")
is, whilst not necessarily a posing hipster, at least subverting their own
credibility.

------
eipi
There are two kind of "technical" people. The "Science" kind, and the
"engineering" kind. If you appreciate the "beauty" of an mathematical
equation, or the "elegance" of a proof, you are the "Science" kind. If you
appreciate the preciseness of a tool, or speed to achieve a task, you are the
"Engineering" kind. Science provide the backbone behind engineering, but
engineering re-invigorates science. Unfortunately, programming can fall into
either categories. Argument like this is mostly pointless without a specific
context. As a programmer, it is a life long effort to find the "zen" of the
two.

------
dspeyer
Does he really think this sort of invisibility just happens?

A road goes over a bridge so smoothly that drivers don't notice the bridge.
The result of the bridge-builder refraining from decoration? Mostly the result
of the bridge-builder very, very carefully lining things up. With a level of
planning-time rarely seen in the software world.

Non-craftedness is just a style, one that only the most skilled craftspeople
can achieve.

------
Mz
The cathedral example does not work. The author clearly explains how the
aesthetic of a cathedral helps put people in the right reverent frame of mind
to worship, which is the action they are there to perform, then dismisses that
beauty as not functional, as mere aesthetic. It seems clear to me if the
design helps them get in the right frame if mind, it is functional.
Furthermore, historically, the point of stained glass windows was to share
some of the stories of the bible with a largely illiterate population. Again,
it was beautiful but not merely decorative. The art of the cathedral had
purpose and function.

I have a Certifucate in GIS. The mapmaking class I took emphasized the fact
that a good map -- one well designed for its intended purpose of efficiently
conveying information -- will be perceived as "beautiful" in much the same way
that good engineering is typically perceived as aesthetically appealling but a
beautiful map is not necessarily a good map. In organizations where GIS is not
well integrated, you wind up with "map shops" who are not involved in any
really important part of collecting the data or using it. Their only role is
to make maps for the people who do use the data. Map shops inevitably become
obsessed with making beautiful maps, to the point where embellishment may well
interfere with effective use of the map.

I have come to believe that beauty (of all kinds) is valued because it is a
qick and dirty proxy for real value since things which are well designed seem
to universally have visual appeal. Therefore, if it is not aesthetically
appealling, it probably is not really all that good in terms of quality. I
think beauty then also gets routinely maligned because it can be a quick and
dirty means to fake value, to falsely signal value, when it doesn't really
exist. I think this conflict will never be resolved because both things will
remain true. We will continue to remark with awe and wonder on the "beauty" of
high quality work and continue to deride low quality work which tries to cover
up its defects by slathering it in prettiness.

For those adequately in the know to understand the code, there will continue
to be people who talk about programming in terms of "beauty". For those not in
the know, it is too abstract to "see" the beauty of it.

------
heathlilley
I think of it like this, Craftsmanship is about having the discipline to dot
'i's and cross 't's. It's about scrubbing out the pans after your done cooking
a meal, because while you might be able to keep reusing a skillet without
cleaning it to produce delicious meal after delicious meal quickly,
eventually, you're going to send a customer to the hospital.

Keeping code in small readable chunks that have automated tests makes it
easier to maintain and if this hasn't been your experience then I would say
you haven't been doing it correctly.

------
wellpast
There is an internal property of a software system wherein it is better suited
to accomodate the future (new requirements, change). Better suited means it
can accomodate the future more efficiently and stably.

Two software systems may delight the customer, for example, but one could be
far better positioned to evolve, grow, delight future customers and more
customers.

The ability to create such systems lies with some not all and usually comes
with experience.

What is this ability called, if not craftmanship?

------
elchief
"Non-programmers don’t care about the aesthetics of software"

<https://www.google.com/search?q=market+cap+apple>

------
polyfractal
> _So here’s my concern with the idea of Software Craftsmanship. It’s at risk
> of letting programmers’ egos run riot. And when that happens… well, the last
> time they went really nuts we got Web Services, before that J2EE._

I'm pretty sure it wasn't programming _craftsman_ that created J2EE, but
rather the programming _tradesmen_ that this guy seems to be glorifying.

------
__abc
As a programmer of 13+ years ... YES, YES, A THOUSAND TIMES YES

~~~
jgw
As a programmer of 29+ years, I'm not sure I agree! :)

~~~
__abc
I hear ya. It's all about balancing short term vs long term.

My general reaction to Craftsmanship is they pull toward an equally unhealthy
end of the spectrum. Only focusing on quality is equally as bad as never
focusing on quality.

------
lttlrck
Since when is it legitimate to self-label yourself a craftsman? It's pure
vanity.

Repeat after me: you are a computer programmer.

------
crististm
"With a craft, the product has intrinsic beauty in its own right." - Is he
talking about art?

------
michaelochurch
Code beauty is different from aesthetic beauty (e.g. cathedral). Code should
be straightforward and almost boring. You don't need to start complex; it will
come to you. Complexity should come from the problem being solved. Self-
modifying code is "fun" and also completely unmaintainable. Same with code
that uses a lot of inheritance (except in GUIs, where inheritance is a natural
fit). It might be "fun" to write but it's hideous to maintain. It's better to
point that creativity in the direction of _clean_ code that teaches other
people how to use it and how the problem is solved.

Code aesthetics cannot be compromised, but code beauty doesn't mean complexity
or adornment. It means functional simplicity and ease of learning. It should
trigger the, "Why didn't I see this problem so simply?" reflex.

 _A really great programmer (and I’ve been lucky enough to work with a handful
over the years) can out-perform a doing-it-for-the-money programmer by orders
of literally hundreds, delivering in hours or days what would take an average
developer weeks or months._

True, if that great programmer doesn't have meetings or interruptions, get to
choose her tools, and has full autonomy in how she does her work.

I used to think that mediocre "day-jobbers" (to borrow a word from the OP)
made the crappy corporate software environment and bad software. I now am
pretty sure that it's the reverse. The corporate world limits people and turns
them into day-jobbers. You have to be constitutionally insubordinate in order
protect your creativity through the grunt-work 20s and not a lot of people
have the nerve to deal with the result of that (e.g. frequent job changes).

This is compounded by the fact that the people who climb the corporate ladder
tend rarely to be of that insubordinate type. After 15-25 years, they're
finally in positions that would use that creativity... and don't have it
anymore; it's gone forever.

~~~
yuhong
[http://programmers.stackexchange.com/questions/45776/why-
do-...](http://programmers.stackexchange.com/questions/45776/why-do-business-
analysts-and-project-managers-get-higher-salaries-than-programme)

