Why: Write Down the Journal to Optimize the Efficiency of My Code-Reading Skill

I made an unnecessary detour when I was working on [adding profiler of time to first-order derivative calculating] (https://github.com/solvcon/modmesh/pull/190#discussion_r1064114035). This post tries to retrospect the detour and find out what I can optimize.

Let's use the thinking framework of start doing, stop doing, and continue doing.

Not Fully Understand What I Launch

I made an example of driving script without GUI. This is good for reproducing and boost my iteration time of development. However, I did not know sufficiently enough when I wrote that example, so I thought my driving script used the function of first-order derivative calculating.

I used debugger to read code, and I assumed the debugger would step through the function of first-order derivative calculating. Of course, the debugger never steps through where I expect because of my incorrect assumption that I thought my driving script used the function of first-order derivative calculating.

Then I started wondering if: 1) my debugger setting is incorrect. I was not confident of my configuration for that IDE since it is my first time to use debugger for c++ python binding, and also it is my first time to use debugger for c++ python binding in that IDE, vscode. 2) I did not mark breakpoints at the right place 3) Some mystery happened and the debugger did not step over/into the code section I want. This item relates to my bullet 1 (I am not confident of my knowledge about call stacks and compiler optimization?).

So I kept re-running the debugger and walk through the code with the debugger again and again, to see if I can have a "uha" or "eureka" moment "that I understand this code session, and it is / is not what I want". This process is boring and frustrating.

Protect Passion and Motivation

Endurance is virtue, but sometimes frustration could kill your passion and then your motivation. Without passion and motivation, you won't kick off or continue doing anything, then you will do nothing.

Stop Doing Endless Trial and Error, and Start Stepping Back a Bit and Think

Brainless trial and error is a sign of laziness: lazy to think and wish for luck. It is not only time-consuming, but, most importantly, without making process of the implementation , the bore and frustration could kill your passion and motivation.

Getting lost in the code may also make you not only frustration, and make you harder to resume your current work after context switch. Without a practical next step would be a big friction of motivation mentally for you to move the work forward.

If I stepped back a bit earlier and think twice like reviewing my process of driving script, rather than brainless trial and error, I will move forward earlier and get more fulfilled.

Alternative Solution: Check Another Running Example

Another solution comes to my mind is checking another running example of driving script. We may become numb by checking/review the same driving script again and again. Exposure ourselves to new driving script may bring us new stimulation and then help us find the blind spot.

What I Am Doing Well And Please Continue Doing Them

We have retrospected something I can improve, let's see what I am doing well and can continue doing that.

Use Debugger To Read The Code

When reading complex code or language that I am not familiar with, using debugger to read the code interactively is friendly for our human brain.

Make a Runner for GUI Testing Earlier

If the GUI application is follow the rule of "design for test", then try to make the manual GUI operation a runner by skipping or imitating the manual part. This would help us test easier and faster.