Shitposting as a Learning Style
Everyone learns in different ways. Some methods work super well for one person, while someone else just doesn’t “get it.” While most of us know this intellectually, it’s easy to forget that other people aren’t all like we are. I’m speaking in this case, of course, about myself.
Here’s an example of what I’m talking about. For a while I was very down on the idea of vendor certifications, such as the AWS Cloud Practitioner cert; I’ve since radically changed my view on them. The original reason for my distaste was that cramming for a test never was a great way for me to absorb and retain information. I thus viewed getting certifications as exercises in short term memory retention, which is less than useful in the context of our industry. Guess what? Not everyone learns that way!
If you put me in front of a YouTube video, or into a physical classroom, I will zone out and struggle to learn anything. (Fun fact: the real reason I livetweet conference talks with dumb jokes is that it forces me to pay attention throughout the talk. Don’t tell anyone…) Reading blog posts often leads me down the same path. Occasionally talking to someone deep in the weeds about what I’m working on leads to a breakthrough; other times I end up feeling like I haven’t done the required prerequisite reading and most of the conversation doesn’t land for whatever reason.
Personally, the real method I’ve found that leads to the best learning outcome for me is using it to build something. For shitposting.
Wait, what?
Last week I found myself confronted with an interesting problem. For background, the ridiculous camera I use for my video work isn’t in fact plugged into my computer at all; it’s got power, an SSD plugged into it, and a gigabit network connection, but there’s no video feed coming off of the camera directly. The video is instead streamed over the network for use on my computer, plus for my YouTube vidoes I record natively on-camera. Bear with me; this is going somewhere.
I don’t want to have to fiddle with the camera directly; it’s carefully focused and inside of a teleprompter enclosure. As luck would have it, it has an API, sort of. What I basically wanted was a way to control the thing via the Elgato Stream Deck; in other words, “push a button, it starts recording video. Push it again, it stops recording. Push a different button and it syncs the files on the camera’s SSD to my computer.”
If I need to make a few distinct and frustratingly obscure API calls by pushing a physical button, that means I need a script of some sort. My programming language of choice most days is “crappy Python” but let’s be clear: my computer is a disaster fire of different Python versions and virtualenvs, and I haven’t found a great way to ship today’s Python setup into something that’s going to work sustainably across my succession of computers from year to year without a whole mess of fiddling. I briefly considered using PyInstaller to generate a static Python binary, which after reading the documentation and a few experience reports on the internet, I considered to be a very funny joke–one right up there with “How to Build Packages for Debian.”
Add in the fact that I’ve been meaning to kick the tires on Go for a while, and this seemed like a great excuse. I had to make a small handful of API calls to a very basic endpoint, I wanted to package this up solely as a command line utility, and given what I’ve observed about Go’s ability to cross-compile and output a static binary for basically any OS or platform, it seemed like as good an excuse as any to dive into it.
How I Learned Go
I got halfway through the slides for the excellent OSCON 2017 workshop on Building an Awesome CLI App in Go by Steve Francia and Ashley Willis–specifically the part where they discovered a Go CLI app framework called Cobra, and then tossed the slides aside and went back to my tried and true method of learning a new thing: sheer brute force, again in the service of shitposting.
To me, the only thing that makes a language, tool, or SaaS product “stick” is using it to solve a problem. Firing up a “learning Go” tutorial covers a bunch of stuff that virtually never aligns to my vision of what I’m trying to achieve. Instead, I broke it down into a few distinct tasks.
“I want it to make a GET request against the following URL. Time to Google how to make an HTTP GET in Go” is where I started, and that led me down a rabbit hole where I learned a bunch of things. Among them were “it’s super easy to hit an API in Go,” “this is how third party dependencies work in Go,” and “if you don’t enjoy pain, call the language ‘golang’ when you’re searching since a bare ‘go’ by itself is completely unsearchable.”
It took a couple of fits and starts, but within 90 minutes or so I had a working app that I’ve put up on GitHub for you all to make fun of.
The Takeaways
There were other options available to me, to be sure. I could have found some extension for the Stream Deck that let me make bare HTTP calls against an endpoint. It would have been faster for sure, and as far as “being able to pass this on to others” goes, please! I don’t imagine that there are more than a dozen people on the planet who use this particular camera as a webcam (there are WAY better options for that; I have this camera primarily for Other Things) and have this specific requirement that I do. The odds of anyone else ever using what I’ve built are slim.
But I came away with an understanding of how Go is structured as a language, what the toolchain looks like, how to turn stuff I copied and pasted from Stack Overflow into something that will compile, and more. This won’t be my last time using Go for something interesting–and this certainly won’t be the last time I have to learn something new.
For the first decade of my career I was convinced that this learning style was bizarre and not how most people approached things. Maybe that’s true, and maybe it isn’t–but if it’s how you learn, I invite you to join me in shitposting your way to learning new things while having a fair bit of fun along the way.
