ON TURNING OVER UNTURNED STONES
       
       One of my favourite after-work activities is to putter around the
       print shop where I have a number of presses and other pieces of
       printing
       equipment. They all came to me second hand--well-worn and after
       decades of service--so they are always in need of a little bit of
       cleaning, oiling, or fine-tuning. It takes a lot of rags, elbow
       grease, and patience to make them shine again. But they get there,
       eventually, and I've begun to enjoy the renewal and maintenance of
       these machines just as much as the act of printing they provide. It
       has caused me to gain a cursory knowledge of machines and their parts,
       like what a coupling is and how set screws work. It's also caused me
       to daydream about one day creating my own press or piece of printing
       equipment. I've got enough spare parts lying around that it shouldn't
       be too hard to cobble something together... I just need to find the
       time...
       
       I bring this after-work activity up because I've been thinking a lot
       about tools. Any
       craftsperson worth their salt knows that it's important to keep tools
       in top shape. There's no more sense using a dull saw to cut wood than
       there's sense in using a flashlight without batteries to find your way
       in the dark. And yet, we try, don't we? I've run jobs on a press
       that's been sorely in need of tuning, and I've written code on
       computers needing software updates or running low on space. But
       whereas I can tolerate the dull computer, I won't stand a rickety
       press. I attribute this difference in tolerances to heuristics. The
       press' parts and inner workings I can see and understand, from the big
       flywheel down to the smallest spring. But the computer's inner
       workings are--to me at least--more elusive and obscure. For me the
       mechanics of a computer are far more difficult to grasp.[1]
       
       I've used computers from a young age, but how I've put them to use has
       changed considerably over the years. As I mention in [I|2022-04-06.org|/assets/2022-04-06.org|roygbyte.com|70],
       I didn't always understand that computers could be used to /do stuff/
       and /get things done/. Soon after realizing the "power of
       programming", I became interested in seeing how computers could
       provide commentary on society (to be sure, part of me still is
       interested in this edge). More recently, I've become interested in how
       computers can order and partition the world. The separation of the
       whole into its parts delights me, even if it is a flawed
       sensibility. I'm drawn to admire programs that have so robustly
       established the logic of their foundation[2] that they remain
       resilient through generations of change in hardware, software, and
       developer sensibilities. Emacs is such a software program, since it
       seems to remain fresh and relevant despite how thoroughly computing
       has changed since its creation.[3] And the press
       is also like that, having proved it can remain useful and relevant
       even as printing technology has changed from letterpress to offset,
       digital, and whatever-the-hell it is now.
       
       Yesterday I received a piece of e-mail I'd been anticipating since
       January. The message told me I had been accepted into the Certificate
       in Software Development program at the University of New
       Brunswick. Yay! To know that I'd soon be taking courses like /Discrete
       Structures/, /Data Structures and Algorithms/, and /Software
       Engineering I/ filled me with joy and excitement. These courses (and
       the in the curriculum) represent to me the theoretical
       underpinnings of programming I sorely lack. Because although my skills
       and knowledge had allowed me to work with software well enough to get
       things done, I'd never been able to get those things done
       /right/.[4] And as a (mostly) self-taught programmer[5], I
       hadn't always had the appetite to learn the math or the theory or the
       physics that make computation happen. Unlike printing presses, these
       characteristics are not immediately evident. Not to me, anyways.
       
       A few days before I received my letter of acceptance from UNB I sent
       an email to , whose blog I had stumbled upon a few weeks
       before and marvelled upon for its convivial musings, thorough
       annotations, and generally kind and approachable airs. I asked Jeremy
       "if it's common for programmers to spend a bit of their [time]
       fixing/sharpening their tools. Like, do you ever take an hour to learn
       a new Emacs feature that could boost your productivity?" I was curious
       to know if programmers putter, if they (we?) spend time with their
       tools outside of their productive use.[6] This may seem obvious to
       folks thick in the field of computer science or software
       engineering. To a lay-person like me who's never taken a course in
       Computer Science, been part of a development team, or had to have
       their code subject to a review these programming habits are not
       immediately obvious.
       
       Jeremy responded thoroughly, making a number of great insights on the
       benefit of "". (As an aside, let me say that
       sending the message and receiving such a detailed response was an
       important grasp of confidence that made me feel like I am a part of
       the field of software development, even if on the fringes, and even if
       many of my experiences of using computers to build things and solve
       problems often involves angst and frustration.[7]) He writes:
       
             one outcome I consider absolutely enjoyable is the
             puttering of time simply playing with a computer. Much like idly
             whittling wood with a knife is quite enjoyable; and while the tangible
             outcome is a pointy stick, the intangible is a sense of wonder.
       
       This reflection spoke to me deeply. Play is a crucial part of
       craft. From my experience with printing I know that when paws are kept
       curious--when they wander through type drawers, ink canisters,
       leading, and gears--they can develop a tacit knowledge of the
       craft. There's an immense pleasure to be found in these idle
       movements, just like the pleasure of "whittling wood". But I wonder
       how much that pleasure can be found in what is largely a cognitive
       task, like computing. Even using an interface as seemingly simple as
       the command line requires thought and concentration, doesn't it? Can
       hands idly type words into the prompt like the knife can idly shave
       wood from a stick? I don't have that experience yet, but with these
       queries I've become curious. Maybe that feeling--curiosity, wonder,
       awe--is all that matters. The "idleness" I seek isn't lack of movement
       or absence of thought but something else: absence of
       expectation. Deciding to play in order to have fun is like going to a
       restaraunt in order to have a shit--/that's not the point/.[8] We
       play because we're drawn into something unspoken, undiscovered, or
       unknown. We play because we delight in turning over unturned stones in
       order to "ouu", "aww", and "eww" at the squirming insects and bugs
       that
       lay beneath. How precious it is to find something--a thought, a
       feeling, a sensation--that we hadn't found before.
       
       
       Footnotes
       ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
       
       
       
       Footnotes
       _________
       
       [1] Perhaps this difficulty is owed to being unfamiliar with the
       tools? Given a press and its manual, solving issues becomes fairly
       trivial. Can the same be said of a GNU/Linux machine and its
       "man-pages"?
       
       [2] Their anatomy, perhaps?
       
       [3] How has it managed to do this? A guess: by being developed on a
       resolute paradigm that need not be changed for the program itself to
       change. Like how the components or structure of DNA don't change but
       its contents and expression do. While Emacs remains attached to its
       key concepts of macros and self-documentation what goes into the
       buffers is entirely up to you.
       
       [4] In UNIX philosophy, there is the "Rule of Optimization" that
       instructs to "Prototype before polishing. Get it
       working before you optimize it." A number of people have expressed
       this concept, including Ken Thompson. There's more about that on .
       
       [5] Self-taught in the sense of being an autodidact who reads
       programming books, StackOverflow posts, etc.
       
       [6] I would like to christen the expression "`M-x` and /awe/", as
       in: to invoke Emacs' meta key and then scroll through the list of
       suggestions. (Technically, it's actually `helm-M-x` that's invoked,
       but I
       have that mapped via `(global-set-key "\C-c\C-m" 'helm-M-x)`).
       
       [7] When learning something new I'm like a fish flopping
       around on the beach. I'm simultaneously: in awe at the newly
       experienced terrain, overwhelmed by the conditions of life that I am
       not adapted to survive, and feverishly hoping the tide will return and
       take me back to sea. Surely, I must not be the only person who feels
       this way in face of a new skill of knowledge?
       
       [8] “The time of getting fame for your name on its own is
       over. Artwork that is only about wanting to be famous will never make
       you famous. Any fame is a by-product of making something that means
       something. /You don't go to a restaurant and order a meal because you
       want to have a shit./” -- Banksy (emphasis added)