It has been two years since I started this blog. A year ago, I reflected on the first year. I have averaged an article a month, this being number 24. I try to post an article in the first week of each month. That cadence is about right for me. I have a lot of things that I want to write about, but it takes me a good while to write an article, reflect on it, and refine it. I'm not sure how many people have ever read this blog, but maintaining it has been very satisfying. A couple of times a friend or a colleague has told me that they enjoyed an article, which has been most rewarding. Maintaining this blog has benefited me in a number of ways. I thought I would reflect on them here.

Anonymity

Without a doubt, one of the biggest motivations for starting this blog was to be able to share some of my work to expand my opportunities for employment. For my entire career, I have worked on proprietary software applications and systems. I don't have a public record of what I've worked on, beyond a list of items on my circum vitae that most people have never heard of.

Troy Hunt, in The Ghost Who Codes, writes about how anonymity can hurt your career. My anonymity came from investing too much of my time exclusively for my employer and not enough for myself. I have always enjoyed my job and I find it hard to put work down. I'm always thinking of what I want to tackle next or how we can make something that we've just completed slightly better. On nights or weekends, I would often forge ahead on whatever was next at work. It was my outlet for when I wanted to feel productive and work on something technical. Now, however, I'm better at using my time to explore something that I want to explore, often still related to work, but from an angle that leads to a blog article that I retain, rather than just uncompensated work for my employer. At the same time, this still has great benefits for my employer and my productivity at work. For example, when writing an article on automatic resource management in Scala, I discovered the Scala ARM library. When writing an article on test generation in Scala, I studied how to handle HTTP rejections in Akka HTTP. Both of these things immediately benefited my day-to-day work and I had something to share publicly for this weekend work.

Having a place to share some of my work that I control, rather than being a content provider for Stack Overfow, GitHub, LinkedIn, etc., is important to me. I'm quite happy with my employment at the moment and I'm not actively looking for a job, but I hope that should circumstances change, sharing some of my thoughts and my work publicly will help me find opportunities that I would not find otherwise. I also hope it might open some opportunities outside of just employment, opportunities that find me, rather than me finding them.

Improving My Writing

I've always taken care in my writing and I think I write reasonably well, at least for technical communications. I took a technical writing course in university that was fairly influential on my writing. Most influential, however, was my Grade 11 English teacher. She essentially focused the entire semester on reading one book, The Lord of the Flies, and writing one comparative essay, contrasting themes from the novel. She paid close attention to the content of the essay, but even more to the structure, emphasising constructs that can be practised and lead to good writing. We kept refining the content and the structure of that one essay, incrementally, week after week, over the term. Living with and evolving my work like that was a great experience and is much more representative of professional work, be it writing or programming or engineering. It was a much more valuable experience for me than trying to read a bunch of books and crank out a bunch of essays. I approach each blog post in a similar manner.

I take more note now of other people's writing—how they structure their thoughts, how they use punctuation, formatting, and emphasis—and it has influenced my own writing. I used to focus primarily on the content, worrying about punctuation and formatting after the fact. I'm much better now at considering these aspects as I write and I'm also getting better at editing. This has helped me write more effectively when I type an email, comment on a code review, or have a conversation in a chat application at work.

The fact that my writing is public and the fact that I want some consistency to the quality of my writing has forced me to make some explicit decisions about how I'm going to write. For example, I faced a decision when working on a recent essay that called for the use of a lot of singular pronouns. The decision was made even more interesting by the fact that the author of the book that I was quoting in the article was always very careful to use singular pronouns. I found that using he/she was awkward and that choosing between he or she was pedantic. I thought, forget it, I'll just use plural pronouns. This is how I usually talk. This is how my friends and colleagues usually talk. Writing this way is not without controversy, but it is actually quite traditional and accepted. I figured if it was good enough for Shakespeare, it is good enough for me. If it was not for writing in public, I probably would not have given any consideration to this topic.

The more that I write, the easier it gets, in some ways. I'm fairly disciplined now about keeping track of ideas whenever they strike me, noting them down and regularly reviewing them, whether or not they will ever be incorporated into an article. I find the articles that start from some programming examples are the easiest to write, at least once I've spent the time to refine the code samples. It takes me a long time to refine my ideas though. I'm particular about choosing my words and I tend to edit and read and re-read and edit again. I'm not sure if I'll even get a whole lot faster at the actual process of writing.

Refining Ideas

I think by far the biggest benefit to writing this blog has been in collecting and refining my ideas. A blog article is an opportunity to explore a topic, review some of my favourite references, including articles, books, podcasts, and presentations, and deepen my understanding. When I set out to write an article, I don't want it to be a sloppy rant or an attempt to prove how much I know about something. I want each article to be well thought-out and I want to be able to look back on it in a few years and still appreciate it, even if it is no longer relevant or I no longer hold that opinion.

Most of my blog posts start with a reasonably well-defined central idea. The bulk of the work is in exploring and refining the supporting ideas. When I'm writing an article I usually spend a lot of time trying to find out how others might tackle the same problem or approach the same idea. It is a way for me to welcome new ideas and new influences, in addition to reviewing some of my favourites. I feel my blog has become a nice journal of my thinking, experiences, and influences and it has been enjoyable to look back on it over time.

Sharing Ideas

I have been using my blog more and more at work to share ideas with my colleagues. Recently, a colleague of mine was about to conduct his first interview and he asked me "What questions should I ask?" Of course, there are many answers to this question and they certainly depend on the position the interview is for and the experience of the candidate. Becoming proficient at interviewing, like most other things, takes practise. In his first attempt, my colleague will almost certainly not deliver a particularly effective interview. I have written a few articles reflecting on my experiences as both an interviewer and an interviewee. Rather than suggesting a bunch of question to ask, I referred my colleague to my blog so that he could consider my opinions on interviewing and, as much as anything, to provide references to the thinking of others that I've found influential.

Another colleague of mine was developing some rather complex system tests for a database application. The orchestration involved in each test was 100 lines of code or more and the majority of it had to be repeated for each test in the test suite. These tests were also challenging because of the timing involved waiting for various operations in the distributed system to complete. I was able to point him to an article on my blog that demonstrated some techniques that I've used for reusing code across tests, while at the same time making tests faster and more reliable. It turns out that this approach worked quite well. He was able to develop a suite of effective and deterministic tests that run in under a few seconds. The tests are easy to follow and with these building blocks in place, it was easy for him to add new tests when he added new functionality to the application. I think this has been the single most rewarding experience I've had with my blog to date.

Conclusion

It takes a lot of time to write a quality article each month and it is hard to balance this with other things that I want to do like play bagpipes, read, spend time with family, exercise, or just relax. It is certainly a lot easier to enjoy a beer and watch hockey than it is to toil over a blog article for a few hours, especially when my day job also involves being slouched over a computer most of the day. But I think maintaining this blog has been worth it. I started it mostly for myself and I've enjoyed reviewing a number of the articles I've written to remind me of ideas and references. If someone else enjoys an article and finds it valuable, or my blog leads to a new opportunity that I would have never anticipated, that's a bonus.