I was addressing what the parent comment (from peeters) insightfully observed about the original article's four-step workflow description: getting to the next bug and fixing it could either be thought of negatively ("damn, I have another bug in my code") or positively ("I've solved this problem and made some forward progress"). Whether you find this negative or positive is a function of your mental state.
This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.
During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).
The author explicitly says that fixing bugs feels good. But the point (as I see it) is that the workflow often obscures the larger positive goals of the endeavor and tends to burn people out, and that's a net negative. You can argue that it shouldn't, but I don't think you can argue that it doesn't.
Everyone wants to be that 3rd happy mason. But that story doesn't tell you how to do that, it just suggests that it's a better way. Saying that it's just a function of your mental state is tautological.
The story tells you explicitly. Don't stare at your watch, think about the product vision.
Every day I go to work to fend off spies who want to steal your data. Protecting the powerless, defending your freedom! I will never meet you, and I will never even look at the treasure I am defending, and most of time is spent fixing broken configs, but I am doing it for a good cause, and at the end of the month I enjoy my paycheck too.
This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.
During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).