From: [email protected]
Date: 2019-11-10
Subject: Programming as Craft

I  write a lot of Awk code.  I think it's fun.  Awk has been around
since 1977.  Almost every time I tell someone  that  I  program  in
Awk,  the  response  is  some variation on: "What? Why would you do
that?"

I get a similar reaction when I mention that I've written a contact
manager  almost  entirely in bash.  I've seen this reaction online,
too, when people ask for help using bash or Awk  or  Perl  or  sed.
"You should just use Python," someone often says.

They're  probably  right.  I haven't used Python, but I'm sure it's
more modern and less esoteric than the other tools I've  mentioned.
Lots  of  programmers write Python professionally, so it's probably
safe to assume that a fair number of large  companies  use  Python.
We  can  also,  then,  infer that it is performant and scales well.
I'm sure this is also true of other languages, such as C# and Java.
These  are serious languages that enable professional developers to
deliver scalable, high-performance solutions that  enterprises  can
rely on.

But  that's  not  my idea of fun.  I'm not interested in the stric-
tures of industrial software development.  I  write  programs  that
help  me  publish  this blog, manage relationships with recruiters,
and track my cat's health.  There's  definitely  less  pressure  in
this scenario than in any corporate IT department, but that doesn't
mean that I don't care about quality.  My code has to be effective,
but I have a lot of control over how that happens.

Why,  then,  do  I choose the tools that I do?  Why not be sensible
and use a *real* programming language?

I use these tools because I find it fulfilling.  Conceptually, some
tools  in  the  GNU  suite have a history going back over 50 years.
Text formatting and macro processing  predate  Unix.   When  I  use
these  tools,  I  feel a connection to the past, to the people that
have created and maintained these tools, and to a coherent philoso-
phy about how to solve problems.

I  admit, some of these tools are deeply idiosyncratic and can be a
pain in the ass to use.  But, when I actually manage to  make  them
work,  I feel that I've learned something about the past, something
that I can't really put into words.  To me,  it  is  comparable  to
standing  on  a  sailboat and looking out on the ocean, feeling the
rocking of the waves, hearing the wind beat against the sails,  and
knowing that, for centuries, sailors have shared that experience.

What  am  I  doing,  then?  Am I just playing around in a dusty old
sandbox?  Are my creations just laughable oddities?  I'm sure  many
will say so.  To me, though, creating these programs is a method of
self-expression.  Text-manipulation  utilities  are  my  tools  and
text, sometimes code, sometimes prose, is my medium.

Words  like  "self-expression,"  "tools," and "medium" for me evoke
images of an artisan pulling and shaping clay into pottery, a  car-
penter  carving  wood into furniture, or a jeweler working and fin-
ishing metal and stone.  The act of making  something  through  the
application of skill and care is *craft*.

In  Programming  as Craft[1], Danny Crichton also mentions this ap-
plication of skill and a connection with the past,  but  ultimately
concludes  that programming is not a craft because skill cannot ac-
cumulate when tools and methods are constantly changing.  He  tells
a  story about how much fun he had learning about computer science.
After "modernizing" his toolchain, he went to create something,

    And I stopped, burdened by the sheer amount of effort  it
    takes just to get the most basic of apps running. Maybe I
    have changed as well, but programming just didn't inspire
    the same level of awe as it did before. It didn't feel so
    much as a craft as a never-ending trial  of  stamina.  It
    just wasn't fun, in the sense that I walked away after an
    afternoon with a sense of joy at the creation that I  had
    unearthed.

Why  did he take on so much complexity -- so much that he no longer
enjoyed it?  To me, Crichton sounds like one of the many people who
assume  that  the  needs of industry are the only ones that matter.
It's an easy trap to fall into when the industrial  perspective  is
dominant  in literature and online fora.  That perspective is rele-
vant to people who want to gain and use these skills  to  get  into
the industry, stay in the industry, drive innovation for the indus-
try, and make a bunch of money.   Many  people  want  to  do  those
things,  more  than  want to engage in some personal archaeology of
computer science, so I understand why that mindset is so pervasive.
But  I  think  it  can give people the impression that computing is
just about business and not, to steal a phrase from Steve  Jobs,  a
bicycle for the mind that amplifies human ability.

If  I  wanted to make my own clothes, I wouldn't try to mimic those
that produce clothing at an industrial scale.  There's a long  his-
tory of people making their own clothes resulting in a rich body of
tradition and literature.  There is no  long  history  of  domestic
computer  science  that  focuses on application of the skill by the
individual for their own benefit.

Crichton identifies a need for a "slow code movement."  If you step
off  the  hedonic  treadmill  of languages and frameworks fueled by
corporate money and unchecked, self-serving  cleverness,  you  will
find  that  programming-as-craft lives.  I think this is especially
evident in the maker community where the act of creation, often for
one's own benefit, is of the highest value.

Many  GNU  tools  are conceptual descendants of tools developed for
Unix.  Unix, compared with its predecessors and even  "user-friend-
ly"  systems  that followed, feels as though it was made with human
users in mind.  The  command-line  interface  rewards  effort,  and
skill can be built and honed.  The C programming language, slightly
younger than Unix, has heavily influenced every major  language  in
use  today.   If  you learn C, learning anything else requires only
incremental effort.

I'm going to keep programming in Awk.  It's effective, but also fun
to  use.   There  are many things it doesn't do well or at all, but
those are things that I, myself, just don't need.  It  connects  me
to  a  tradition  and a lineage that, one could argue, goes all the
way back to the abacus.  Whatever your tools, medium,  or  purpose,
happy hacking.

**Postscript**

If  the  needs of most programmers are relevant to industry, then I
expect that most  fora  will,  and  should,  address  those  needs.
Crafters  simply need to be aware of this so that they can evaluate
the information they receive.  It also means that crafters are  re-
sponsible  for  putting  in the work.  Read the documentation.  Run
experiments.  Learn by doing.

Learn how to ask questions.[2] When you ask for help from strangers
online,  understand  that many (if not most) of them have an indus-
trial mindset and they may not share your values.  If you are  try-
ing to build a website using a macro processor from the 1960s, they
are probably going to tell you to use WordPress like a normal  per-
son.  To them, it's a solved problem.  They may not understand that
you are doing this because you find it interesting  and  enjoy  the
challenge,  or  that  you  want to know what it *feels* like to use
those tools.  Feeling, expression, and personal fulfillment are ir-
relevant to industry.

So,  if someone cuts you down for making irrational decisions, just
understand that they don't share your values.  If  you  get  stuck,
consider  stepping back and revisiting the fundamentals before ask-
ing for help.  When you do ask for help, ask good questions.

References

[1]: https://techcrunch.com/2018/02/24/programming-as-craft/
[2]: http://catb.org/~esr/faqs/smart-questions.html