Root

Posted on January 25, 2020

I have been attempting to motivate myself to start some sort of technical blog for at least five years now, but if someone inquired I am not confident I could say what the reason is that I thought I needed one prior to now. It was potentially just a misguided belief that I needed an online presence to be a real programmer. I no longer hold any form of that thought as throughout my career some of the most brilliant people I have interacted with couldn’t ever be bothered with being known for their craft outside their place of employment. The issue, for me, of using blogging to further my programmer cred is that it was just never a good enough motivator to actually do the work needed. The incentive and requirement structure that the notion created in my mind was poisonous without me realizing it. It caused my internal narrative to be something like: to be worth reading my writing needs to be interesting and to be interesting it needs to be novel. Which was always followed by the feeling that I have nothing novel to offer so why bother. So since I have nothing to write about I must not have anything of value to offer the wider community.

Recently all of this changed. I read two posts that heavily impacted my outlook on the purpose of maintaining a blog. Why I Keep a Research Blog was one of them. The author very effectively explains that one of the reasons he writes is to find gaps and assumptions in his own knowledge. He does this by treating his writings as a medium to teach a concept to the public, and he keeps researching and writing until he can imagine no more questions being asked. He also discusses through the lens of the mathematical community that reforging existing paths by exploring them in your own words contributes to the community as a whole. The writing does not necessarily need to be novel to be of value. Just walking along the well-worn path of those before can help others understand with a new clarity if you have described it in a way that resonates with them.

The other recent read that is shaping my thoughts on writing is Reality has a Surprising Amount of Detail. In this post the author describes an instance of him, his brother, and his father building stairs to improve a piece of property. He explains the practical trouble with cutting the wooden boards as well as constructing the steps from their component pieces to be safe and usable. He notes that building stairs is filled with fiddly detail that are often invisible to the novice. This idea seems to generalize to any situation where you are attempting to do something new. You are going to be unaware of these unobserved details and not accounting for them will worsen your results. They may even be staring you in the face but not easy to notice because you don’t know what to look for yet. Once you have noticed and accounted for them though the once elusive detail become a mindless footnote in the process. Try to recall the details and insights necessary to learn to ride a bicycle, and you will likely find it hard to do. Once you know how to ride a bike you can just naturally do it. Careful thought isn’t really required anymore since you have constructed a framework shaped by details that you have already noticed and come up with solutions for. These two properties of the details of a task have a troubling implication. If you are working on something in which all the important details are unknown unknowns, but the details you have noticed have created an framework for your thoughts then it is very easy to get stuck in a mode of thinking that is ineffectual at best. The suggested way to overcome this problem is to actively seek details in the reality around you that you would normally leave unnoticed. I think the proposed course of action of searching for the unseen details in a problem space fits together well with the previous blog’s thoughts on gaining understanding through teaching. It is often the gaps in understanding due to these missed details that you have just mentally hand-waved past that make things difficult to explain to others because you yourself do not actually understand it on a comprehensive level.

If I can successively implement the advice from these articles into a process for writing consistently that works for me I think it will help me with one other issue I have been running into in the last year or two. As a bit of background, I am a professional game developer by trade and I write C++ code for a very large publisher and studio as part of their engine team. For years the product itself was enough to keep me content in whatever tool-set and whatever process we used to produce it. Recently though I have started to look at the craft of programming at a more meta-level and found that I have a lot of interest in topics I never gave time to before like programming language theory, compilers/interpreters, and functional programming. Specifically I have spent much of my free time learning and writing Haskell. I harbor no belief that Haskell is going to strongly invade the games industry anytime soon. Still though, some of the things I have learned while working in it on my own time has made me want to find ways to inject more guarantees and clarity to the systems I am writing than typical C++ game code offers. The problem I am running into is that there is too much to learn and I have scattered my personal time in a dozen different directions trying to learn it all. I need a way to focus on one thing at a time and go deep rather than broadly. I think that if I write about things I am working on like the first blog suggested then it will force me to focus just a little bit more than I am now.

So that is what I am going to try. I don’t expect to forge new paths anytime soon on any of these topics I have planned to work on, but hopefully both you and I can better understand the surprising details of the well-worn path of those that came before much better than we do now.