Theory versus your work, and how to tie the two together

Hey everyone,

Just sharing some things of what I’ve learned in my work place along the way.

There’s a giant blob of code, in which, at the beginning of this week, it was hard for me to understand. I wasn’t the person who wrote the code originally by the way. The work on starting to fix the bug was Thursday with other priorities that remained.

So now, are you asking exactly how I was able to solve the issue? If the answer is yes, then read on!

Now then, you’re going to need to ask how what you’d like be doing will make the most sense to you.

You can try to solve it 100% by yourself which is totally fine, but it would normally be a consumption of time. So the cost of trying to look at what’s going on is a lot more time than value to be put in. Therefore, unless you are looking into architect a solution, a bug fix should take around a week maximum.

Today however, we’ll look into a bug that you are unfamiliar with the code base. Now, there are steps and sub-steps along the way.

First, ask the person who originally coded the solution, and then introduce the bug. Most likely, he’ll be able to answer why the bug is happening.

Now for step A, he should be suggesting a solution that should be very simple. Now if that works, then you can stop here. If it doesn’t work, he’ll suggest step B. If that works, then you probably don’t want to stop here just yet.

Why?

Although the solution is simple, the fix is not a permanent fix. Therefore, now it’s time to go into the second step.

Start commenting out code that may take a while, which also has sub-steps by itself. Eventually, it’ll get to the point where you’ll be able to understand what is going on. Now, you can start to make a workaround.

The third step is to try and ask yourself what else can be done. If you need yet another person to give you some theory, then feel free to ask away. You might get an abstract solution, but at the same time, there should almost always be a derivative to the abstract. During this time, the sub-steps would be to do some research, and then find a way to implement not the same solution, but something similar to the nature.

Step four would be to code something up with trial and error. You’ll find that it works for that bug, and now you’ll need to do a lot of sanity testing. You’ll find that you might be introducing other bugs into the equation. That is all sorts of bad.

Step five would be yet another trial and error solution, mainly in finding what worked before and how you can re-implement the old logic back without breaking the new fix. Now go back to step four. Until you’re completely satisfied, then the only next step would be to commit the fix.

So there is always theory, but your job is to analyze whether or not it is right for the piece of work. That’s all I have for today, let me know of thoughts.

Until next time!

Brian.