Afterwood

Ten years ago today (as I write) I created a blog and published my first post. It was to be the start of a new chapter in my career as a programmer, spurred on by my fairly recent introduction to the world of ACCU which itself came about through lamenting the demise of the major printed programming journals on the company’s chat tool.

My decision to begin writing was not an easy one, though. For a start, my English exam results as a teenager were somewhat abysmal; so bad, in fact, the exam board wouldn’t even give me a grade (a ‘U’ for those familiar with the ’80s English school system)! I eventually passed my English Language exam, but not without a struggle. I thought developing software would have little to do with ‘proper’ writing and so it wouldn’t matter in the long run; I couldn’t have been more wrong.

Aside from the act of writing itself, which I had accidentally started to do anyway through some lengthy diatribes dressed up as emails about the state of the architecture and codebase I was working on at the time, the other major concern I had was around originality. What was I going to write about? If there was something I had learned from all my time spent reading up to that point, it was that so much had already been said, what could I possibly say that was new? In particular I’d only really worked in ‘the Enterprise’ which is hardly a breeding ground for cool and exciting new inventions in the world of software. If that wasn’t enough, StackOverflow had recently taken off and was fast becoming a major source of knowledge that looked to be the nail in the coffin for many shorter topics which seemed to be a nice way to ease oneself into the writing process.

What I came to discover was that neither of these concerns were really anything that I should have been quite so worried about. Writing, much like programming, is something which you can only get better at by doing. What had made those emails particularly hard to write was getting the tone right so that they framed the problems in a light that was positive rather than simply sounding like an empty rant. I wanted the problems to be acknowledged and to inspire my team to think about how we could improve matters going forward. Consequently, I found myself continually reading back what I’d read, and then re-writing bits, again and again until I felt I had finally expressed myself in a way that I hoped was somewhat inspirational. I don’t know why it took me so long to recognize that what I was already doing with code – continually reviewing and refactoring to best express the solution – was perfectly normal when writing prose too. And naturally as I got better I found myself triangulating towards a piece I became happy with much sooner and therefore the experience became more enjoyable as a result.

It’s probably no surprise that the more you do of both – programming and writing – the more interesting parallels you discover between them because, after all they’re both about languages with rules where ambiguity can have unfortunate effects. As such, I’ve found an unexpected feedback loop developing, where my interest in programming languages has generated an interest in natural languages too, where for a long time there was only really disdain. This in turn has generated a degree of confidence that has caused me to consider being more adventurous in my writing style.

Looking at the subject from the content perspective, what I’ve found is that originality is essentially a moot point because as an industry we seem to spend a considerable amount of time rediscovering ideas and concepts from the past. In part I suspect that is because there is still a considerable gap between the theory and practice of programming due to the imperfections and limitations of the tools we use. Hence there is a continual need to bridge the theoretical and practical worlds by framing the discussion in the context of different toolsets and problem domains as this helps the message to get though to different people. Coupled with the imperfections and limitations in our writing, this means any given topic can, and must, be said in a number of different voices to help others relate to what we are saying. Just as one size does not fit all, neither does one explanation, which is exemplified by the number of people who have attempted to explain what a Monad is.

There is also a heavy bias in the industry to focus on what the ‘cool kids’ are doing in places like Silicon Valley despite the fact that the large majority of jobbing programmers are not involved in greenfield work. While it is useful and interesting to know what new stuff looms on the horizon, I also want to know how some this can be applied under the tight constraints of the aging brownfield codebases which my day job entails. A lack of knowledge sharing from those in older establishments is less surprising when you understand what constraints they apply around protecting intellectual property despite the fact that what many of them are producing is anything but rocket science. As such, I’ve become happy to help populate the body of technical literature which helps document the experiences of how one person has tried to apply their ever growing tree of knowledge to what might be considered by some to be the less glamorous world of the maintenance programmer.

My decision to start recording my observations and practice using the written word has undoubtedly been fulfilling. At the very least, I have been able to refer back to my own notes when the same issue turns up again, but occasionally I have also been fortunate enough to learn that other people have benefited too, and that alone still makes it all worthwhile.