I think the act of coding is fun, even if the domain is not.
I think the goal should still be fun. It’s not fun to lose the beans.
I think when the coding becomes overly fearful is when bugs and problems happen. Maybe you don’t have much leeway around the bean part, but you have a lot of room to test and validate that system. How do you make that system as fearless to work with as possible?
It’s a difficult goal, but achieving it is a worthwhile accomplishment. A difficult puzzle that some might find fun.
You’re describing nothing more than having the programmer be able to stay in the “fun/challenging” zone, above the “boring” zone and below the “stressful/helpless” zone. This is obviously very personal: What is boring for you may be challenging for me. Further, all learners of any subject are trying to stay in this zone. Professional educators are very aware of this and refer to it broadly as “student engagement”.
The goal of a software project, however, is not optimal individual learning about programming, it is usually something else.
> The goal of a software project, however, is not optimal individual learning about programming, it is usually something else.
Sure. It’s my goal. Not my project’s. My project doesn’t care about anything really.
The name of the game for me (the programmer) is maximizing my output without getting burned out. To that end, my intermediate goal is to find fun where I can. That’s the game.
I think the goal should still be fun. It’s not fun to lose the beans.
I think when the coding becomes overly fearful is when bugs and problems happen. Maybe you don’t have much leeway around the bean part, but you have a lot of room to test and validate that system. How do you make that system as fearless to work with as possible?
It’s a difficult goal, but achieving it is a worthwhile accomplishment. A difficult puzzle that some might find fun.