Very early into my professional software development career, I found a gap in a very specific skill. I lacked the ability to convey meaning about: a poor design, an unclear requirement, or un-optimized chunk of code. The ability to express these thoughts coherently was difficult.

This was something that I had not learned about in school, nor did they set an expectation for me encounter this problem. Yes, learning how to deliver a prepared speech was covered. However, being able to quickly convey meaning on the spot was not.

This manifested itself as have a vague feeling that something was not optimal/clear/precise and I was not able to pinpoint the exact issue. Which in-turn makes it almost impossible to convey this meaning to another person. How could I express something to somebody else if I myself do not full understand the issue?

Looking back, I think this might have been an artifact of me being at the very beginning of my programming journey. Where everything was new and fascinating and I wanted to do everything right! All without having the experience, guidelines, or general heuristics.

Accidentally Breaking The Communication Barrier

The Consumer

This story takes place around the timeline of where I just started to discover that I can actually apply myself and succeed. Having applied this work ethic to the last half of my higher education career, I wanted to continue to have it after school as well. Meaning the goal to make myself better at my current career was crystal clear. How that would be turned into reality was not. It felt like there was a missing piece to this self-improvement puzzle. Something which would bridge the gap between where I was now and to the place I wanted to be. If I just had that next big project to work on. An investment of time which would yield honed career skills given enough time and effort.

In the end, I did come up with an idea. Which was, "I am going to consume as much information as I possibly can." Thankfully, there are things that I enjoy about my new current field of work. When the topics are interesting, learning becomes a positive side effect instead of being the primary objective. A flashbulb memory occurred shortly after the discovery of the Software Engineering Radio podcast. There is this vivid memory of the feeling "I do not know anything, and the amount of information out there, will take years to finish." It was like I was positioned at the bottom of mountain and the only way up was a long winding trail. Which would take forever to make any progress on.

I interpreted this feeling as a hint that I should double down on the ability to consume information. Refining the skills to become better at listening to what other people have to say. Having only a limited amount of free time between commitments such as: work, sleep, exercise, and eating, required me to hone a specific skill. Which is the ability to densely pack in education and still be able to retain it within a small time-slot. Thankfully, we live in a world with technology and people who like to speak words about interesting stuff.

Therefore, most of the information I have consumed has been via audio. Ranging from videos lectures, audiobooks, and podcasts. The vast weight of knowing that I would probably be spending years to get to where I want to be was heavy. Though it was not soul crushing, yet. Consume faster quickly became part of my knowledge hoarding goal. Taking in information was all I had to improve myself with at the time. So why not be really good at that?

Thanks to technology, audio players have the ability adjust the rate to which information is thrown at me. Something that I picked up during my video gaming phase was how to acclimate to higher control sensitivity. Most video games allow for the adjustment of the mouse or joystick sensitivity. Having a high sensitivity enables the ability to react to in-game events quicker. In my case, this would enable me to quickly point and shoot. Nothing like snapping a full 180 degrees and destroying the opponent behind you. In order to reach the point where my movements where quick, I learned I could incrementally work my way up the scale. Each day I would start with the sensitivity of the mouse at a level higher than I was used to (a bit uncomfortable). Then I would spend matches getting used heightened feedback system. Overtime, once I felt like I was starting to get the hang of it, I would then bump up the sensitivity and repeat the process. This process would keep going until either control configuration was maxed, or there was not any noticeable improvement in performance over time.

As it turns out, that same process works for speeding up audio. Start by bumping up the playback speed of the audio just a bit out of your comfort zone. This new speed requires more focus on what is being said and comprehending the topic at hand. Which limits the amount of attention other tasks could be given at the same time as listening. I would repeat the process bumping up playback speed when I got comfortable. This continued until if the playback where any faster, then listening is the only thing that could be done at the time. The playback speed of x2.35 is where my limit is. Anything faster requires me to sit down and just listen to comprehend subject at hand. Which means other tasks that require less focus such as: going on really long walks, washing my car, and driving, all get thrown out the window. Which is a no-go, and defeats the purpose listening to audio.

There was a brief period of time when I would consume analog books. The biggest problem with books, is the sitting down in one place and not doing anything part. Programming has me stationary in front of a computer for the majority of my time awake. Therefore, sitting down in one place and consuming a book is difficult, because I need to move. There are few opportunities were I could take advantage of times I should be sitting down and not doing anything. Such as, when laundry is being done. Those tasks are far and few in-between though. Making audiobooks the superior choice because I can do low impact tasks while consuming knowledge.

The Producer

Somewhere this time, I felt bad about my entire knowledge-base being unoriginal. Just borrowed wisdom from others. As if all of my thoughts where unoriginal and not worth sharing. Eventually, I had a realization that the sum of everything that I have consumed gives me a unique perspective of the world. Since my time (and yours) is not infinite, I can only dedicate my attention to a small subset of information. Making the things I have chosen to consume essentially picked by the luck of the draw. This randomness forms a picture of the world that is unique to me. Until we reach singularity, where anyone knows everything and anything at a given time, I still have something to unique contribute.

Before I continue, if you also would like to read the same things I have read. Feel free to browse through some of these book recommendations. This is a distilled list of my worth-while reads (I would not recommend you junk or filler to make your reading list bigger).

No I did not originally forget the topic of this section, "accidentally breaking the communication barrier." I have just been busy setting up the stage because now I get to tell you how it happened.

Turns out the piece of the puzzle which missing was: other people's perspectives. As I consumed more and more of other people's opinions or teachings, the more my own thoughts became clear. Acting as a catalyst for me to be able to speak comprehensibly about a topic. The more I consumed, the better I became at communicating with others.

Exercises in Communication

Starting a blog

I was now hoarding knowledge others so kindly spent the time giving out and was not giving any that back. Which eventually started like I should be giving back. In turn leading me to the very beginning of my GitHub contribution streak. The very one I am trying to escape.

This is what roped me into showing others that I am accomplishing something every day. Previously, I had tried to get myself into a habit of bettering my skills as a software developer but those soon faded out. They mostly did not work because of the lack of interesting ideas or problems to solve.

It took copious amounts of information consumption to discover that I could write about my own technical experiences. I started to encounter problems that other people have not asked about. Meaning the Google machine could not give me a convenient answer. Thus https://blog.unthrottled.io was born. Marking the start of a process that would extend past this blog and consume a large portion of my attention and require truckloads discipline. I began this effort all without having any exit plan or knowing when this goal of self-improvement will have been completed.

Writing a blog was an overall positive experience. It increased my ability to write more coherent emails and convey my feelings with written words better (though editing this a year and some change later makes me wonder if I did). I stopped contributing to it after I figured out that building things with new technology was way cooler. A couple of months after starting, I had stopped writing blog posts. Trading it in for constructing applications using emerging technologies. I am fairly confident this was when I found Software Engineering Radio, because that podcast showed me a new world of neat software tools. I wanted hands-on experience with the cutting edge software which all the cool kids where using. Doing this also meant that I had to do this on my free time as well. At the time I was working for the government and we were still writing SOAP services.

This new trend of building new applications would continue into early 2018 and would quickly change when I started my next step career. After I started at my new job I was still in search of new things to learn. The new tech stack that I was working with a fresh change of pace. New technology, new challenges, and more things to learn. It was also around this time I discovered that I could combine Anime Girls & software development tools and that I should get better at math. Essentially tabling the direct dedication of getting better at consuming more information. This goal is still important and gets my attention sometimes. However, it is not my primary goal anymore.

Presenting Technical Topics

Although my blog journey reached an end, I still have a desire to share things I have learned. There is an opportunity, at the place I had just started the time to be able to present on technical topics to an audience of coworkers. The thought of giving a technical talk to an audience in-person was an uncomfortable feeling. By this time, I had learned to gravitate towards activities that make me uncomfortable, because they tend to yield net positive results. Eventually, I reached a point where giving talks felt like second nature. Even though it have become a comfortable activity, it still takes monumental amounts of effort and practice to complete.

The following paragraphs are dedicated to a small subset of topics I have presented on.

Reactive Programming

I adopted reactive programming and the non-blocking Spring WebFlux before starting my new job. This gave me an opportunity to share this emerging tech with my co-workers. I would like to think I have a good grasp on how these new and strange programming paradigms work. Explaining these new concepts is difficult using only words. I thought it might be easier if I had moving pictures to point at, so I willed https://learn-functional.unthrottled.io/ into existence. It is a website, built to explain the concepts of reactive programming using animations . It also helped solidify my understanding of the topics as well because, it uses the same programming constructs it covers to implement the animations!

Amazon Web Services

Part of the new tech stack at my new job is Amazon Web Services. Doing anything in AWS was scary (at the time). There were walls of documentation. However, in this case quantity did not equal quality. To AWS's credit, they have been doing a better job on their documentation recently. I was curious about how to host my own things, I already knew about containers and the cloud. So I started to dive into the world of AWS. After picking up some handy tips that I had not known before, I felt the need to create https://frugal-aws.unthrottled.io/ Which documents my process of how I supported my very first production. I do it a bit differently now, but it is fun to look back on that.

This lovingly crafted journal is not the first time I have wanted to escape from my software contribution streak. Back then, I thought I knew how to escape. I was confident that the answer was tracking my time in some other way, other than writing code and pushing it to GitHub. SOGoS was born, and became a pet project. It was destined to pull me out of the hole I dug myself into. Long story short, that did not work, you can read more of the story here. Anyway, in the process of building that project, I rode the struggle bus and solved some difficult problems. Like using the really cheap, but really confusing Amazon Cognito. I created some slides and gave a presentation to all who where interested. You can find the slides of the talk, here: https://unthrottled.github.io/cognito-an-oauth-story/#/

In Conclusion

I gained the ability to communicate better with those around me by listening to other peoples stories. Though I may be mimicking what others have done, it is the combination of all those I mimic that give me a unique perspective. A perspective that is worth sharing with others. Though I may not share as much of what I have learned now, I am always looking for ways to hone this skill. Take this memoir for instance, it's a bunch of words that is difficult to write and I am conveying my life story, essentially communicating.