I'm actually pretty methodic (I used to program a lot when I was younger) - testing each new chunk of code until I'm totally happy, with lots of pauses and visual checking chucked in - not forgetting testing each idea for new code within a section I already know works and monitoring the output. My main subroutine is so big (the biggest if/else if statement you'll ever witness!) there is high risk of errors and I have one problem left which I know the cause of, just haven't dealt with it yet as I started to hurt my back at the PC for too long, leaning over and tweaking the model too.Will probbalby get it resolved early next week, then it's just ironing out some of the NXT's slightly unrealiable motor positioning. I'm using PID motor controls, plus touch sensors, plus stall sensing. I still get a motor that occasionally go too far or not enough due to the random nature of twisting a rubiks cube but I'm certain I can resolve it. I could have a machine that only rotates the cube 90 degrees in each direction, then motor control would be a doddle with stall sensing, but that would slow the solve down
I've always wanted to build my own cube machine rather than fix or adopt other people's. With this one I'm using someone else's code (Daniele's) to teach me how to code in C better, then replacing it with my own and slowly stripping out the original code as I understand what I'm doing. So satisfying.