When the option to ditch the keyboard is not available (Ie. always for me), the way I deal with this, is to change what I am working on. Ie. I may be weeks and

When the option to ditch the keyboard is not available (Ie. always for me), the way I deal with this, is to change what I am working on. Ie. I may be weeks and weeks in networking code and get it to a reasonable point but then get fed up, and move to 3D graphics code, then on to the caching system and then back to the networking code and so on. None of these sub-systems are complete in 1 sitting, but taking this iterative approach gives me a few things: - the change brings variety to the mind, which prolongs the burnout. - every "round" of work, I will learn something, thereby building my knowledge bit by bit. It is good to consume this knowledge bit by bit, giving time for it to be absorbed, which this approach allows for. - it means that at any one time, I have a good "overall" view of the state of the entire product. - i notice things that I did not when working on that sub-system the first time. Fresh pair of eyes, almost. Well, the disadvantage I suppose is that it is probably not the most efficient manner to work, but it keeps me relatively sane. Progress feels slow, but then there are moments where multiple sub-systems come together at the same time, and those are very rewarding.