Learning as Performance
And as a teaching tool
No, the cat did not jump in afterwards. It did try to eat a floating leaf however.
As I mentioned in last week’s newsletter, I’ve kicked of a giant teaching/learning project involving teaching my UX teammates how to build things in The Cloud, something they, as non-engineers, would never be able to do without significant amounts of help. The goal being to give them a realistic taste of what goes into engineering something.
I won’t get into the weeds about the specific toy project we’re building, but it’s more complicated than simply “spin up a cloud VM and run Wordpress on it”. OK, more simple than that example, but more complicated than a mere VM. It’s got machines generating fake telemetry, queues handling data ingestion and processing, then finally storage and ingestion into databases, before finally a display on some kinda web app. For a group what literally has never used the command line before, it’s Hard Core stuff, even if we’re going to use off-the-shelf parts as much as we can.
The biggest problem we currently face is how we share very common ground in terms of engineering knowledge. We don’t have the time to give a full lecture series on things like virtual machines, networking, servers and protocols, so we’re using the discussion about what we’re building as our forcing function and topic guide.
The lack of common ground also means that when explaining things, we have to go way into seemingly unnecessary detail, because we can’t assume that everyone has enough context to follow along.
So what’s the current plan?
Learning in Public
People working within the UX space are all pretty familiar with the concept of user testing. Put a user in front of your product, and by using a mixture of observation, questions, and prompts, you see how a user works with your product, where they get stuck, get a sense of what they were expecting, and what was going on through their minds.
So the idea that started all giant project was to simply self-narrate a user test on myself as I bumbled through figuring out a product to complete a task. While I’m not a particularly good or experienced user test moderator, I do have a decent sense of what UX researchers and designers are looking for, what sort of information would help understand what was going on. Things like what mental model I was using, what I was expecting, how that didn’t line up with reality, etc.
Those notes became a sort of learning journal, which I can then clean up and give to people to read so that they can understand the whole journey of the process, coming long for the ride in my brain so-to-speak.
I’ll include a (slightly contrived) example at the end for those curious.
Surprisingly, I couldn’t find a name for this method (which probably is a reflection of my lack of knowledge of pedagogy, this is most definitely not a new idea). I searched and the closest thing I found in educational literature was mentions of “reflective journals”, but they’re a tool for students to reflect on their learning process, while my goal is to use the journals as a kind of teaching artifact. I asked people on twitter, and Gary Chou calls the process “working in public”, which I like. I definitely would use the phrase if I were doing something I’m familiar with, like analyzing a data set, in the open.
So in my particular variation, I’m learning in public. I have no idea how to run and set up an nginx installation, but I think I can do it and I’m gonna find out how. I’ll probably make embarrassing mistakes while doing so, but I will overcome the obstacles, learn something, and get it working.
Failing in Public
Probably the hardest part about the whole learning in public process is that it involves failing in public in a pretty spectacular and self-documented way. If you intend to be honest about the story, there’s no room for hiding embarrassing missteps and revising the past here.
For example, imagine I was learning how to set up PostgreSQL and, in my ignorance, follow some poorly written guide on a sketchy forum that taught me the wrong security practices while setting it up. I get a functioning system database running, but wind up exposing a default-password root login to the open internet. That journal will be recorded and saved for others to see.
Sure, part (perhaps most) of the blame is on whatever wacko guide that got written that led me astray, the remainder being me doing poor homework and following an unreliable guide. But while this situation is almost unthinkable for such a popular and well-documented product like PostgreSQL, it is entirely possible for more obscure products that have weak communities.
Hopefully, I learn more later and correct my security mistake and update the journal, but if anything that makes it a bit worse because I’d have to admit I was very wrong previously. For many people who would prefer to cultivate a positive image of themselves in public, this is uncomfortable territory.
But at the same time, these mistakes are in my opinion the most important part of the learning process. This is where mental models are tested, found lacking, and replaced by something better. This painful discovery process is how we all learn to avoid similar issues in the future. As a UXer who needs to understand what users are going through so that I can prevent users from going down bad paths, such mistakes are also very useful research material.
In my private test run, it took me *17* pages of text and (large) screenshots to create and upload a static web site to Google App Engine, something that only takes a handful of steps in the official documentaion. I had to learn how to use bootstrap, explain setting up DNS and SSL, on top of just throwing an html file into the command line, but still, it’s really long for the amount of technical work that I did.
For my UXer audience, I think this hyper-detailed output is perfect for them, maybe after some light editing for clarity. They’ll be able to draw parallels to things that they’re building at work and apply what they’ve learned. I’m a bit unsure whether such raw material is useful to a broader general audience that might not have the patience to want to know ever single step.
Despite the verbosity, I personally love the idea of seeing how experts do their work. I’ve also never seen examples of experts explaining how they learn a new thing. But I’d binge-watch/read that stuff if I ever find it.
Maybe someone out there agrees with me? Hopefully?
An Example Journal
Here I’ll do an abbreviated example of a journal for illustrative purposes. It’s actually a task sitting on my todo list, but simplified a bit.
Task: Figure out how migrate a domain that’s being hosted so I can still use it for email, but not have to use the current hosting service.
Tech requirements:
Use email addresses from this existing domain I own and have them forwarded to gmail which would be the primary client
Also need to be able to send email as that account once or twice… a year.
Be super cheap. Free is ideal. We barely use these emails.
Lots of bonus points if I never have to maintain a frickin’ mail server. Because, no. It’s 2020 and I don’t have time for that. Just no.
Various paid options
Google “use custom domain with gmail” to see what my options are. While I do have another host that I could theoretically send and forward mail with, I don’t want to run a mail server and have to worry about securing it as well as having
Since I’m using gmail anyways, G-suite is the current paid option. I still remember when G-apps was a free thing that could be used for one off domains like this, but that’s long gone. $6/user/month isn’t TOO expensive if I actually used the email with any regularity, but obviously it’’s not worth $72 a year to me. Technically, $72/yr is still cheaper than the current cPanel-based host I have attached to this email, but not by much.
Browsing, around, the majority of the top google responses involve using the email forwarding service from the domain registrars, godaddy, etc. I should check if my domain registrar offers a similar service.
Answer is: Namecheap does have a forwarding service provided for free. But there’s a catch. It’s just a generic receive forward through a virtual mailbox, there’s no actual SMTP mail server capability included, so I can’t SEND as that email. It’s been years since I set up gmail sending aliases, so I check gmail’s documentation on the whole matter. Yup, it does need some form of SMTP to send. So this isn’t good enough.
Namecheap’s email SMTP service isn’t expensive, at $1/mo+$0.41/mo for extra emails. While it’s not free, it’s close enough. So if I’m going to do a paid option, I can use this.
But, just in case, is there a free option I’m overlooking?
There’s this rather involved guide that uses a sending service called Mailgun. But I don’t really want to have yet another service of dubious origin =\. Let’s file this under “possibility”.
Check Sendgrid, since I use them for sending email for a site I run. This isn’t their intended use case. There might be some roundabout way to shoehorn that functionality in, but it’s not obvious and maybe a TOS violation. Scratch that.
Finally, I could run my own MTA like postfix on my server instance. Even if I make gmail pull the messages off later… but looking at this guide… I’m pretty sure I’m in over my head if I did.
Actual implementation
[After laying out those and possibly other options, I’ll pick one, explain why, then dive into detailing my adventures in failing to get it to work.]
…
Hopefully you get the gist, obviously the journal will drag quite a bit more. It explicitly states goals, lays out options and my personal preferences. Hopefully it’s able to impart a core reality about engineering that isn’t obvious to people on the outside—that there’s more than right way to do things, and we might make pretty serious choices for completely frivolous reasons. It’s always a complicated balancing of constraints, preferences, trade-offs and mental stamina.
Even the calculation we often do of “do I risk spending a lot of time learning New Tech to do it a certain way more directly, or use a more complicated way with tech I’m familiar with”, are hard to express.