Do I make progress on projects if I stick to 5 minute stubbable code functions? An experiment.

"ADHD is really executive function disorder" - Russell Barkely

The quote in the best talk ever made about ADHD goes something like that. In my quest to overcome this and learn how to actually get things done, I've tried many things. This is one of those tries, and I welcome you to read along with my adventure:

Do I make progress on projects if I stick to 5 minute stubbable code functions? An experiment.

I want to actually finish a programming project. But how? I took to the internet to find some inspiration, and found a Systematic Program Design Course with what seemed like a good system.

I gathered up the materials and set myself an experiment. I would try 5 to 10 rounds of attempting stupid tiniest chunks of email automation or website code (those being the projects I felt invested in at the time) in only 5 minutes. A significant part of my aim will be to make each function "stubbable"—that is, it returns a value such that the code is executable even if not correct.

If this is a good method of making progress on my projects, I expect my code to go off on an occasional tangent but for the functions to retain enough isolation to be fixable.

Below, I summarize the specific issues rather than include embarassing detail.

Data

Mar. 21 - None of the parts I created actually do what I need yet.

• 5 tries so far on email automater.  
• 2 functions stubbed,  
• 1 function deleted.  
• 4 function tests.

• Issues
• 13 complications
• 9 information errors
• 9 objectives failed
• 3 uncategorized errors

Mar 22 - tried to make an website code stub, the result was invalid.

• Issues
• 1 complication
• 2 information errors
• 2 objectives failed

Mar 25 - copied a function from website, made an instance function, made a new class. Spent a while on planning which components I'd need, then made a new class. Got sucked into looong work instead of stubbing, bad idea.

• Issues
• 3 complications
• 3 information errors
• 4 objectives failed
• 2 meta-issues

Mar 26 - starting over with wishlist of components for a log parsing utility.

• 3 functions,
• 5 stubs,
• 5 tests.

• Issues
• 2 complications
• 4 information errors
• 6 objectives failed

Mar 27, 28. worked on programming, mostly doing big pieces trying to force sequential progress. I think I really benefitted from the pieces already built, and that I made faster progress when I kept to the spirit of the chunking strategy. Not bothering trying to record issues on this, too scattered.

Review Apr. 8 - I quit sticking to the 5min thing, but spent a bit of time working out chunks to work on. I'm going over the timers I set even then, esp. with issue hunts.

Conclusion

Yes this helps, but with caveats. Stuff gets done if I time-constrain myself on making stubbable functions, *including* separate time-constraints on the functions to test other functions.
Followup

I continued to use this method to break down my work in projects, and am just now sharing this experiment on my blog.

After an experiment I always take a few minutes to think of Sanity Checks: These are other quick experiment ideas (ideally taking less than five minutes)

• How much can I actually type at mozy speed in 5min?
• Estimate how long it'd take me to refactor a data type throughout a medium-sized project.
• Time myself on refactoring the log parser to look nice
• Fermi estimate time wasted on a project because of having to look stuff up and verify syntax. 

Compare to time wasted hunting down accumulated errors for lack of a good feedback loop. Which is actually likely to be the bottleneck?

I rarely the time to do the followup tests I dream up, but I consider it good practice to habitually consider what being plausibly, identifiably wrong looks like.

----

Was this a nice read? Does something like this experiment seem worth performing for yourself? Take a couple seconds to comment yes or no!