Software programming/Art and Buddhist Practice - Pursuing creative activity I have read this question but I'm seeking more advice.

So it is quite obvious in the activity of software programming that we cannot help but think about programming concepts and also end up creating objects as concepts (as in Object Oriented Programming) and make something work. 

Now, I understand their usefulness in the context of what I am working on. 

Invariably, I get flustered and frustrated sometimes when something doesn't work because I am lost in the process of creation of that thing which I am currently working on, the cause being I am not mindful. Because mindfulness means there is an observer observing the mind and thoughts, which may lead to emotions. But in this activity the mind is busy creating things which would work on a system. 

Also, sometimes work is incomplete, and you do get an urge to work on something but also you could spend the time to do samatha or vipassana. How to decide efficiently in these cases?  

How to balance mindfulness, be equanimous and pursue this kind of creative activity at the same time? Or is this a curse that you cannot do it effectively in the process of creativity?  

I would like to know if someone dealt with this and how? Thank you.
Yes it's a problem.

To some extent an impossible problem, in the sense that ...


  The Difficult We Do Immediately. The Impossible Takes a Little Longer.


Quote Investigator also gives that as,


  "If it's possible, it's done. If it's impossible it will be done.





  I get flustered


Anyway, I read "I get flustered" as saying that when the going gets difficult then you suffer a crash.

Zen and the Art of Motorcycle Maintenance talks about this (which can happen as the result of some "set-back") as a "gumption trap" or "loss of gumption".

The way I perceive it as that I need to use my head for storage: my head is meant to be running (or at least simulating the running of) the software, simulating input data (possibly several data, all possible data), keeping in mind the expected output, comparing my model of the needed software with my observtion of the actual software, understanding the "steel threads" while using hygienic techniques to sanitize any errors paths. If there's a setback (e.g. an emotional setback) then I might lose all that and it takes a while to reconstruct it. If I'm (emotionally) unwilling then the afflictive emotion is what occupies (clouds) the head. And repeated setbacks might tend to train you to feel aversion (which is a vicious cycle).

See also Are mindfulness and flow related -- I wanted to find the answer[s] to that useful, but haven't yet.

My little understanding of flow is two-fold:


If you use a scanner (perhaps an MRI) to look at brain activity, they say a a brain in 'flow' state is less active than unusual, i.e. there are various parts of the brain which aren't active; perhaps that's like, those other parts of the brain are distractions, or like, various flaps and spoilers and undercarriage and so on is folded away when an airplane is cruising.
Flow state happens when the difficulty of the work is in a Goldilocks zone: not too easy (which is so boring that it doesn't hold your attention), and not too difficult (which a mind that wants to experience success might be averse to).


Consequently, two bits of advice:


Avoid distractions
If the work is too difficult then simplify it (e.g. analyze it, write it down, automate testing, etc.).


Furthermore:


If you stop working because you care too much, because you identify with the failing software, then try to be a bit more dispassionate
Conversely if you stop working because you care too little, then maybe reflect a little more on the (real world) consequences


A technique which can help is incremental development: take it from one working (satisfactory albeit non-final/temporary) state to the next ... perhaps like Tai Chi walking where you maintain balance during and after each step, or like rock-climbing where you move from one safe hold to another.




  and frustrated sometimes when something doesn't work


It's not going to "work" until it's 'finished'. The majority of your time is with it unfinished and therefore in a non-working state ... so you can't afford to get too personally upset about that, perhaps like a doctor couldn't afford to get too upset with everyone's illnesses (or a garbage collector with people's garbage).

Perhaps ideally you'll see that "not working" as a fault of the software (not a fault of you), and identify what and how to add to or remove from the software (including, your model of the software).

However the dissatisfaction you feel with non-working software is why they're paying you (to work with it) and why you're motivated to fix it: the subjective experience needn't be entirely pleasant all the time.

I guess that I may be more of a "feeler" than a "thinker" (than most other programmers are) on the MBTI, so I use my feelings (e.g. "satisfying" or "not satisfying") as a tool which gives me feedback of whether the software is working. I can't wholly recommend that (it has drawbacks) but that's maybe what I have to work with.

If you're aware you've become "frustrated" then a change in pace or situation might help (see also "the aha! moment"); I won't recommend you go for a cigarette, but maybe take a walk outside.




  How to decide efficiently in these cases?


A traditional way to do that is with a clocked schedule:


"For the next hour, I'm going to be working"
"I'm going to work from 14:00 to 17:30 with a short break each hour"


Whether that's "efficient" I can't tell you. Some other people swear by "being in the zone" at irregular hours.




  I would like to know if someone dealt with this and how?


Perhaps it's obvious they do. Maybe they master it, continue to practice it, and experience its "three characteristics" too.