what kills my productivity is when it takes more than 5secs to compile/load/whatever.
Of course, at that time, few companies were connected 24x7. My employer, for example, dialed in for mail and Usenet traffic exchanges a handful of times a day.
The debates over the first ANSI C spec in comp.lang.c were most entertaining.
I remember the joy when we got Cadence BuildGates to start running parallel synthesis and optimization runs. This allowed us to go from one build per week to two. If we were lucky!
You have created a problem for yourself that should not exist: do not task switch to Hacker News, task switch back to your text editor to re-read the code you just added or to work on the next part of the problem; or you could be working on two parts of the project at once and keep rapidly flipping back and forth between them. Your issue is not that you don't have the patience to wait for five seconds: it is that during those five seconds you are doing something useless instead of something else important.
In all seriousness, once you stop thinking of "patience" as "I need to be able to sit on my hands and wait" and instead think of it as "I now have the opportunity to do something else for the next period of time that I should try to make as productive as I can", I don't think ADHD is the problem anymore: the issue is making sure you always have a fun productive side task. You might find yourself accidentally doing things you realize later had low value for the time, but at least you got something done, right?
Put another way, you should embrace ADHD, not fight it: once you get into the habit of distracting yourself with just another task, the 5-10 seconds of compile time no longer matters, as you routinely switch to another task for five minutes every time you compile and it doesn't matter how long the compile took. You can do this with everything: I deal with delays in my web page e-mail client by having two or more clients open at the same time where I am working on two different search and reply tasks.
If you think about it, some really complicated coding sessions require keeping the state of many pieces of the program in your mind simultaneously (see, e.g., this: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-... ), including code in many different files. This is actually more difficult cognitively than simply working on two separate simple and well-contained coding tasks simultaneously.
I haven't tried this for coding, but the equivalent would be not to start running a test until you know what the next function/method/commit you're going to make is. Even if you have to screw around looking for potential problems in your code, or potential places to refactor, don't run the tests until you know what that next thing is going to be.
Here's the actual Hemingway quote:
The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.
I've since added a bash alias that helps: `alias beep="echo -e '\a'"`
`burkemw3@laptop$ compile ; beep` makes sure I don't have that excuse anymore.
Edit: need to use `printf '\a'` for that
`defaults write com.apple.dock no-bouncing -bool TRUE && killall Dock`
I have the same experience as you do, and these numbers of 2 seconds and 6 seconds really seem about right. If the test runs in less than 2 seconds, I can stay focussed on what I'm doing. By 6 seconds, I'm already thinking about something else. My personal experience has been that if the tests takes longer than 2 seconds, it is virtually impossible to do TDD. Instead you have to write large chunks of code -- or at the very least write several tests in one go.
I'm fairly well known in my current group for the 2 second rule :-) 2 seconds is really a long time for a modern computer, so my feeling is that if you can't build and run a large section of tests in 2 seconds, you've got a serious problem somewhere. When pairing with people who don't mind longer test runs, I've noticed that they never actually TDD. Instead they right large pieces of code (entire functions at the very least), or they write 5-10 tests all in one go. When I show people the normal rhythm of TDD, they suddenly understand why you need to have incredibly fast tests.
I also preach a 2 minute limit for the entire test suite. Kent Beck has talked about that previously (although I can't remember what number he used -- something like 2-4 minutes). He has even advocated simply throwing away long tests. Test coverage is less important than being able to run your tests quickly. I have found that if the test suite creeps up to about 10 minutes, the frequency of running that test suite is reduced to about once per day -- meaning that you have totally lost the context of the problem when you discover it.
Whatever you need to do to keep those tests running quickly is what you should do. Whether that means only running a subset, hot loading modules, stubbing out slow moving pieces (even the database), etc. I could write for quite a long time on testing strategy... This needs to go on my queue for a blog post ;-)
I'm typically editing in parallel with tests running. This can frequently result in no down time whatsoever owing to tests, even during a large refactor. Let's say I make a big refactor and 90 different test classes break (this is not theoretical). I modify some code that might make one of those test classes past, kick of a test run, and immediately go edit another failing test class. By the time I think I've got that figured out, the test run on the first has completed, and I can either move on, or try something else to fix it if it's failed again. This requires keeping the state of multiple test classes in your head simultaneously, but fortunately I'm good at that.
I've found that I'm extra productive in lisp because I'm evaluating and compiling a single function at a time, usually. I can cycle between testing that one function and fixing/finishing it very rapidly since it never has to build or reload the whole thing. A lot of the time it doesn't even require leaving the editor.
Too bad I've so far only been able to use lisp on personal projects.
3/61 tests passed...
It sure is hard to close that browser once it's all warmed up and full of interesting things though...
It sounds a little heavy handed, but it made a huge difference.
So, I know it's not the best solution, but I keep compiling/loading time REALLY fast. I.e. hot reloading is a good example of small thing that boost productivity insanely. But even in C++, I'd just work on a separate project and stub everything so that it compiles in a few ms. I know that if I need to recompile the whole codebase everytime I'm making a change I won't get any work done.
It's also because I tend to do the code/test really fast. I know some people who code for a few minutes, then test it.. so it's less of a problem for them.
Anyway, back to my hacking.. see, that sucker took more than 5 seconds to run :-)