The Zen of a Software Master
From the Classics to software
When I became a professional software engineer at the age of 37 — in a way against all (including my own) expectations — two people were instrumental in helping me get there. First, my dad, who was an early adopter ever since the days of MS-DOS. I remember sitting next to him as a child in wide-eyed wonder, when he was sweating over the install of our first PC from a stack of 3½-inch 720 KB floppy disks. It was thanks to him and the machines he handed down to me whenever he fancied a new one (much to the chagrin of my mum), that I developed a fascination for computing and automation. The other person was Richard, my former CTO. This blog is about him.
I first met Richard when I made the transition from academia to the library world. After having completed a PhD in Classics and working as a researcher and university lecturer, I too fell victim to the infamous bottle-neck that is academic employment. A tenure spot had finally opened up at my Alma Mater and I was one of the two candidates who applied. However, when I failed to get the job (and got chewed up and spat out in the review process) I was bitterly disappointed. But lo and behold, some months later I applied for a position as Head of Special Collections at another university library and I landed the job.
Meeting the master
Richard, who was CTO of the Library Automation Team, was one of the first people who came round to welcome me. He immediately struck me as a special person. Witty, sharp as a tack and always asking the right questions. He must have liked my answers, because although we did not see each other that often, he was always supportive of my projects and spurring me on. We also got along well personally, sharing common interests like games (at the time I was playing lots of poker) and a cut-the-crap mentality. I soon realized, though, that Richard always spoke his mind, which could be quite jarring. I remember one time when we were having a coffee break with some colleagues and I was talking about digitizing old books and prints. At one point Richard interrupted me and said: “Let’s be honest, Tom. What do you really know about digitization?” And he was right. At the time, I couldn’t have told you much about image compression or metadata, but like all novices I was trying my best. I believe Richard saw that too, so I took the remark in the spirit in which it was intended: I dug deeper.
In the process of digging deeper I slowly reconnected with my inner computer geek. Working with library data brought back memories of experimenting with Visual Basic as a teenager and writing FileMaker Pro scripts at university. For a long time, I felt my passion for automation rekindle, but did not know what to do with it. So, one day, I asked Richard out to lunch to hear his opinion. I remember asking him: “I just don’t know where to start. Should I learn C++, should I learn R?” His answer was: “Programming languages are tools. For instance, R is a set of binoculars, while C++ is a microscope. You need to figure out what tool you need first.” In the end, he suggested looking into XML further, which is still commonly used in the library world. I installed BaseX, started exploring XPath and XQuery, and immediately the world opened up before me. I began working with data exports and building pipelines, and soon I realized that I wasn’t half as interested in rare books or prints, as I was in this. Things only got worse when I started learning some Python (with Automate the Boring Stuff With Python) and proceeded to take a summer course in digital image analysis. Until then, I had never believed I could work with software professionally, but when I found myself helping the summer school teacher out in getting Anaconda installed on the Windows machines, something changed in me…
Becoming an apprentice
Soon after, I informed library management that I wanted to leave the Special Collections and make a transition to the Library Automation department. They were reluctant to let me go, but Richard, who was part of the management team, was my biggest supporter. At first, though, it wasn’t obvious which role I could take in the department. The job of data analyst seemed quite suitable, but that position did not yet exist then.
Incidentally, at the same time, my wife and I bought a house in the same village as Richard. Even before we moved in properly, I took him up on his invitation to drop by. I had my son with me, who was promptly presented with a giant chocolate bar, which gave Richard and I ample opportunity to discuss my future. I don’t remember how exactly, but at one point he confronted me with a challenge: “Wait a minute, would you like to work as a software engineer?” The invitation filled me with fear, but at the same time it was now or never. And when I said yes, Richard instantly started arranging a job opening that anticipated the retirement of one of the department’s software engineers.
A couple of weeks later, I started working half-time for the automation team, so that I could get ready for when the job would be officially announced half a year later. Because, even though management approved, I would still need to apply just like anyone else. The next months were hectic, even frantic, with me diving head first in our tech stack, which includes MUMPS, Python, SQL, Go, JavaScript, PHP, to name but a few. At times, I felt as if my brain was expanding inside my skull. But Richard proved a patient tutor; even taking time to do some painstakingly slow pair programming with me, or getting my Linux box set up.
Later on, these grueling months would take their toll. Besides my wife, it was Richard again who noticed I was heading for a burn-out. I have written elsewhere on the backlash of trying to learn computer programming in six months, but I am also forever grateful for that time. It forced me to grow in ways I never thought possible. When the job opportunity came, I was ranked first among the candidates and officially became a software engineer. Fast forward three years, and now I find myself working as a full-stack developer, teaching Information Science with Python, and with the prospect of training new colleagues myself.
Saying goodbye
A few weeks ago, Richard retired as CTO of the Library Automation Team. The months before, we had been working together closely on implementing IIIF (an image exchange protocol) and deploying a bespoke Go tool for software installation. Yet when his last day finally came, I was too upset to really say much in terms of a proper goodbye or thank you. I guess many of my colleagues had the same feeling, because even though he was the founding father of our system, everyone kept rather quiet when Richard left.
I could write much more about Richard in his capacity of software engineer and as a person too. Incidentally, we both commuted on the same train, so I’m going to miss those conversations badly. All too often they would start with software issues, but then end up somewhere else entirely, like chess or fantasy novels, or, indeed, the meaning of life. I could recount numerous anecdotes like when he warned me that his car might smell of dead dog (this was before I knew his wife is a vet) or what he thinks about the paranormal or God. But this is not the time or the place…
The Zen of the software master
When I started out as a software engineer, Richard recommended I read the book Apprenticeship Patterns, which offers a lot of useful advice for being an apprentice in any field really, but especially software. It traces a journey from apprenticeship over journeyman to mastery — the ever-elusive goal of the eager apprentice. But at the very end of the book comes the true revelation: there are no masters. Surely, there are those with superior skill and talent, but ultimately, everyone is an eternal student. However, what distinguishes the very best among software engineers is not their skill, but their added ability to inspire , so that they not only produce great code themselves, but also advance the software craft and community as a whole. In the words of the author:
True mastery is shown in the effect you have on others by transmitting your superior skill
Richard was and is, for all intents and purposes, a software master, a so-called “10x engineer”. He always knew more, wrote better code, and worked harder and faster than anyone else. Yet what made him truly exceptional was his devotion to his role as a mentor. And I for one, thank him profusely for it.
Hi! 👋 I’m Tom. I’m a software engineer, a technical writer and IT burnout coach. If you want to get in touch, check out https://tomdeneire.github.io
If you’ve enjoyed this story, you might also like:
