I F***ed Up As A Software Developer And You Will Too!

I F***ed Up As A Software Developer And You Will Too!

You will make mistakes. Follow this advice to make sure you handle them in the best way.

ยท

8 min read

No software developer is or has ever been without error. I challenge you to find a person who writes consistent bug-free code. Impossible. Every developer has messed up. I bet most engineers will remember the first time they truly fucked up. It is deeply ingrained in their psyche.

Feeling like a veteran with PTSD, they remember that fateful day. A blurry flashback, the blinding crackle of a monitor and the intense sound of keystrokes echoing around them, as realization kicks in.

You weren't thereeee, man!

PTSD dog gif

This is the story of my first mistake, and how to correctly deal with it when you inevitably make one too.

How I fucked up?

It was a normal day, like every other. I was working as a junior developer in a large Fin-Tech company based in the North of England. My days consisted of fixing bugs, closing tickets, and learning, lots and lots of learning. The previous day I picked up a ticket. The issue was a group of clients investment valuations were incorrectly showing. I put on my deerstalker hat and got to investigating ๐Ÿ•ต๏ธ

One long investigation later...

image.png

I discovered the problem arose from a pesky Id field that wasn't populated from a link table.

I had dabbled in SQL. Nothing too complex. It was still early days in my developer career but I was happy with the challenge. I knocked together a SQL statement in SQL Server Studio. I wish I had a copy of it now to show you the pure performant elegant power of queries I wrote as a junior!

Arnold Schwarzenegger he's lying gif

Alas, I do not. I highlighted it and pressed run.

Oh... I didn't mention the company I worked for allowed you to develop on a live database did I? Well... they did... as a junior, that is just madness. They didn't even have a QA team ๐Ÿคฏ

A hard days work was done and another ticket off the board.

Joel: 1 - Bugs: 0

Now... back to the day it all happened

I made my morning coffee. Sat at my desk and got to work on another ticket. Later that day a group email dropped in my inbox from the support team, with the subject of URGENT!

"We have had several complaints from customers regarding this..."

"There was a similar bug fixed in this area yesterday..."

"Clients don't have incorrect investment valuations showing, they have NO valuations showing..."

I read through it, line by line, it became clear. It was my fault. My stomach sank. I was nervous. Palms sweaty, knees weak, arms heavy. Moms spaghetti.

Eminem moms spaghetti gif

I was one of four juniors who started at the same time. We always made jokes about who would be the first to make a mistake. Yet here we were, it was me. I knew what I needed to do. I didn't want to do it. But I had to. I gathered all the evidence I could think of that related to the issue and nervously headed to the senior engineer's desk.

I explained the situation. After receiving a couple of friendly jibes, standard workplace banter. I buddied up with a senior developer and we got to work fixing it. By "we" I mean I sat next to him and told him what I had done. He then proceeded to do some SQL wizardry. Moving around the keyboard like Mozart on speed, yet still managing to talk me through what he was doing. He ran a script, 198 rows affected. That was it. Panic over.

I was the fuck-up for a short while. It wasn't long until another junior made a mistake and the title passed to them.

You will fuck up too... Here's how to handle it

We all make mistakes. It's how you deal with it that matters.

When the brown stuff hits the fan, here is what you need to do.

๐Ÿ˜Œ Stay calm

You will be nervous. You will question your ability. Imposter syndrome is a feeling all developers have experienced. Even the most seasoned coders, years into their career still struggle with it. The best solution is to not lose your head. You need to get in the habit of finding solutions, not dwelling on problems.

If you can solve the problem,

Then what is the need of worrying?

If you cannot solve it,

Then what is the use of worrying?

-Shantideva

Above is a Buddhist quote on dealing with problems. I read it a few years ago and it still resonates with me now. The beauty is, as a developer, you can always solve the problem.

๐Ÿ’ก Find the problem. Even better, find the solution

You need to establish the cause of the problem. Once found, you can limit the involvement of another engineer by finding a solution. If a solution doesn't seem clear, gather all the evidence to assist the person who will be assisting you. With the issue clear in your mind, you can approach the situation in the best way. So when discussing you come across as both confident and competent.

โœ‹ Accept responsibility and don't be afraid to ask for help

The worst thing you can do in these situations is to not own up. Even worse, try to cover it up. Swallow your pride. Everyone makes mistakes. Your response when the pressure is on will be noticed more than the fact you have broken something. The longer you put off asking for help, the worse it will seem in your mind.

So take Nike's advice and Just Do It.

๐ŸŽ“ Learn all you can from it

Every problem is a learning opportunity. Especially early on in your development career. I learnt not to make that same mistake twice. I learnt that the outcome is never as scary, or as negative as it is in your head. As well as that, senior developers are not as intimidating as they seem. Observe all you can. They would appreciate teaching a fledgeling engineer something new. That is, if you don't come back to them in two weeks with the same issue, then maybe they will label you inept.

How to avoid fucking up in future

What if you haven't fucked up yet, or maybe you have and want to avoid it in the future. Follow my advice below to reduce your chance of breaking something.

Note: Reduce, not eliminate. Mistakes will happen.

โœ… Check, check and check again

Read your code, double read it, triple read it. Run it and then re-run it again. If you don't want bugs or mistakes then you need to be thorough in your testing. Even then, a competent QA team may still find a scenario that breaks your code. As long as you feel confident that it will incorporate itself nicely into the existing codebase, without breaking anything, then you are good.

๐ŸŒฟ Use source control

This goes without saying. If you aren't using source control, why? Consider it the bouncer to the codebase nightclub. Not letting anything past unless it has been thoroughly checked. You can view, edit or even undo your changes if you aren't sure that what you have written will mix well with the existing code. Look into Git, GitHub, VSTS on Google for more info on this.

Take this a step further by using pull requests.

๐Ÿง Get someone else to check

Pull requests offer a view of the before and after of your code changes. These can be sent to other team members for validation before going into the main codebase. This way, you can get rapid feedback, and it mitigates the level of risk involved, as someone else has checked the quality of your code too.

๐Ÿ˜ฌ Become comfortable with asking for help

This can only benefit you in the early days of your programming career. Don't be afraid to get a second opinion. Especially when it comes to database queries. Your company will most likely have a Database administrator (DBA). Get advice from the relevant person if you feel unsure.

Don't go asking questions to problems without a solution. Ask for confirmation on the solution once you have found one. Unless you are really stuck, then explain you have exhausted all your efforts and a senior member can point you in the right direction.

โ— Don't develop on a live database

I can't believe I have to include this on the list, but judging by my previous workplace, I do. Set up testing environments and databases for developing on. Keep your production codebase separate and have the checks mentioned above in place to ensure no severe bugs are introduced. Developing on a live database means you are interacting with the real info of real people and that is something you really don't want to do unless you really have to.

๐Ÿ€ This is the end, good luck

There you have it. My first big mistake and how I learnt to handle it. I hope you can learn from this too. Not that you won't make mistakes, but you will be fine if you have the right attitude and outlook to deal with it when the time comes. Problems come and go like the wind in this industry, so don't take stuff personally and always learn from your mistakes.

Follow me for my upcoming posts or you can find me on Twitter twitter.com/TechPickleJoel

I went from self-taught to senior engineer in 4 years. I tweet and blog about

  • โšก Becoming a software developer
  • ๐ŸŽ“ Learning the required skills
  • ๐Ÿ”Ž Finding a job in the industry
  • ๐Ÿ‘ท On the job skills & advice
  • ๐ŸŒฑ Growing in your current career

Thanks for reading โค๏ธ

ย