Detective vs. Software Engineer…

This blog post in not about comparing detective with a software engineer as might be the topic sounds. But it is all about how to add a light side (role play) to your work and how to make your work with little adventurous and of course with little fun.

TRY

{

As of any story of a detective, you need to have a villain. For a software engineer, it's an issue. Small or big the problem it is, the fix is always inversely proportional. IMO, it is always required less code changes to fix a big and complex issue.

For any detective, it is fact he cannot ignore a small clue or details about the crime. He finds the clues & odd things in ignored area and finds the connections and put the things together to understand anything and everything related to crime.

For a Software engineer, it is fact that he need to understand the base of the issue.

1. Why the issues happen in the first place?
2. What's the reason for the issue?
3. What's the problem in existing implementation?
4. What's the expected outcome?
5. What's the specification says and what's the implementation does?
6. Are we handled the case in the right way?

These numerous inquisitive queries are part of finding the clues in every issues worked by Software engineer.

Yes we are more than a detective, a detective evidence are all physical, he can put things by seeing them but as a software engineer, we need to move beyond what we can perceive because we need to visualize the things in our mind, putting clues together and finding the facts and imagining the expected outcome and go for it. We are tougher in a way and we need to be more analytical.

}

CATCH

{

Once we find the cause, next step is implementing the fix. The easiest part in any issue fixing process but dangerous too. If any mistake is done it will affect the entire product.

For a detective, he will devise plans and strategies to trap the target villain. Likewise we as a software engineer go for implementation after careful analyzing and understanding the base of the issue.

Detective will follow standard protocols for trap we follow standard coding guidelines for the fix.

Consider now the implementation is done and we are in testing phase/ trapping for possible outcomes to ensure the fix.

Writing test case is more important than implementing the fix for the issue. After careful preparation in collecting evidence and setting traps, without catching villain and allowing him to escape is totally void and entire work of the detective is lost and wasted. Well, this is equivalent to implementing the fix and without proper testing (Test cases) allowing the loopholes in the fix for nurturing future issues.

IMO, test cases allows us to cement the potholes occurring in the fix.

}

FINALLY

{

No matter what, the end result (ensuring the fix) is always an achievement for any software engineer in the life cycle of issue fixing. When we reach this stage we do always have proudness in our fix and its natural instincts to wanting more of this.

No matter how tougher the issue is, have a lighter side of it and command the issue and don't get succumb to pressure. Hope such approach helps you. Happy fixing:)

}