The Fifteen Minute Maker’s Schedule

If you haven’t read Paul Graham’s “Maker’s Schedule, Managers Schedule”, I recommend doing that before you read this or it won’t make any sense.

The Maker’s Schedule makes sense to me in a work setting, but how about for side projects, things you’re trying to do after hours?

I started fomenting this blog post a while ago.  A very good engineer I know said something to me which I must admit rubbed me up the wrong way.  He said something along the lines of, “See, you like to write for fun, and I like to code for fun.” Actually, I really like to code for fun too, but it’s much easier to write than code in fifteen minute increments, which is often all I have available to me on any given day.

Let’s be clear about one thing: I don’t think of myself as a consumer.  I barely watch TV, only when my two year old insists.  I can’t tell you the last time I had time to watch a movie, and I haven’t played a non-casual video game since college.  I do read books, but books, too, lend themselves well to being read in fifteen minute increments.

I want to be a producer: someone who makes things.  Unfortunately my life is not compatible with these long chunks of time that Paul Graham talks about.  I think any parent of small children would say the same.  When you’re not at work you are on an interrupt-driven schedule: not controlled by management, but controlled by the whims of the little people who are the center of your universe.

This is how I work:

When I’m doing one of the mindless things that consume some of my non-work time – showering, driving, grocery shopping, cleaning the house, laundry, barn chores – I’m planning.  Whether it’s cranking away on a work problem, planning a blog post or a plot for a novel that I want to write, thinking of what projects to build for our next PHP book, mapping out a conference talk, planning code that I want to work on.  This is brain priming time.  When I get fifteen minutes to myself I can act on those things.

In other words, planning is parallelizable.  Doing is not.  Since I have so little uninterrupted time to *do*, I plan it carefully, and use it as much as I can.

When I get the occasional hour or two – nap time on a weekend (and to hell with the laundry), my husband taking our child out somewhere, or those blessed, perfect hours on a transcontinental flight – I can get so much done it makes my head hurt.  But those are the exceptions, not the norm.  I expect that to be the case until our child is a good deal older.

I had to train myself to do *anything* in fifteen minutes.  It didn’t come naturally, but I heard the advice over and over again, particularly from women writers, some of them New York Times bestsellers.  One has five children and wrote six books last year, so it can be done.  The coding is coming.  Training myself to code in fifteen minute increments has taken a lot longer than training myself to write in the same time.

The trick is to do that planning.  Train your mind to immerse itself in the problem as soon as you get into the zone where your brain is being underutilized.  This kind of immersion thinking has been useful to me for years for problem solving, and I just had to retrain myself to use it for planning.

In summary: don’t despair of Graham’s Maker’s Schedule if you just don’t have those big chunks of time outside of work.  You can still be a maker.  You can still be a creative person.  You just have to practice.  Remember: the things that count are the things we do every day, even if it’s only for fifteen minutes.

5 thoughts on “The Fifteen Minute Maker’s Schedule”

  1. I find that when necessary, programming tasks can be broken into discrete elements. Even for tasks that require something hard, there are often utility functions, structures, and outlines that can be done discretely in a given period of time. The problem comes when you run out of discrete tasks, and all that’s left is the hard ones that require uninterrupted time. But effectively managing the discrete tasks means forward progress on a regular basis, and that’s always a good thing.

  2. Amen! I’ve taken to coding after-hours projects, well, after-hours – i.e., when the kids go to bed. I have about an hour or two to code something before I’m exhausted from my “interruption-driven” day.

    Another tip: leave the editor open, as Joel Spolsky suggests. There’s a big mental hurdle in just *opening* vim into your after-hours project. So leave it open and hide it during the day. Alt/Cmd-Tab to it and you’re immersed into the project within a minute or so.

  3. This came along at a really good time for me, I’m going to stop procrastinating and go back to chipping away at the things I believe in – one tiny piece at a time!

  4. Hi Laura! I’ve sent some comments regarding the PHP/MySQL book to Luke via twitter, but that’s not the best medium… May I send further comments via email? Thanks, and it’s great to hear that a new edition is in the works!

  5. what really helps me when I’m coding in small chunks of time is to make sure not to leave the screen till I get my next thought thread up on the screen. so someone starts crying and I just finished looking at the code and realizing a value I expected as missing… before I pick up the kid, I flip my screen over to my db interface. then when I sit back at my screen it helps me to pick back up which where I was. leave the editor open yes and keep your screen on the part of the problem where you are progressing.

Leave a Reply

Your email address will not be published. Required fields are marked *