What is the reason behind?
The first step to take when you are assigned a problem or encounter one when coding or debugging is to ask yourself - what is the reason behind solving this problem?
By knowing the exact reason behind, you obtain more information to help you improve your decision making process. You also get more motivation to solve it and better understand how to prioritise your work. (This helps in getting less stress)
Consider these two different scenarios:
You are assigned the ticket T4882 which is about solving error P01990.
You are assigned the ticket T4882 which involves debugging error P01990. This error happens because of a template error for procurement and the reason we need to solve it is because the customer uses this feature everyday for printing invoices.
Let’s assume you are meanwhile working on a correction to make the invoice template font bigger. As the other task is more important because the customer uses it everyday for one of their main business processes, you can safely pause this one to work on the more urgent job.
Lack of quality communication
During the initial years of my software development career, most of the time a senior assigned a task to me, he or she would rarely mentioned why we needed to solve this problem.
As a result, I often struggled with understanding how the connect the dots - how this change fitted with the current implementation. With my limited experience in ERP software, I struggled with the errors and their codes, which was difficult to trace and understand their meaning.
Only when I started asking the seniors for more information on the tasks and the reason behind - the why, did I become more efficient and had more motivation working.
As a junior software developer or if you just changed company, you might hesitate asking additional questions. Doing so, however, helps you save more time and effort while minimising waste.