The article first talks about the benefits of sophisticated code, you can grow while debugging it. Further on the concept of flow is explained.
Somehow there is a mismatch.
In the graph depicting flow, you see that you achieve best results flow- (and as a bonus, grow-) wise, when you take up challenges slightly harder than according your comfort zone.
The mismatch is that debugging is quite a large notch harder than implementing. There might be a race condition, or you understood a used API differently from how it was implemented. Or some FPGA's software registers are poorly documented. So you spend a lot of time in the frustration/imposter syndrome zone, as opposed to the comforty growing, flow zone.
The effect is much more explicit when the code or design is not from your own hand. You first need to understand other people's clever tricks or paradigms and find the holes in the reasoning or even worse, in the several half baked refactorings that happened afterwards.
Somehow there is a mismatch.
In the graph depicting flow, you see that you achieve best results flow- (and as a bonus, grow-) wise, when you take up challenges slightly harder than according your comfort zone.
The mismatch is that debugging is quite a large notch harder than implementing. There might be a race condition, or you understood a used API differently from how it was implemented. Or some FPGA's software registers are poorly documented. So you spend a lot of time in the frustration/imposter syndrome zone, as opposed to the comforty growing, flow zone.
The effect is much more explicit when the code or design is not from your own hand. You first need to understand other people's clever tricks or paradigms and find the holes in the reasoning or even worse, in the several half baked refactorings that happened afterwards.