Broken code shouldn’t break your spirit. Learn how to behave properly when something goes wrong.
After working for three months at my first post-college job as a web developer for a financial reporting company, I wiped out all of a client’s records with one command.
I downloaded a script meant to remove one client but quickly found that it removed them all and I couldn’t recover those entries. (This was in early 2008 when the practice of working locally before pushing code to a live website was less common.)
I got very upset and started preparing my resume, resigned to the fact that I would be fired. I even Googled if I could be sued for what I did.
As a web developer, you will make mistakes – often and sometimes very bad ones – whether you are a novice or a veteran.
Luckily, the tech manager saved me by telling me about the company’s database backup, and we quickly fixed the problem. But until that moment, I was all on my nerves. As a web developer, you will make mistakes – often and sometimes very bad ones – whether you are a beginner or a veteran (for example, look at the Amazon S3 web hosting service blunder, in which a typo caused huge services such as Trello and Quora to fail).
But failure doesn’t have to be stressful. In fact, it’s important to stay calm when this happens because panic can cloud your judgment and force you to make hasty decisions.
If you understand how to diagnose a problem, learn from your mistakes, and remember that this happens to even the most experienced developers, you will quickly stop panicking the next time something goes wrong.
How to handle mistakes: OMG AKS & A1LSKD!!!!
You screwed up – bad. The code you’ve been tinkering with for weeks, maybe months, through countless pizzas and espressos, is suddenly full of bugs. And not only does this one bit not work but along with it, a decent chunk of your website, project, etc. – it all sucks.
Before you get upset, take a deep breath and remember that:
1) Major failures happen regularly across the industry
2) it is unlikely that you will lose your job because of this.
I don’t know anyone who has been fired for breaking something on a project. (In the worst case, the demand for developers is high, and you will quickly find yourself a new job). Experienced teams are used to the fact that something always breaks – and if they are not used to it, then soon they will be. As a leader and team member, how you respond to a mistake can affect the rest of your team. If you can stay calm and understand that mistakes are fixable, your team members will feel more comfortable and work more efficiently.
Diving into the Problem – Understanding Broken Code
First of all: analyse the issue. Unfortunately, this is the hardest part. In the television series Mr. Robot, there is a great line by Rami Malek’s character Elliot Alderson, a cybersecurity engineer: “Most programmers think that debugging software is fixing bugs, but that’s bullshit. In fact, debugging is about finding an error, it’s about understanding why it arose, and about the fact that its appearance was not an accident.”
In my case, I knew why I broke the site: I uploaded code that I didn’t test first. But more often than not, you have no idea who or what caused the break. Your instinct will be to debug the code and various files, going from file to file, to find out: “Okay, this function is called here. Where is this function?” This process can be tedious, time-consuming, and chaotic, while the error can be as little as two missing letters.
Another key to becoming a skilled bug finder is realising that you won’t always fix your own mistakes – often someone else’s. Knowing how people usually make mistakes will help you quickly find a bug in someone else’s code before it causes trouble.
See it – Say it – Sort it
How do you know what mistakes and behaviours your team members are prone to? Communication.
Once you’ve got your money up, talk to your team and start taking control of the situation. Perhaps someone can easily fix the problem, or admit to being the culprit, or, in my case, reassure you by saying, “Oh, don’t worry, it’s fixable.” Open conversations can cure countless office ills – even issues like coding blunders that you might instinctively want to keep to yourself. One of the most supportive companies in this respect is the e-commerce site Etsy. The company’s engineering team maintains the Code as Craft blog, where they regularly share their experiences, as well as regularly host a series of talks on trends in technology and programming. I think that along with Google, they are one of the most passionate teams when it comes to writing high-quality code. Despite aspirations for greater heights, or perhaps because of them, Etsy developers make mistakes from time to time. But instead of getting upset, team members openly talk about where they screwed up, on a blog or in an email addressed to the entire company. This is not a public denunciation of each other, but rather an opportunity to explore the mistakes that happen, in the hope that it will help others prevent them from happening. Developers should strive for this way of thinking. Following Etsy’s lead and thinking of programming as a craft means approaching it with the same care and thoughtfulness as any other crafter – looking at the bigger picture and discussing with your peers the tools, techniques, and ways to get better.
Open conversations can cure countless office ills – even issues like coding blunders that you might instinctively want to keep to yourself.
Some companies achieve this through code reviews, where programmers show off their code and the rest of the team makes suggestions to improve it. Code review can help colleagues better understand each other’s thinking and learn to better diagnose problems together. Involving people—whether these are work colleagues, college buddies,` coding school community, or industry friends—can give you feedback and alert you to the mistakes others are making. It also provides an opportunity to share information about processes and approaches that help development teams stay focused, rigorous, and on track.
Bug fix: open your internal developer
Once you find a bug, chances are it can be fixed quickly. But ideally, you could avoid carefully going through the code line by line or discussing the problem with the entire team. You can jump five steps ahead and guess where something went wrong. “A bug is never just a bug,” Andrey says. “It represents something more. Thinking error. It makes you who you are.” If you have some knowledge about the application and, more importantly, about yourself, fixing bugs will be much faster. While both come with time and experience, there are shortcuts to get you there sooner. When you type code, tools like linters and compilers tell you that you’ve made a very simple, preventable mistake, such as a spelling error or misplaced parenthesis. This means that usually if a bug makes it to production, it’s not a bug, but rather a logical error that occurs when your knowledge of how the program works is incomplete or flawed.
“A bug is never just a bug. It represents something more. Thinking error. It makes you who you are”, Andrey Kozyulya, CTO at DAN.IT
Find the error in your thinking. Know yourself.
As a mentor at the DAN.IT training centre, I help students understand what kind of developers they are: what types of mistakes they are prone to and where in the development process are they likely to make them. Programmers are usually divided into those who make stupid typos and those who make logical errors, but there are a lot of nuances in between. One way to start understanding your programming style is to ask yourself questions such as: Do you tend to forget the equals sign or incorrectly evaluate the truth of variables? Are you confusing the order in which your functions are called? Are you confused by the asynchronous nature of JavaScript? Or maybe you’re great at problem-solving but often make typos. Everyone has their own approach, and therefore everyone makes mistakes in completely different ways. At DAN. IT, we give students homework and projects designed specifically to challenge them. In order for everyone to be aware of different types of problems and to find patterns in their work, we often display errors on the screen so that the whole class can see and analyse them.
Another way to learn from your mistakes is to keep an error log, which some of my colleagues ask their students to do in their web development courses. Error logging makes you think a little more about the types of errors you make. If you take the time to write down your mistakes, chances are you will remember that this is something you might repeat in the future. Once you know what problems you are likely to face, you can use that knowledge to diagnose your future failures.
Remember: even the most experienced developers fail. But when you learn to handle your mistakes with grace and thoughtfulness rather than panic, you can prevent future problems and gain valuable insight into who you are as a professional.
Andrey Kozyulya, STO DAN. IT education
