Started in 2009 as a Blogger blog about video game design/culture/psychology/philosophy (my most-read post was about quitting World of Warcraft[1] and was discussed on HN at the time[2]), it's now a (mostly) static site built in Hugo including the blog, my own developed games and a dev blog about them (only one game so far; that's a new part of the project), quick reviews of games I play, shared links to interesting articles/videos, and a blogroll of other recommended websites.

I'm very much a fan of "Publish (on your) Own Site, Syndicate Elsewhere", so I've been moving all of my content together under my own control. My articles also go to Medium, my games also go to itch.io, my shared links are also on Pinboard, etc., but everything is primarily on my own site and if any of the external services vanished I wouldn't lose anything.

It's been a great way to learn more web development tools and skills, and it's nice to have both "write something creative" and "tinker with site infrastructure" as project options depending on what kind of energy I have in my free time.

[1]: https://pixelpoppers.com/2010/12/doing-my-dailies-why-i-quit... [2]: https://news.ycombinator.com/item?id=2054992

There's definitely more interaction with people, as your day-to-day work is more about helping people succeed than building things. But you still use a lot of the same skills you've built up in development work - especially if you've spent any time debugging code.

Whether this will appeal to you depends on what motivates you. For me, I really like feeling like I've made a difference and one of the most powerful ways to get that feeling is to solve a problem for someone, so this is a very satisfying line of work.

Also, I've done a lot of interviewing of candidates for this role - and I can tell you that at least on my team, lack of experience isn't really a blocker. It's common to need to quickly learn a new product or feature to solve a customer/developer's problem with it, so we look more for quick learning and problem-solving instincts than built-up experience or domain expertise.

I haven't done a lot of comparison or asking my coworkers how much they make, but the information I do have suggests that while developers are commonly paid more on average, if you're at a company that actually values product support (often because it's recognized as an important contributor to customer retention) this difference can easily be dominated by other differences such as willingness to negotiate. Support teams are also usually smaller so it can be easier to demonstrate how much value you, personally, are adding.

But again, this assumes the company actually cares about support. There are definitely places that treat it as a revolving door position and won't pay much.

It's also worth noting that from what I've seen, companies are much more willing to have distributed support teams than dev teams, due to the value of having support availability in multiple timezones. I actually telecommute four days a week in my current role.

From the perspective of the business, by improving the experience the customer has with the product, CS folks maximize the odds that the customer will be happy with the product, and therefore stay subscribed to it, increase their subscription tier, and recommend it to others.

The experiences described in this writeup are pretty terrible and I'm not sure that organizing those particular CSMs any differently would have produced better results. Organizing CSMs by location also has the benefit that the customer tends to be able to get ahold of the same people on short notice because they're working in the same timezone. And there are a lot more industries than there are timezones. While it does seem plausible to me that if you could pull off CSMs-by-industry it would be more successful, it would be a lot harder and more expensive to do so. I personally don't know whether it's worth the tradeoff.

Ebert flirts with definitions of art, but never provides his own. This is the biggest problem by far with his essay. Maybe his definition really is something that flat-out can't include videogames. But when he simply says "videogames can't be art" without explaining what he means by art, we can only fill in the blanks with our own definitions. It's no wonder gamers get enraged by this. And they say, "Of course games are art, look at Bioshock/Braid/Flower/etc.!" And Ebert looks at these games not with the gamer's definition of art, but his own, and says, "Of course these are not art."

It's pointless and inflammatory and it can't possibly go anywhere constructive until Ebert defines his terms and explains just what he means when he claims videogames are not art.

You describe a frustrating experience in which you had to work very hard to experience the content, and as a result you didn't care much for it, and posit another experience in which the content is far more accessible and the experience is shared with a wide audience, and assume you'd enjoy this better. I'm with you that far.

And then - if I'm reading correctly - you suggest that the frustrating experience is Easy Mode, and the accessible one is Hard Mode? This is where you lose me.

If I'm trying to play a game I've heard good things about, my experience can certainly be soured by a high level of frustration. And I'd probably like a game more if I can share the experience with other people who like it. To me, these are both arguments in favor of Easy Mode.