Now it's a thing

This is an archive of a DevChat newsletter. To get the next one early, and in your inbox, sign up!

Three weeks, three issues of the DevChat. Missed the last one? Read the archive!

Let's get into it, shall we? Topics of the week:

  • None of us knows what we want
  • Syntax highlighting!
  • Google Stadia collapses
  • Virtual chaos
  • Cross-Posting and Canonical URLs

What are you into?

Last week I asked you which part of the DevChat you were the most interested in:

Screenshot of Twitter poll asking about DevChat preferences, with all bars roughly the same

I don't really know what to do with that, so I'll just forge ahead!

We now have syntax highlighting!

Assuming your email client supports relatively modern CSS, the DevChat now has full syntax highlighting. Now I can sling code right into your inbox.

type Amazing = string|{ooooh: "!"};

async function look( atThis: Amazing ){
  const syntax = `highlighting ${typeof atThis != 'string' ? Amazing.ooooh : '?'}`;
  // it's just so amazing

Google Stadia collapse

When I first heard about Google Stadia, my first though was, "Neat!" That was quickly followed by a second thought, "But... why?"

Stadia felt like a solution looking for a problem, and had no clear market. Google had trouble articulating the value proposition from the outset, which was made even worse as they kept shifting the business model underneath whatever market did exist.

I had honestly forgotten about Stadia until it came back into the news this week: Google has dissolved its game studios, and is pivoting its business model yet again.

The value proposition is now even less clear. How did this all go so wrong?

I don't think Stadia would have seen early success even with a better business model. The problem is the market segment they were targeting. People who:

  • Have very fast Internet and are geographically close to Google Stadia servers.
  • Are interested in playing AAA titles.
  • Are willing to spend significant money on playing those titles.
  • Either don't have a console/high-end PC, or want to be able to game on less performant devices.
  • Are okay with the objectively worse experience of playing a game that has lag.

And then add on top of that, "Can understand Google's confusing marketing."

Who checks all those boxes? If I already have a console/PC, I'd play there to avoid the lag. If I didn't, it would probably be because I either didn't have the money or space to get my own hardware. But in that case I also wouldn't have the money for Stadia. And so on.

Further, the main thing Google was trying to sell, at least to developers, was the idea that we could remove the hardware limitations completely, and make games that could only be played on Stadia! Need 100 teraflops to simulate 10 million enemies at once? Stadia's got you covered.

But the selling point is also the problem: your game can only be played on Stadia. You've limited your revenue to what Google will pay you directly, plus whatever is generated by players. Collectively, that revenue has to cover the costs of making the game plus the opportunity cost of not selling on other stores. Google would have to pay out the nose to developers/publishers to make that risk worth it, which puts them in a tough spot.

Who knows what will come of this. The tech for streaming games is in its infancy, and Google probably just pulled the trigger too early in trying to be first to market. If they keep at it they might figure out or create this currently missing market.

If you want to get even deeper on this topic, we talk about quite a bit in our upcoming podcast episode.

Make room for chaotic collaboration

It's pre-COVID times. You're working in an office. You hit a stopping point in your current project, take your headphones off, and lean back into a big stretch. You look around. Everyone else still has their head down, so you quietly get up to go grab some coffee.

Your colleague sees you get up in their peripheral vision, and thinks, "Oooooh coffee sounds good right now." They meet you at the espresso machine (because you're at a fancy tech startup), and you chat about what you've both been up to so far today. You mention a problem you were dealing with earlier, and your colleague asks you some questions about it. As the discussion gets going, you realize that the two of you are onto something! You bring your colleague over to a whiteboard and the markers start flying. An hour later, you've solved a major problem that saves you tons of time, and creates new business opportunities for the company.

This is chaotic collaboration. Unplanned, unexpected, and occasionally resulting in profound discovery.

We've been working remotely since April, using Discord as our primary tool for collaboration. We've managed to create a system that feels a lot like being in our old office, but the thing that's been missing is that chaos.

Our Discord is set up so that we each have our own voice room (our "office"), where we are just online while we work. That way someone can pop in to ask questions, and there is the sense that everyone is around working together. But this structure makes it so that nearly everything is planned, since by default we're siloed off from each other. There is little room for chaos.

This past week we tried something new: a voice room for everyone to hang out in while working (we're a small team). It's totally opt-in, but the expectation is that if you're in the room you've got your video on and are screensharing (and muted or on push-to-talk).

This setup creates some of the collaborative chaos that you get in an office environment, where you can look "across the room" and see that someone is doing something really cool. Or you can ask someone to take a look at a thorny problem you're trying to solve, and they can literally just look (no technical hoops necessary, everything is already running smoothly).

We're still experimenting with this, but coupled with some Wacom tablets and a digital whiteboard, just this first week we've solved some huge problems that otherwise would have taken a lot longer, or might not have been solved at all.

Cross-Posting and Canonical URLs

SEO (search engine optimization) is the bane of my existence. I've messed it up so many times with the studio website that I'm surprised Google even knows about us at all. I mostly know what to do, but I typically don't put good tests in place to make sure I do those things correctly.

For example, a few weeks ago I discovered that no longer had a sitemap. You know, the thing that says, "Hey Google, here are all the pages I want you to know about!"


Anyway, something that's come up a lot recently since I started writing articles again is the "Canonical URL". A canonical URL is your way of telling Google, "Hey, the original (canonical) version of this webpage lives at [insert very specific URL]."

Why? What does it matter?

Let's say you put your heart and soul into crafting a blog post. Once it's done, you shop it around to see if anyone will publish it. Maybe somebody does, maybe not. Either way, you it on your own site, Medium, anywhere you can take advantage of existing traffic.

People read your article and like it, so they post links to it on Reddit and in their own blog posts. But, which URL do they use? Probably the one from the site where they saw the article! Now a collection of links lives out on the Internet, all pointing at different URLs.

Google's whole thing is ranking search results by, in part, how often they get linked to. You've now split your score across all those different websites, tanking your searchability! And even if your post does come up, you can't control which website shows up first!

The solution to this is to set the canonical URL header on each posting to a single URL. Where possible. Medium and both let you do this in their advanced options. Some sites don't provide this option, so you may want to treat one of those as your canonical URL if it's likely to generate a lot of your traffic.

Note that this isn't just a problem for cross-posting. It can be a problem on your own site. For example, many websites allow both and to work, creating two distinct URLs for every page. Also, many pages on sites have content that changes based on query parameters (the stuff after a ? in the URL), and query parameters can come in any order while still resulting in the same page. So and are the same content, but with different URLs.

Long story short: there are all kinds of reasons you could end up with multiple URLs where you should only have one, and you have some control over this with canonical URLs.

Next time

That wraps the DevChat #3!

Give me feedback! Specifically, which part of this issue interested you the most?

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

(Replies don't go to me (yet), so use Twitter for now!)

Have a great week!

❤ Adam