How to Fail as a Web Developer
Broken code shouldn’t break your spirit. Learn the right way to handle when things go wrong.
By Matt Huntington
Three months into my first job out of college, as a web developer at a financial reporting company, I wiped out every single one of my company’s client records in one command. I had uploaded a script meant to eliminate one client, but quickly realized that it removed all of them and I couldn’t get the records back. (This was in the early 2000s, when it was less common to work locally before sending code to your live website.) I went into full-on crisis mode and started getting my resume ready, resigned to the fact that I was going to be fired. I was even Googling to see if I could be sued for what I had done.
As a web developer, you’re going to fail — often, and sometimes in huge ways — whether you’re a newbie or a veteran.
Thankfully, a tech manager saved the day by telling me about the company’s nightly database backup and we quickly fixed most of the problem. But until that moment, I was sweating bullets.
As a web developer, you’re going to fail — often, and sometimes in huge ways — whether you’re a newbie or a veteran (for example, see this recent mishap at Amazon’s web hosting service S3, in which a typo took down massive services like Trello and Quora). But messing up doesn’t have to be stressful. In fact, when it does happen, staying calm is key because panic can cloud your judgement and force you to make rash decisions.
If you understand how to diagnose a problem, learn from your mistakes, and remember that this happens to even the most senior developers, you’ll be able to shift from panic to zen the next time something goes wrong.
The Meltdown Moment: OMG AKS&A1LSKD!!!!
OK. You messed up — big time. The work you’ve been slaving over for weeks, maybe months, through countless pizzas and espressos, is suddenly throwing errors. Not only is it not working, but it’s taken a huge chunk of your website, project, etc., down with it. Not good.
Before you hit crisis mode, take a deep breath and remember that 1) big failures happen regularly all across the industry, and 2) it’s unlikely that you’ll lose your job over this. I don’t know anyone who’s been fired for breaking something. (Worst-case scenario, though, developers are in high demand and you can find another gig.)
Experienced teams are used to things breaking — and if they’re not used to it yet, they will be soon enough. As a leader and team member, the way you react to a mistake can influence the rest of your team. If you can keep a calm head and recognize mistakes as something easy to fix, your team members will feel more comfortable and work more effectively.
<DIV> Into the Problem: Decoding Broken Code
First thing’s first: Analyze and diagnose the problem. Unfortunately, this tends to be the hardest part.
There’s a great line in the TV drama Mr. Robot that speaks to this journey, when Rami Malek’s character Elliot Alderson, a cybersecurity engineer, says, “Most coders think debugging software is about fixing a mistake, but that’s bullshit. Debugging is actually all about finding the bug, about understanding why the bug was there to begin with, about knowing that its existence was no accident.”
In my specific instance, I knew why I broke the site: I had just uploaded code I hadn’t tested first. But most often, you’ll have no idea who or what caused it. Your instinct will be to sort through the code and the various files, traveling from file to file to figure out, “OK, here it called this function. Where’s that function?” The process can be exhausting, time consuming, and chaotic, like jumping from lily pad to lily pad trying to find an error that could be as small as two missing letters.
Whether you’re debugging, fixing a mistake, or writing a piece of code for the first time, it’s important not to rush. In general, you should write one tiny segment and then test to see if it works. If you write a lot of code without checking any of it and it breaks, the problem could be coming from anywhere. If you keep a calm head and write in a relaxed manner from the start, you’ll make fewer mistakes.
The other key to becoming a skilled bug-finder is knowing it’s not always your own mistakes you’ll be fixing — often they’re someone else’s. Being aware of ways people commonly mess up will help you quickly catch someone else’s error before it turns catastrophic.
Talk It Out
How do you get to know what kinds of mistakes and behaviors your team members are prone to? Communication. When you mess up, talk to your team and start doing damage control. It’s possible someone else will have an easy fix or ’fess up to being the culprit — or, like in my case, reassure you by saying, “Oh, it’s not that bad.”
Open conversations can cure countless office ills — even issues like coding fails that you might instinctively wish to keep to yourself.
One of the most supportive companies when it comes to making mistakes is the eCommerce site Etsy. The company’s engineering team writes a blog, Code as Craft, where they regularly share learnings in the field, as well as a regular speaker series exploring tech and coding trends. Along with maybe Google, I think it’s one of the most committed to writing high-quality code.
Despite pushing for great heights, or perhaps because of it, the developers at Etsy make mistakes from time to time. But instead of that being a negative, team members talk openly about where they screwed up, whether it’s on the blog or in an email to the whole company. It’s not a public shaming, but rather an opportunity to explore the kinds of errors that happen, in hopes that it prevents others from repeating them. This is the kind of mindset developers should strive for.
Following Etsy’s lead and thinking about coding as a craft means approaching it with the same amount of care and thoughtfulness any other type of artisan would — looking at the bigger picture and talking with your peers about tools, techniques, and ways to get better.
Open conversations can cure countless office ills — even issues like coding fails that you might instinctively wish to keep to yourself.
Some companies accomplish this through code reviews, where programmers display their code and the rest of the team makes suggestions for improving it. Code reviews can help colleagues better understand one another’s thinking and get better at diagnosing problems together.
Engaging people — whether they’re workplace colleagues, peers from your college or code school community, or friends in the industry — can provide guidance and alert you to mistakes others are making. It also provides an opportunity to trade processes and philosophies that can keep development teams focused, meticulous, and on track.
The Big Fix: Discover Your Inner Developer
Once you find the bug, it’s often a quick fix. But ideally, you’d be able to avoid meticulously going line by line by line through your code, or having a team-wide discussion to get there. At top form, you’d be able to jump five steps ahead and guess where things went wrong.
There’s another Mr. Robot quote that’s appropriate here: “A bug is never just a mistake,” Elliot says. “It represents something bigger. An error of thinking. That makes you who you are.”
If you’ve got some knowledge about the application, and perhaps more importantly, yourself, fixing mistakes becomes a lot faster. While both of these things come with time and experience, there are shortcuts you can take to get there sooner.
When you’re typing code, tools like linters and compilers tell you when you’ve made a very basic, preventable error, like a misspelling or forgetting an opening bracket. That means that usually, if a coding error has made it all the way to production, it’s not a mistake but rather a logical error, which happens when your thought process about how the program is working is incorrect.
“A bug is never just a mistake. It represents something bigger. An error of thinking. That makes you who you are.” — Elliot Alderson in Mr. Robot
For example, a couple years ago a former coworker was testing for the truthiness of a variable — a case in which, if a variable is an empty block of text, the number zero, or a null value, it is treated as false. He was testing the truthiness for a company’s ID, but what he didn’t know was that there was a company in the database with an ID of zero — so the company was always coming back as not having existed, when, in fact, it did exist. The colleague didn’t make the correct logical assumption and test to see if it was exactly false. The problem-solving was incorrect.
Find your error of thinking. Find out who you are.
As a web development instructor at General Assembly, I help students discover what kind of a developer they are — what kind of mistakes they’re going to make, the types of errors they’re prone to, and where they’re going to go wrong in terms of thinking about a process.
Coders generally fall into camps of those who make silly typing mistakes and those who make logical errors, but the nuances are incredibly complex.
One way to start understanding your coding style is to ask yourself questions like: Do you tend to forget an equals sign, or not evaluate variables’ truthiness correctly? Do you mix up the order in which your functions are called? Does the asynchronous nature of JavaScript trip you up? Or perhaps you’re a great problem-solver for nearly everything, but make frequent typing errors. Everybody has a different approach, and therefore everybody makes mistakes in entirely different ways.
At GA, we give students homework, labs, and projects designed specifically to challenge them. To make everyone aware of different types of problems and find patterns in their own work, we’ll often put errors up on the screen for the whole class to see and dissect together.
Another way to get to know your common mistakes is through keeping a bug journal, which some of my colleagues have their students do in their web development courses. Keeping a bug journal forces you to think a little bit more about the kinds of mistakes you make. If you’re spending time writing down your errors, you’re more likely to have it in the back of your mind that it’s something you may repeat in the future.
Once you know what kind of issues you’re likely to fall into, you can draw on that knowledge to diagnose your future, inevitable, failures.
Remember: Even the most experienced developers fail. But when you learn to handle your failures with grace and thoughtfulness instead of panic, you can prevent future problems and gain valuable insight into who you are.
Matt Huntington is the lead instructor for the full-time Web Development Immersive Remote course at General Assembly, the online version of our cornerstone Web Development Immersive program. Looking for a quick coding primer? Check out Matt’s video series, Basic Programming Concepts You Need to Know, or attend a short bootcamp or free intro class at your local GA campus. If you’d prefer flexible online learning, check out GA’s JavaScript Development and HTML, CSS, & Web Design courses.
Matt Huntington has worked as a developer for over 15 years and has a full understanding of all aspects of development (server side, client side, and mobile). Matt graduated magna cum laude from Vassar College with a degree in computer science. He teaches the full-time Web Development Immersive Remote course at General Assembly, and has worked for clients including Nike, IBM, Pfizer, MTV, Chanel, Verizon, Goldman Sachs, AARP, and BAM.
