Typically, your job as a software developer begins with an induction into the company HR policies, leave policies, salary components, other benefits and perks, company holidays etc. This is followed with an induction into the team you are recruited for. This would usually involve getting to know the piece of software that the team develops/works on, the build system, release procedures, version control system used in the team etc. And then getting to know at a high level, who the customers are, what the typical software usage is. Initially most of it sounds like greek or latin (Atleast in the first job it does! In the subsequent ones, you would be able to mentally map, one thing to another in the previous one). However with time, you would get used to the tool names and company-specific software terms.

While a few companies have a 2-weeks of induction, a few have a month’s induction program. Some of them believe in pampering their employees, leniently giving them 3 months to settle down. During the settling time you would be assigned your first assignment, mostly a small bug fix. Largely, the motive behind this is to get you accustomed to the bug-fix process and the various tools used in a bug-fix process.

Now, once you get your first assignment, what should you do:

  1. Read and re-read the problem statement.
  2. Usually the steps to replicate the issue are provided. Read them and get a mental picture of what is being done, and what is the issue the customer is facing – He could be seeing an incorrect message, or an incorrect value somewhere in the tool or a crash.
  3. Set-up the software as per the software version number, the platform (Linux, IBM, Windows etc.) and other configuration files provided in the issue.
  4. Once the set-up is ready, replicate the steps and see if you able to see exactly the same issue.
  5. Sometimes the issue is trivial and replicable on the first go. If not, you can ask the customer for any additional steps or config files which are missing in your set-up.
  6. Once you able to replicate, you now need to find the root cause and a fix for the same. It is a good practice to build a debug version of the software. This can take time, depending on the size of the tool.
  7. Replicate with the debug version. Use a debugging tool – like GDB (this has a GUI version and is very easy to set-up). You need to apply a breakpoint. If it’s a crash that you are trying to fix, then there is no need to set a breakpoint. Else you can apply a breakpoint at the location of the last log message that you have seen in your log file or at a function which you are sure will be executed in the steps.
  8. Try to replicate the steps, till you hit the breakpoint and then execute step-by-step inside the GDB GUI. From here you need to logically analyze what the problem is and get to the line of code that is problematic.

Usually the first bug that you are assigned is a very trivial, small fix – to add a NULL pointer check, to correct an error message, or to initialize uninitialized variables.

Once fixed, build the tool and use the exact same set-up and steps that you used to replicate the issue. If the fix is done, you can see that the issue is no longer seen with the same steps. And congratulations…. On your first fix!

In some organizations this could be followed by a regression testsuite execution, to be sure your fix has not broken something else and then a review process, by a senior member to validate your fix. Fingers crossed, hope this helps you fix your first bug without any creating any regressions.