Being generally curious, I have a variety of subscriptions on YouTube, including late-night comedy, civil engineering, and game design. I do not recall the first video by Daryl Talks Games that I watched; however, one literally changed my life. This video was one in a series called the Psych of Play which discusses topics of Psychology, video games, and the relationships therein. While I am writing about my application of the ideas discussed, he did the in-depth research, so go watch his video first. I’ll wait: How Speedrunners Make It Look Easy | Psych of Play
Admittedly when I first watched the video, I was half-listening, doing something unrelated when it came up on YouTube’s autoplay playlist. What caught my attention was the summation of the two on-screen quotes which was, “Practice until you can do it right, then keep going until ‘right’ is second nature.” Inexplicably, I was transfixed by the sentence, replaying it in my mind. I started thinking about how many things for which I had accomplished the first part, and for how few things I had accomplished the second. Something changed almost immediately within me. My definition of what success meant to me was shifting as I attempted to refocus on my previous activity.
The key concepts tumbling in my brain were automaticity, overlearning, repetition, and chunking. Many of the examples were of sports and music, so how does that apply to a programmer/developer/engineer? Software is complex; developing it requires creativity, insight, and problem solving, not repetition. In fact, we attempt to avoid repetition with the common refrain of, “don’t repeat yourself.” We’re not overlearning and chunking our coding skills so that you can execute a hyperdash into a spin jump to save a few frames. What does that have to do with the world of solving complex and interesting newproblems with code?
Novel problems require novel solutions, right? Yet, the idea of design patterns already exists for solving common software design problems. Nevertheless, I went back and rewatched the video with my full attention. Automaticity. Overlearning. Repetition. Chunking. I was intrigued by these concepts and how I might apply them to further developing my career, focusing on automaticity and chunking with overlearning coming with repetition.
The definition, from Wikipedia: “Automaticity /ˌɔːtəməˈtɪsɪti/ is the ability to do things without occupying the mind with the low-level details required, allowing it to become an automatic response pattern or habit. It is usually the result of learning, repetition, and practice. ” The most obvious target of automaticity was typing every day. Increasing my typing speed might have an outsized effect on my day-to-day productivity, but I also wanted to form better habits and break some bad ones.
For chunking, we stop thinking about exactly how to write a for-loop or typing “i f ( c o n d i t i o n ) { }.” We think to check this condition and an if-statement comes out. What about something more complicated? From experience, I have discovered there are building blocks of problem-solving that can be reused. Obvious examples are iterating over a map or other data structure, but what about multiplying and dividing a number by its base to shift it left and right respectively? Certain chunks are difficult to devise on the spot and under pressure whether it is during an interview or a looming deadline. Less time reviewing how to do something means having more time for productive planning and doing.
One might think these would all naturally happen over time just by doing our jobs each day. Yet, in 5 years of my career as a consultant, I rarely got to build a thread-safe class from scratch at work. Nor did I often make anything more than simple network calls. Do not misunderstand me. I have a breadth of experience spanning embedded devices in on-road cars, desktop applications, mobile apps, smart home devices, and more on-and-off-road vehicles(again, embedded devices); what I often missed was depth. As a consultant, the priority was getting the next feature working, adding the depth portion to an ever-growing backlog of skills I wanted to explore more thoroughly. Eventually.
I practiced until it was right, but I did not overlearn. I would use a skill or concept once or twice to get a feature working and not use it again for another 6 months. By that time, I had often forgotten some of the key aspects, triggering an all too common, “what am I missing?” I would then have to review it, relearning very quickly but still wasting valuable time when the ideal is just recalling the method. I do not view forgetting to be the problem so much as but that I was satisfied with that way of going about my time in my career for so long.
I am generally a fast learner, and I had been successful by most measures, raises, praise from clients and management, and not working 80 a week to meet deadlines, but I regret being satisfied with ‘good enough’. I do not know with certainty why that sentence after years of doing as I had done triggered such a realization, but suddenly, I could no longer accept being that way. It has not been a secret that I have interviewed multiple times at Google. After the last time of being rejected, I had accepted that I had been ‘successful’ in my career, and Google just was not right for me. Perhaps it was for that reason, my mind thought, “Do you think Larry Page and Sergey Brin reviewed Http, Graphs, or Network Theory when they invented PageRank. Almost certainly not.” I later learned that the basis for PageRank started as Larry Page’s dream. Literally.
Even outside of work, I remembered all the time I had wasted having to review concepts as I began digging into a more advanced component. Sometimes it was how precisely a language worked versus another. Other times it was not immediately seeing how fundamental data structures I had learned— but to which I did not have first-order access— could improve a system or how bad the runtime of a piece of code was regardless of it being on a second thread. Perhaps the worst of all, the more time we have to process or devise how we are going to solve a problem using tools we already used previously, the less time we have to do things we really want to do whether it be more time to work on a cool new feature or more time with family and friends.
I accepted that my path to overlearning, automaticity, and mastery would not be simple. My daily work with specific topics, concepts, and tools was sporadic, so I could not rely solely on my day-to-day work, no matter how much I focused, to gain the level of mastery that I now desired. The more I reflected the more holes I found or things I had forgotten that I wanted to learn. In addition to the skills I wanted to acquire, I faced personal inadequacies I needed to address if I wanted to get there from here e.g. wasting time, distractions, and indecision. For more on the books and techniques that I found helpful and more detail on the specific actions I took to kick off my journey, watch for my next post tentatively titled, “Down the Rabbit Hole: A Journey to Automaticity, Overlearning, and Mastery.”
JD Lowe 