One of the most important skills an engineer can develop is being able to keep a clear head when everything is falling apart. Today we’re talking about techniques that can help you be a practical and effective developer.
Have you ever heard the phrase “on tilt”? Old pinball machines had a mechanism to stop you cheating by tilting the machine, which would lock the paddles and force a game over. It would also trigger if you got angry and started hitting the machine too hard. You’d start losing, so you started acting emotionally, which meant you lost even harder.
You get the point: your response to a problem can create an even bigger problem.
It’s a lesson more developers need to take into their work. We work long hours solving complex problems, and even longer ones solving problems that should be simple but every step to fix them just breaks them further. When that happens, we can respond to it in two ways: we can take a deep breath, maybe take a short walk and come back, or we can go on tilt and make everything worse.
A codebase processes what you put into it—if you put frustration into it, it’s going to create frustration for end users.
Which is easier said than done. Humans are naturally emotional creatures, and I’d be lying if I said I hadn’t spent the occasional late night swearing at my IDE. But don’t worry, that’s what I’m here for: today we’re going to be going over some ways to get your calm back when things go wrong, and how to do the job that’s in front of you.
Be Realistic About Your Abilities
The best developers in the world started without a single line of code to their name, and I’d bet good money that the best developers in the world still run into code they can’t follow from time to time. There are more languages than one person could learn in a lifetime, more tricks and snares than anybody could hope to totally master.
And that’s fine.
It doesn’t matter where you are in your career progression, you’re always learning. If you encounter a problem and you approach it like a roadblock and get frustrated at yourself, then you’re only going to make things worse. If you approach it as a learning opportunity, then you start to develop the growth mindset required to become a truly great developer. It is perfectly acceptable to not understand, but it’s impermissible to refuse to understand, to cross your arms and get upset and not take it as an opportunity to grow.
Call In Backup
One of the most common culprits for bad code is the developer who went in alone and ended up hacking together a spaghetti code fix for something the developer in the next seat over could’ve solved in a single line. If you’re stuck, ask somebody for help. It’s such a simple thing, but, well … developers often lack soft skills and this is one of the quieter and more pernicious ways it makes our lives difficult.
You’re not always working in a team, but even then you’re not alone. Are you seriously going to tell me that you’re not in any developer Discord or Slack channels? That you don’t have a Stack Overflow account? That you don’t have a single other engineer friend you can DM? We live in an immensely connected world, and there is always help a few button pushes away.
It can also be a bit of an ego hit admitting I don’t know how to do this, but even the most senior developers trip over sometimes. We work with exceptionally complex systems, and every day somebody finds a bug that nobody else has found before. Even the best developers get stumped sometimes, but what makes them the best is that they know who to talk to if they want to figure it out.
Triage is a process paramedics and doctors do in emergencies. It involves figuring out who needs the most help, who needs the least, and sometimes even figuring out who’s too far gone to save. Good triage saves lives. You’re probably not working on anything with those sort of stakes, but it’s still a good mental process to develop.
In any fast-paced work environment, it’s important to apply a sort of professional triage to tasks, and figure out which ones:
- are working as expected;
- are struggling, but acceptable;
- need urgent support;
- are too broken to fix.
Don’t just prioritize, prioritize ruthlessly. If it would take more time fixing something than just scrapping it and starting from square 1, don’t be afraid to raise the issue. Try to be realistic, practical, and unemotional. Maybe you wrote the most beautiful code in the world but the feature around it is fundamentally broken—your beautiful code needs to go. It hurts, I know, but it’s part of becoming a great developer.
Say When It Can’t Be Done
Leading on from our last point, sometimes a task just cannot be done with the time and resources allocated. It happens. Sometimes it’s management trying to squeeze an extra dollar and sometimes it’s that somebody well-meaning has failed to consider the whole picture, but we’ve all been in a situation where the task put in front of us just isn’t possible. The 2020 Democratic Iowa Caucuses were thrown into disarray because of a poorly-programmed voting app, and it turned out they’d only been given two months to develop it. Electronic voting is hugely complex and a lot of engineers think it still can’t be done reliably, and the team at Shadow had a tiny, tiny window to go from wireframes to completion. Now, their reputation is ruined. They were a small, new company, and their first major project made the news for being broken.
They could’ve saved themselves a huge amount of time, money and bad press if they’d just said “no”.
Or, “we can do it in that timeframe, but we need double the engineers and three times the budget.”
Or “why didn’t you ask us a year ago? If we start now, we can have something amazing for next time.”
If you’re willing to stick up for yourselves and say when something just can’t be done, then you delete problems before they even become problems. Know when a task is within your capacity, and when you need to refuse, defer, or call in friends to spread the load around.
So, you’re in trouble. There’s no backup, there’s no ability to triage, and it’s too late to say no. I’m not gonna lie, it’s a bad situation, but you’re going to be fine, because I’m going to teach you an old actors’ trick.
The way through this is by breathing. Which seems obvious, but a lot of people don’t understand what a “deep breath” actually is and how much it can help you focus. It doesn’t mean a big breath, it means a deep breath.
Put your hand on your stomach, then breathe in long and slow through your mouth. If your stomach pushes our hand out, you’re making a deep breath. If your chest inflates, you’re not. You can do it now: try breathing so your stomach inflates, then try again and see if you can put it into your chest. It’s not actually your stomach and chest—it’s how deeply into your lungs it’s going. The scientific name for this is diaphragmatic breathing, and it will lower your heart rate and blood pressure almost instantly. Take five deep breaths, holding onto each one for 2–3 seconds. Repeat as necessary. You’ve got this.
Actors do diaphragmatic breathing during performances: it makes your voice louder and more clear but it also calms you down and helps prevent stage fright. I mentioned it offhand to a colleague once, years ago, and he started doing it at work when he got stressed. He told me it helped immensely, and I’ve been passing it on to colleagues ever since. When everything else goes wrong, take a deep breath.
We are hiring! If you’re looking for software engineer jobs in Kolkata, India, then you’ve come to the right place. If you’re more in the mood to read and relax, why not read our guide to Docker basics?