1. Start always from clear plan, strategy. It should be step by step.

1st example:

QA responsible for deploy on test envs, dev to provide changes itself

• If QA said that your changes not work in test env’s, check if it was successfully deployed (for example through Jenkins status).
• Then reproduce by yourself in test env
• Then go to deeper investigation.

If you will start directly from deeper investigation (double-checking on local), you could spend a lot of time, but the problem can be at deployment. In this case you will save a lot of time. Don't assume that deployment was successfull, check by yourself.

2nd example (Codebase based):

Bug: On changing market type the budget form is not changing according to the type of market.

1. If you don't know how technical logic work, try to find info in corporate docs. If there is no docs, then it will take more time to understand, Digging in codebase.
2. When you have done this task, write the documentation by yourself. Don't let your knowledge be forgotten in future. From my experience: knowledge in brain is preserved Approximately for two months.

Trying to find out the Root cause (starting point of issue):

In general 2 cases

Check the market

• Check if market is changed in backend, when changed in front end UI. Because if they are not saved, then Front state (VUEX) is also not syncronized.

Check the budget form

• Check if budget form is updated in frontend component according to state (VUEX). This logic contains a lot of files to look up.

I started from the second step, but that was a mistake, the first step should be checking the market.

Summary

if you will start without strategy, straightforward looking to code, you will lose more time, and when you have strategy you will focus and only search for this particular stuff in the heap.

Try to sharpen your strategy by writing it to LLM.