Welcome to episode 12 of Front End Center! Before we start, I wanted to wish the internet a happy 25th birthday! August 6th, 1991 is the day Tim Berners-Lee introduced “the web” to the world. Look how far we’ve come, and the journey is only picking up pace!

The more we add to the web, and the more complex it gets, the more difficult it can be to work with. More complex code and development standards, multiplied by sifting through resources that all claim to be “the only correct method”, means that things aren’t getting any easier.

Whether you’re just starting out as a developer, or are established and just keeping up with best practices, you’re going to face a challenge.

As a slight masochist, I’ve also been enjoying to self-imposed difficulty of playing back through the Dark Souls series and its related siblings. For those of you who aren’t familiar with the series, it is heralded as being immensely, shockingly difficult.

The games tend to attract players who like a challenge, or who are nostalgic for the olden days of platformers that brooked no leniency on the player. Miss a jump or touch a single enemy? Head all the way back to the start of the level; or even the whole game!

Playing through them again, though, I question the stereotyped fanfare of difficulty for difficulty’s sake. I think there’s a lesson within the difficulty of the Souls games that sets them apart, and also holds great importance to design and development in any form.

The key difference is that Dark Souls didn’t make it that much harder to win; it made it much easier to lose.

Other modern games have layer upon layer of loss-avoidance techniques. Every objective has a giant glowing marker on it, and a looped audio narration telling you exactly what to do. Weapons of mass destruction will shake your screen and lower your health bar… until you crouch behind a rock and it refills immediately.

In this system, player failure is something to be avoided. You gain nothing, except a very slight knowledge of what you will encounter again in a few minutes. It’s the equivalent of landing on a ‘404 Not Found’ page, and just gaining the knowledge not to follow that exact link again.

Dark Souls embraces failure and makes something of it. Every new discovery can be equally amazing and terrifying, and the game encourages you to embrace that. You WILL fail, and die, repeatedly. Like other games, you will learn from these failures as a player.

The game also has systems and interfaces beyond this external learning, however! Failure doesn’t simply rewind your last save point ad infinitum. On character death, you will drop the currency you have with you, but it can be recovered. Your last moments are captured in a ghostly animation and shown to other players in the same game-place around the physical world.

You are asked to learn through your (and others) failures! Many times the ideal solution to a challenging enemy is to literally ram your head against it repeatedly, failure after failure. As you learn its habits and quirks, your character also stock piles additional currency to make the fight easier WHILE you get better. You have to be smart, though.

If you expect to fail, you can’t just run in yelling and making noise. To get the most from your failure, you need to plan ahead for round two. Make it easier on yourself to recover the currency you lost, and focus on learning instead of winning.

What sets the games apart is that while many games make losing hard and worthless, Dark Souls embraces your failures.

This ideology and methodology is baked into the best design and development as well. In our work and careers, there are no giant, glowing destination markers. We can’t take cover behind a server rack and wait for our professional reputation to refill back to full.

There are concrete practices in development that reflect how to embrace failure. A/B testing is the embodiment of learning from failure. When you run parallel tests of multiple designs or approaches, you are expecting one to fail. Either by a little or a lot, you want to learn.

Learning what not to do, and why, is just as important as learning what to do in the first place. There’s a wealth of information available on how to do things “right”, and it would be nearly criminal to ignore that wealth of knowledge. What happens when the unexpected rears its head, though, and failure is a current reality instead of an undesirable future?

I’d gladly take the developer who’s failed and corrected fifty times, over the developer who’s NOT failed a hundred times in a row. I’ve been in both positions in various capacities, and, honestly, the latter is terrifying. There comes a moment where you pause, look down, and suddenly realize that not only are you afraid of heights, but you also can’t tell just how high up your tightrope is.

Success is, retrospectively, easy. Things that work as intended aren’t complicated. Things that fail, by their nature, fail unpredictably. Does your WordPress post not show up because of a missing semicolon? Or is it because you were REALLY tired last night, and wrote half your templates in the wrong scripting language without realizing it? Just finding what went wrong can be immensely challenging.

Whether there’s a documented process like A/B Testing, or you’re completely on your own to learn and implement, remember to make use of failure. Even when a solution is “good enough”, can it be improved? How can you make something faster, or more intuitive? Once you answer that, is it worth it?

Learn from your own efforts, and learn from others. Like in Dark Souls, if you see a lot of ghosts running around somewhere… there’s probably a hidden spike trap in the server room? Or it’s an issue that has proved challenging for those who came before you, and there’s a lot to learn. Probably both. Better safe than sorry.

A reminder and request that I’m currently running a questionnaire that can be found in the episode description or at http://fec.fyi! It’s a very short set of questions, focused on the content and quality of the podcast, and what I can do to improve the experience! I greatly appreciate everyone who takes the time to fill it out.

Until next week, thanks for listening! This has been Chris Landtiser, and Front End Center.