…and other pompous comparisons I make.

After the ‘epiphany’ described in  “What developers can learn from Speedrunners?” I began examining my routines, tasks, and general stuff I do, the first and most obvious thing to improve was my typing speed. I wasn’t a slow hunt-and-peck typer by any means, but I wasn’t the fastest either despite typing every day, whether writing e-mails, sending chats, or coding. Yet, I had gotten too far purely on autocompletion and copy and pasting. That largely served everything that I ever typed as part of building software. The second and matching ‘}’, ‘]’ and/or ‘)’ would be inserted any time the first one was typed by the IDE of choice for whatever language I was writing that day. However, when I really looked at how I was doing it, I realized that my brain worked faster than my fingers; therefore, my fingers were holding back my thoughts whether it was writing code, Slack messages, or documentations.

When I measured my typing speed via Epistory(a game I had owned, but hadn’t consistently played much recently) I was rated at about 23 WPM. It may not be the best or most accurate way to measure my WPM via a game. Nevertheless, as anyone who is a typist knows, that is pathetic. So, I began typing every morning and before bed, mostly playing Epistory at that point. I started improving, but I was tripping over my fingers using techniques and fingering that has mostly been the same since the days of typing messages into MSN messenger. Mind you, I have written an entire novel of roughly 120,000 words. It was finished in 2011; if it was not for a bored friend and a scanner, I would still be typing it to this day! Jokes aside, I found a “proper” typing chart. Making a conscious effort to hit the keys with the fingers prescribed by this chart. For a few rounds, I lost significant speed typing, but once the new muscle memory started taking hold, I started seeing the numbers rise. 23WPM became 27WPM and 32WPM. I saw a few spikes and dips, but, generally, my WPM was trending upward. Can you guess what also increased with my WPM? Wrist pain.

Unfortunately, I am a broad-shouldered individual and proper typing hand position requires my hands to be turned outward not allowing my wrists and arms to be aligned even with elbows pressed firmly against my sides. I had previously tried to solve this with a Microsoft Natural Ergonomic Keyboard 4000, but after having a third failure—I’ve been told they’re prone to moisture problems—  I switched to my first mechanical keyboard and just dealt with it. As I said before, I was not typing as much before so the occasional soreness was completely bearable especially as someone who experienced years of it working in commercial kitchens. When I realized my desk layout was limiting my ability for my now old mechanical full-sized keyboard to be centered, I switched to a 10-keyless keyboard. I never used the number pad and suddenly, it felt like an acre of room on my desk for my keyboard, mouse, and multiple notepads.

It was at this point that, by chance, a random Facebook posting warning for a scam ad for an interesting-looking(and not a scam) keyboard called a Dygma Raise. It was mechanical, RGB, and it SPLIT IN HALF. The cherry on top was that it was available with Cherry MX brown key switches. For the uninitiated, Cherry MX switches come in a variety of colors with differing feel, and browns are the keys that click when they register without everyone within half a mile hearing your typing. I have seen several permutations of these, but no keyboard had the option for “All ofthe above.”. It seemed like it was perfectly what I needed, but at an eye-watering price of $289.00 when configured with my lovely brown key switches, I balked, partially due to our saving for a house and partially on principle. I had just bought a $100 tenkeyless keyboard; I don’t need this. However, I kept pining for something that could remove the pain, and my wonderful wife convinced me to take the plunge, saying “it is for your health.”  

I have had my Dygma Raise for a few months now, and I love it. Not only did it banish the pain, but it is also highly customizable— the Steam Controller of mechanical keyboards. With it, I have continued practicing. Typing of the Dead, Epistory, and Nanotale have been ways to both have fun as well as practice typing.  TypingTest.com has also become a regular resource. After persistence and consistent practice, I tested my typing speed to see I had reached 52 WPM— over double my original typing speed. I have reached the point that the limit of my typing speed during regular activities is my thoughts. It is fantastic to be unhindered by my fingers. My general productivity along with my daily output has substantially improved, and I no longer experience the regular soreness that was in my wrists. 

Resources

https://www.typingtest.com/

https://www.dygma.com/

http://www.ergovancouver.net/wrist_movements.htm

Typing games

The Typing of The Dead: Overkill on Steam

Epistory – Typing Chronicles on Steam

Nanotale – Typing Chronicles on Steam

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.”

For a long time, I believed blogging above me. Why would anyone care what I have to say? There is a point in software where a person, whether you call yourself a coder, developer, programmer, or engineer, how much they do not know.

There is a curve of self-awareness plotted on a graph whose axes are ‘what a person knows’ versus ‘what a person thinks they know’ that describes what is often referred to as the Dunning-Kruger Effect. At the beginning and first height of this curve, there are novices who think they know everything. They’ve conquered a few trivial challenges, and now they believe themselves to be Experts. I have a few instances where I was right here. They are not experts, and neither was I, much to Future Me’s chagrin.

Once a person gets some experience, they understand how vast the world is. If they are smart, they will begin seeking out real experts and more advanced resources. I spent the last few years here where I have been hoarding as many bits of information I could though at a rate a lot faster than I could actually consume and internalize them.

Nevertheless, I have persisted. At some point in my discussions with other engineers, I was beginning to understand that some of my ideas and insight were unique and interesting; I had started climbing the other side of the Dunning-Krueger curve. While I am still learning many things, I have come to realize that I have five years of experience and knowledge that can help others; I have a responsibility to share ideas, struggles, and the occasional epiphany as so many who indirectly helped me in my career had done before.

While I do not want to blog for the sake of blogging, I hope to share some interesting if rare insight into topics (such as concepts that I got hung up on and what cause those concepts to click) as I continue to explore the seemingly infinite realm of Computer Science. So, look forward to my first article tentatively titled, “What can Programmers Learn from Speedrunners?”