When Your Code Is On Fire

Disasters do happen when you are working on projects. I am reminded of a certain situation in which a junior programmer imported something into the core library and errors started popping up everywhere. Like “the whole house is on fire” situation. Now, I know about not touching production rules, backups, etc. There are systems put together in-place to stop this particular problem from happening. But this post is more of how to handle things when shit happens. This guide is mainly for Junior Programmers of Unity, but it may be of help for other software and languages as well.

Do Not Touch, Take A Break first

Hands off, stand up and go drink water. Take a break, take a deep breath, try to calm yourself as much as you can. When your code is on fire, you will be freaked out. But, trying to fix things when you are not having a rational mind is the worst thing that you can do to yourself, it will create more errors, which in turn might be harder to fix afterwards.

Accept The Situation

We screwed up, accept the situation. Things happen, we cannot change what has happen, but we can make up for our mistakes by fixing it. You might be getting an earful, but you need to make things better.

Analyzing the errors, and fixing it

You need to look at the errors that pops up. Here are some of the patterns you need to look at:

If the errors looks like it comes from the same method, variable or class reference:

This means, you have inadvertently overwritten a certain class or file. If the class/file belongs to you, you can fix this by finding out what changes have you made from the current version and the old version. But, given the fact that you are reading this guide I am assuming that its not you that developed that particular class/file. In that case, you would need to ask your co-worker that written the class to see if he has a backup. If he does not, he can still help you since he understands his code better than you. Just be sure to say sorry, thank you for the help, and buy them lunch or something.

If the errors looks like it comes from a particular library:

When this happens, chances are your library versions are mismatched, one of them is either older or newer. Find out what the old version number is. Download the old one, create a backup of the current code, replace the library with the old version. Sometimes, different versions of libraries have what we call breaking-changes. These are changes to the codes that makes our old implementation to no longer works. So, do not simply upgrade a library without glancing through the change notes.

If the errors looks like it comes from multiple libraries:

Sometimes this happens because you messed with or mismatched their dependencies. Chances are, there are libraries that uses the same dependency components from other libraries. Go through the codes that contains the errors and find out which dependency they share, and replace that dependency library with the correct version.

When all else fails

You tried fixing it, but it does not work, the errors does not make sense. Here is what you should do.

  1. Backup the code. I am literally asking you to have a backup of your error ridden project. Just in case you turned the fire into inferno, you can always go back to just fire.
  2. Isolate the parts that does not have errors, move them out of your burning project folder into another project folder. Save what you can from the burning wreckage. You do not have to start from scratch.
  3. Reimport the libraries, download from original/error free source.
  4. Bring one of the code files that have errors into your new project, see if it still burns in the new project. If it does, see what is wrong, and fix them first. Do not add more files until you fixed this one code file.
  5. Repeat step 4 until you have a working version again. It might take time, but this will allow you to focus on the problems one at a time.

Learning from disasters

Here are a few things that you can do to avoid such disasters:

  1. Backup!, Backup!, Backup! before doing any changes, especially to Production/Core.
  2. Do Not Touch Production or Core. Make a copy of it in your machine, and make changes in that instead. If it is okay, run it by your person in charge, he will move it to core safely.
  3. Always refer the person in charge before doing anything in Production / Core. They are the ones who are responsible for the whole codebase, do not bypass them, ever. They are the ones that will be either saving you from disaster or help you out of one.
  4. If you are not sure, ask and clarify.