Trying to end "Stack Anxiety"

If you follow developer conversations online, you’ve no doubt seen various people saying things like “Everybody ought to try this one new framework!” or “Nobody should still be using that old library!” or “That programming language is dead!” Very broad, sweeping, seemingly-authoritative statements, often made without considering the context by which others make their technical decisions. They don’t always do much to make things easier for people who just want to create. You've probably also seen people worrying about all the prerequisites and technical dependencies that get in their way every time they try to create something new. It’s gotten harder than ever just to try the new frameworks and libraries that come out every day, let alone give them a fair, in-depth assessment. Trudging through installation, configuration, dependency hell, and all the other parts of setup can have you feeling burnt out even before you set out to learn a new syntax or design pattern.

In short, the way that coders encounter new technologies that are supposed to help them seems perfectly designed to create what we could call “stack anxiety”. We can sum it up as two big worries:

• Concern that one isn’t using the “right” tools or frameworks, not on technical grounds but on social ones
• Fatigue or worry about all the overhead involved in trying out new frameworks or libraries, with lots of technical barriers that have nothing to do with coding itself Put together, these two big causes of stack anxiety are like a perfect recipe for sucking all the fun out of coding.

Stack anxiety is a lot like FOMO — it’s exacerbated by how we talk about coding, especially on social media. Thought pieces written by people who are (or who sound like) experts, even when well-intentioned, can have a huge negative impact on coders who are just starting out. And we're all newbies sometimes, whether it's because we're new to a particular framework, or because we're new to coding in general.

The end result is the coding equivalent of looking at your Instagram and comparing yourself to an influencer whose entire job is to look appealing on social media. You’re gonna feel bad! And you never see all the hard work they're doing behind the scenes, often with a whole team helping them do it.

This painful pattern often makes the most vulnerable coders feel bad for making choices that are often perfectly reasonable, or for which they didn’t really have much choice due to legacy or other constraints. Sometimes you just can’t use that tech that it seems like all the “cool kids” are talking about. And sometimes, even if a technology is really interesting, getting it set up and running takes up all the time or energy we have, leaving no time for, you know, the actual coding.

There’s got to be a better way! #

We’ve thought a lot about stresses like Stack Anxiety when making Glitch, because we’re deeply focused on removing any barriers that get in the way of quickly creating apps. And here’s what we've found: barriers to coding are as likely to be social or structural as they are technical.

A lot of times, the hard part about coding isn't the coding.

So, how are we trying to make sure Glitch reduces everyone's anxiety a little bit? By addressing the issue at a few different levels.

• You've got this! One consistent part of how we've designed Glitch's community is to make sure everyone is encouraged and rewarded for being thoughtful and supportive to one another, not critical of their choices. For example, in lots of places where you see another person's avatar on Glitch, you can instantly click to thank them. (And we'll be working to expand this to almost every place you can connect with people on Glitch.) When so much of coding culture is about tearing apart other people's work or trying to seem smarter by being critical of their creations, it can mean a lot to know someone has your back. It even goes all the way to Glitch's very name — we chose a name that means a little mistake or problem, because we all have bugs sometimes, and it can be reassuring to know that we can fix them together.
• Really good defaults. Recently, we created an all new set of starter apps for people to remix and get started with as they build new apps on Glitch. It’s a bit counterintuitive, but part of the reason we spent a lot of time choosing really great default stack choices on these starter apps is so that you don’t have to. You’re not getting into some personal or political battle when you pick a JavaScript framework on Glitch, you're just getting something that runs great, instantly, and lets you focus on your ideas and your coding.
• Instant setup. How many times have you lost all your momentum on creating a new project because you get stuck trying to wrangle dependencies, or configure new components that you have to install, or because something in your dev environment breaks in a way that takes forever to debug? One key goal of Glitch is to eliminate those entire categories of stresses — especially because it can be so hard to feel inspired and motivated to make something new if the first thing you encounter is a whole lot of exhausting chores. The great part is, over the last few years, the Glitch community has fully adopted this ethos. Everyone works together to support community members and creators in having less stack anxiety overall. For example, we’ve documented the rationale behind our opinionated choices for each part of the stack in our new starter apps. But that's not trying to say “this is the One True Way”. Rather, it’s so you can understand the choices being made, and keep your focus and energy on the problem you’re trying to solve. If you run into any issues, these default choices were made with the goal in mind of ensuring you’d be able to find others using the same tools in similar ways — whether that’s in the Glitch community or out on the internet at large. We wanted to make it as likely as possible that getting your app running wouldn’t involve having to justify, defend, or explain your technical choices to anyone who wasn’t trying to help you build.

Ultimately, that's what all this work boils down to. The social aspects of coding, and connecting to other coders, should be reassuring us about the choices we make, and the tools we rely on. Trying new things should be exciting and rewarding, not a moment that inspires fear of what's about to happen. There are so many more cool apps and projects just waiting to be made, to solve real problems or express meaningful ideas. We just have to support each other in making an environment where the social and technical barriers to coding don't get in the way of unleashing that creative potential.