One of the hardest thing for me was trying to find what code is not working as intended, locally it's fine to spend some time, read the logs or worst case attach a debugger and run, if not instantly but eventually, you will find the root cause. My problem was mostly a mental block rather than a lack of ability.
I had to get rid of this mental block when I started working in HFT company where on failure there are a ton of messages generated and have to scan through all the messages spread across multiple files to find the root cause like finding fields correctness or timing of the messages.
Initially, this was hard for me as I used to go in the logs without giving a lot of thought to where and what is failing and which logs should be checked. This all changed as I realized I am spending a long time finding the root cause without any plan. The technique I use now is a technique I observed from 1 colleague and decided to adapt so now if there is any error, instead of directly looking in the logs or stack trace,
I start creating process flow in the head and then logically go step by step till error starts making sense.
Not sure if that made any sense to you, so to make it clear, let's say you are a mechanic and there is a car in front of which is not starting. Old me would open the bonnet and start looking for issues but the New me, will first think, "hmm, why is the car not starting? is key inserted? is battery charged? is there enough fuel?" and then will check all those things 1 by 1 and reach to the bottom of a problem which might be inside the bonnet only! but the point here is, earlier I was missing the "process"
Process is more important than the result
Top comments (0)