What I am finding is that arduinoing (my new word for it) is a consumer of free time of the worst order
Yup.
But here are some ideas on the programming side...
1/
Before you program,
write down what you want to happen. If there are multiple inputs, write down what you want the end results to be in
every circumstance. Programs are logical, we are not.
Writing down can (and should) include sketch graphs of input-versus-output.
If-then and
logical maps are extremely useful.
2/ If you're copying and pasting program lines from third party sources, try to
understand what these lines are doing. Don't work blind. You'll then get a grip of what each and every instruction is. Maybe you don't need/have to amend parts of it?
3/
Test the program in small chunks. Does a chunk behave the way you expect it to? If not,
why not? If it does, move on...
4/ Programs longer than (in my professional experience) six to ten screens of code with, particularly, subroutines and branching become mentally unmanageable. You can't hope to grok it in one. It's like juggling jelly. Stop for tea and you've lost something.
This is why
// and
/* ...
*/ become
essential. Note: I used
pink in Actionscript for
comments years ago, and I've hardwired myself to read anything in this colour as a comment, and nothing else. Your colour may vary. Comments are ignored by the processor, take just a little room, but allow you
to tell yourself (and others) what a section of code actually
does. For programs beyond the mentally unmanageable, a comment might be
a lifeline after just a few days of programming.
My favorite example is
// Andy, trust me, this works that after two days on a complicated ongoing project, meant that I could incorporate the routine that followed it without having to re-understand what the hell I'd written. A year later, I nodded at my then confidence and could
move on!
There is
nothing worse than looking at old code that you wish to adapt, code that
you yourself have written, that no longer makes any sense, because there are no comments in it.
5/ When everything's written, and everything works, save your code. Save it all over the place. Print it out. Spend a while writing down what the code does and how it works,
line by line. You
will need this information at some point in the future.
Andy