Welcome to DevChat #9!

Here's what's on deck:

  • Onboarding versus longboarding
  • Conflict-free hotkeys

This is an archive of a DevChat newsletter. To get the next one early, and in your inbox, sign up! To read past issues, head to the archives!

Onboarding vs. Longboarding

Because of the tools we've made the center of our technical ecosystem, we're constantly bumping into this common theme:

  • We're using bleeding-edge versions of every tool, because the bugfixes and new features in those versions are worth the risk of instability.
  • We're constantly running into edge cases that seemingly no one else has seen before, and have to solve these ourselves.

How did we end up here?

We could pat ourselves on the backs and claim that it's because we've become such experts in our tools, and are doing such amazing stuff in games, that we're pushing the envelope and this is the only possible outcome of that fact.

But... we can't possibly be that special. The number of people out there making games and webtech, building pipelines, and practicing DevOps principles is huge. There are definitely a lot of people out there who know far more than we do about our tools and the kinds of problems we're solving. So why do we keep finding ourselves feeling like there's no one out there to help us?

There is a lot of nuance here and no clean, simple explanation. But there is something foundational at play: what I'm going to call the "Onboarding/Longboarding Problem".

In short, the Onboarding/Longboarding problem is that you choose long-term paths (longboarding) based on initial, limited knowledge and experience (onboarding). By the time you have developed the experience needed to truly evaluate that choice, you've not only already made it but are deeply invested!

You can't know the full features, nor the full limitations, of something until you're an expert in it. To become an expert in it takes time and deliberate practice but, more importantly, requires that you decide to invest the time in the first place.

Everything out there has an alternative, so why choose one over the other? There are two major factors: social proof and the onboarding experience. All the social proof in the world can't overcome terrible onboarding. Further, social proof is a bad guide because almost no one out there will be an expert in even just two of your myriad alternatives at the same time. Why would you follow the advice from experts in one thing about the other thing?

So then you get faced with choices: GameMaker Studio, Unity, or Unreal (or any one of the hundreds of other game engines)? Node.js or PHP? Vue.js or React? Mac or Windows?

When Seth (our game programmer) got started making games -- uh, a decade ago? -- he didn't know anything about the discipline. He didn't know how to program, wasn't an artist, and hadn't the foggiest idea of what it would take to build a game from scratch. He'd tried to learn programming at various points, and tried to find self-teaching materials about making games, but overall the onboarding was terrible for the games industry.

But then one of those life-altering happenstances: our other brother (Sam) ran a game jam (a 48-hour event wherein teams make an entire game). Why did he do this? Because he was working for a weird little startup during his summer break from college, and they wanted him to.

He had trouble getting people to show up for the event and thought, "Dang, it'll look bad if no games come out of this thing." So he decided he'd make one, too. He had never made a game, though he'd had some introductory exposure to web programming. Knowing his limits, and that he only had a few days to prepare, he went searching for tools that would let him make something quickly without having to become an expert. He found GameMaker Studio.

And so Sam made a game in a weekend, because the onboarding experience with GameMaker made it possible for him to do that. Knowing that Seth had always wanted to make games but couldn't find an approachable path forward, Sam sent him a link to GameMaker.

And thus, our history was made.

The onboarding experience that GameMaker provided, specifically to a complete game-making newb, made it one of the very few tools that Seth could have decided to use to make games.

Here we are, something like a decade later, and Seth is a true expert in making games with GameMaker. Further, we've invested enormous time and resources into building a full ecosystem around the ins-and-outs of GameMakers capabilities and issues. The cost of switching to another ecosystem would be staggering, and so even if we could afford it we'd only do such a thing if it was obviously worth putting game-making on hold for, oh, a year while also trying to find a way to keep our existing games viable within a tech ecosystem we'd eventually abandon...

In short, the pressure to longboard within the tech ecosystem that Seth chose a decade ago when he knew literally nothing about gamedev is enormous.

Okay, so that story brings us back to the Onboarding/Longboarding problem. Seth could not possibly have known about the kinds of issues he'd be running into ten years later as a GameMaker expert when he adopted GameMaker. He chose it because its onboarding process was exactly what he needed at the time.

Aside from some frustrating limitations of GameMaker, the biggest problem we face is just how small the community is. In any community, the proportion of people you can lean on for help, or hire, or who can help you lobby the engine maker for common needs, is going to be small. There are always far fewer people trying to make games for a living than doing so as a hobby, and within that group far fewer still who are making games with similar technical issues to yours. So the smaller the community is, the harder it becomes to find those proportionally rare comrades. Especially when your technical needs are truly rare.

A few times a year we find ourselves re-asking the question, "Do we need to switch to Unity/Unreal?" As I noted, the cost of doing so would be horrifying, so practically the answer has always been and will continue to be a solid NOPE. But even beyond that, we'd yet be making another decision in the absence of true knowledge about what it would mean to be an expert in the new engine. We'd inevitably find ourselves in exactly the same situation, just with different details.

I'm dealing with the same thing for Rumpus (our webtech) right now. I chose to use Vue instead of React for the front-end (the part you see when you visit bscotch.net) because it was far more fun and accessible back when I learned just enough of the two to make an "informed" decision. But again, that decision was informed by the onboarding, not the longboarding.

And here I am, having just upgraded from Vue2 to Vue3 and converted it from vanilla JavaScript to Typescript, now stuck with broken Intellisense and some bugs that are giving me a super hard time. I'm stuck at another proportional intersection: a Vue project within a full-stack mono-repo (if that means anything to you you'll be surprised that it matters, but it does!), using Typescript, running from within a Docker container, using VSCode as my editor. The Vue community is small enough that there just aren't many people out there in the same situation as me, and even finding experts to hire as consultants to help solve my problems is a huge challenge.

As with GameMaker, I'm invested. I've already built a sprawling website in Vue. To change tech stacks I'd have to first learn enough React to match the expertise I have in Vue, so that I would know that I could port every feature. And then I'd have to do the actual work!

And after all that, I'd eventually find myself as a React expert, completely bummed by some set of issues within that tech stack, wondering if it's time to switch to whatever the coolest tech stack is at that time...

The cherry on top of this problem is that the world changes around you while you develop expertise and your long-term decision deepens its roots. No matter how appropriate a decision was at the time, its current alternatives could appear to be preferable at any moment.

So what's the summary here? I guess it's that the Onboarding/Longboarding problem is a statement of an intractable fact. You can't know what will happen in the long term, and you can't know enough about most things to make a fully-informed long-term decision about them even in the short term.

Probably the most useful realization stemming from this fact is that it probably is not worth swapping one long-term decision for another after you've found the holes in the first one, unless your investment is still low at that time or the gains are obviously enormous even after acknowledging the limits in your ability to evaluate such a belief.

I assume everyone has struggled with the long-term consequences of partially-informed decisions. How have you managed those consequences? If you made the gamble on cutting one investment for another, how'd it go? Tell me all about it!

Conflict-free hotkeys

I was having some mouse trouble last week, so I needed a new one. A feature I wanted to make sure that the new mouse came with was extra and re-mappable buttons. So I got a Logitech MMO mouse. One of those goofy things with 12 buttons on the side.

And controllable LEDs. I'm not a barbarian.

When it arrived I was pumped to map one thing in particular onto one of its buttons: un/mute for Discord.

One of those minor nuisances I'd been dealing with since the start of COVID and work-from-home was keeping track of whether I was on push-to-talk, voice-activity, and within either of those muted or unmuted.

I hadn't mapped un/mute onto a keyboard shortcut because the tools I use (in particular VSCode and its extensions) have so dang many mapped hotkeys that I couldn't find a keyboard combo I was confident wouldn't eventually do something really bad.

I needed a conflict-free hotkey.

You know those F1 - F12 keys that Windows keyboards have (maybe also Macs...)? Turns out there's also F13 - F24, though most keyboards don't actually have those.

I figured that F13 - F24 would be free of hotkey conflicts. After all, if they weren't even available to most people why would any software map them onto anything?

So I mapped F24 to one of my mouse buttons, only to discover that Discord has that as a hidden hotkey for minimizing a fullscreen video call... but Ctrl+F24 seems to be working just fine!

Long story short: if you have some extra buttons laying around on your keyboard or mouse, and a way to map them onto other inputs, using Ctrl+F13 through F24 just might be a safe zone.

Have any hotkey pro tips? Please share!

Until next time

That wraps DevChat #9!

I've been having a great time hearing from readers. If you haven't said hello, please do!

Share with others by forwarding, or link directly to the archived post.

Have a great week!

❤ Adam