Category Archives: planning

Four-day weekend ahead

Today is Canada Day. Monday is a floater day for IBMers in Ontario. (IBM uses floater days to balance out the number of holidays across the provinces. Nice, isn’t it?) This adds up to a four-day weekend. You can get a lot done in a four-day weekend.

I make lists of things to do so that I don’t give in to the temptation to spend the time working. Time to review my initial list of unstructured time activities (update focusing on evenings and weekends), maybe think about plans for the summer and long-term plans.

Things to work on:

Chore-day: – just get everything ready for more good weeks:

  • Turn compost
  • Wash clothes
  • Tidy the house
  • Prepare large batches of food
  • Weed the garden, maybe plant another batch
  • Return library books and check out new ones
  • Reset the litter boxes

Other things I can work on:

  • Write a detailed blog post about our experiences with community-supported agriculture
  • Organize files on our server
  • Review old blog posts and write updates; organize thematically?
  • Prototype photo database W- was thinking about
  • Learn how to play Portal 2’s “Still Alive” so that I can help J- learn it
  • Work on Latin digitization and homework

I was thinking about sewing, but I’m fine in terms of clothes, so I don’t particularly need it. Last year, we used these long weekends for woodworking. Shelves and cabinets would be nice, but again, we’re doing pretty well right now.

Organizing and writing, I think. That’s the key. And maybe some more Latin.

2011-07-01 Fri 12:06

Planning for summer

J-‘s now on her summer break. We’ve been thinking of ways to help her use her summer well. There’ll be time for unstructured play and for hanging out with friends, of course, but it’s also good to help her develop initiative and life skills, fighting the temptations of video games along the way.

Both W- and I are working through summer because we’re saving our vacation days for Kathy’s upcoming wedding, so J- will need to be self-driven. She’s pretty good at dealing with the inevitable what-do-I-do-now moments (and we all get those, if we’re lucky). She often practises piano or ukulele, reads a book, or hangs out with friends. We can help by setting some challenges, nudging her to work on mastery or life skills, and giving her feedback on how she’s doing (such as for writing or math exercises).

Overall plans for the summer:

  • Read
  • Practise music
  • Hang out with friends
  • Prepare for next school year
  • Work on life skills

It’s often easier to pick from a list than to think of something to do in the moment, so here are some ideas for things to do:


  • Swimming
  • Biking
  • Exercising
  • Running, playing in the park


  • Reading a book (critical reading – maybe discussion at dinner?)
  • Working on reading exercises
  • Working on math exercises
  • Going to the library


  • Drawing (comics, sketches, etc.) – maybe put together a sketchbook or comic book
  • Writing notes, stories, and so on
  • Playing the piano or the ukulele
  • Visiting the AGO, the ROM, the science centre, etc.
  • Taking pictures
  • Exploring arts and crafts (ex: collage, sculpting)

Life skills

  • Learning how to cook
  • Making life better: cleaning, tidying, looking for ways to improve, etc.
  • Volunteering (Free Geek?)
  • Learning life skills: taking public transit, biking, etc.
  • Negotiating/persuading


  • Hang out with friends
  • Play video games (time-limited?)
  • Play board games

We’ll encourage her to add to this list, too.

We like the way her school uses rubrics to make it clear what excellence looks like. We’re not planning to use one to grade J- for her summer work – grading summer! what a thought – but it might be useful to work out one with her so that she can self-evaluate how she’s spending her time and so that she can motivate herself to push her limits. W- and I thought about the process first so that we can guide her through planning her own. Here’s the draft W- and I came up with:

Category 1 2 3 4
Physical Sat on couch all day / stayed indoors Basic calisthenics Extended physical activity Stretching your limits
Mental Played video games all day / watched TV all day 1 unit of work 2 units of work 3 units of work
Creative No creative output Drew / wrote / practised piano/ukulele / etc. Memorized part of a song / New story/comic/drawing to share Discussion of work
Life skills Mess Cleaned up after self Cleaned up after cats Made life better / cleaned up after others
Technology Played video games or surfed the Internet all day Practised IT skills (typing, presentations, etc.) Created something using technology and shared it with us or others Learned something on your own / experimented with tools

Thinking of ways to build scaffolds for J-‘s learning through these lists of ideas and rubrics for self-evaluation inspires me to make some of these for myself, too.

What would my discretionary-time activities look like?


  • Biking
  • Exercising
  • Gardening


  • Reading a book, maybe blogging notse
  • Improving development skills


  • Drawing – sketches, presentations, etc.
  • Writing notes, stories, blog posts
  • Playing the piano
  • Visiting the AGO, the ROM, the science centre, etc.
  • Taking pictures

Life skills

  • Preparing a new recipe or experimenting with a familiar one
  • Making life better: cleaning, tidying, looking for ways to improve, etc.
  • Learning how to drive

What would a rubric for myself look like?

Category 1 – minimal 2 – acceptable 3 – good 4 – awesome
Physical Sat and worked all day / stayed indoors Worked at standing desk / did some gardening Turned the compost / exercised Exercised for hours
Mental Did OK at work Solved new problems or built new functionality at work Read one or more books Worked on learning a new skill / Shared what I was learning
Creative No creative output Blogged / practised piano Created and shared pictures or sketches Learned a new technique / memorized part of a song
Life skills Mess Cleaned up after self Cleaned up after others Made life better

Thinking about blogging and planning ahead

Most of my blog posts look back – lessons learned, moments experienced. Some of them are written about the present: making decisions, figuring out knotty problems. A few of my posts look towards the future: goals, things I’d like to learn.

Here’s a rough categorization of the blog posts from the past two months:

June 2011 July 2011
Past 33 20
Present 1 7
Future 5 5

Most posts were written in response to things that happened that week, often even that day.

A blog doesn’t always have to look back. I’d like to get better at writing ahead: picking topics I want to learn about and writing about them. This is an odd sort of thing. I’m looking ahead to the things I want to reflect back on. They’ll still count as “past” blog posts, except I’m planning them for the future.

It’ll be like an editorial calendar – a list of ideas to work off, and thoughts about what kinds of information to seek out or save, and a way to plan upcoming posts. Something that gets me to write more post series like the one I did on the value of blogging.

Thinking about what chunks of knowledge I’d like to learn and share will help me write more deliberately instead of writing about whatever crosses my mind, although casual writing like that can also be helpful in patching together memories. I like the idea of a lifeline of books, gradually adding to an outline of knowledge I’d like to pass on. An Org-mode outline, even, so I can use it to organize my snippets.

This kind of list will help me separate brainstorming from writing. If I can keep a list of ideas that inspire me, then I can write even during the blah moments. It’s like the way that a brainstormed list of ideas for single-panel comics has helped me put together three for IBM’s intranet.

It will also help me plan research or note-taking. If I want to write about discretionary time, it’ll be good to track how I spend my time and research how other people spend theirs. If I want to learn more about happiness, I can supplement personal experience with research.

Planning ahead will help me recognize things I should stash in my archives for later use. If I want to write about my experiences doing buy-and-hold index investing over 10 years, I can think about what I’d like to include in that 2017 post. I’d probably want to mention my first investment here (1.116 shares of the TD Canadian Index e-fund, each share priced at $22.4100 on December 4, 2007) for extra flavour. I may also want to write about any hiccups along the way, like how I’m dealing with this current financial slump. (Portfolio underwater? Buying more.) Many writers have a snippets file, also known as a morgue. This blog and the Org text files I keep for unfinished or private notes will probably be quite a useful resource over the years, if I can make sure the data doesn’t get trashed.

I’m curious about time, decisions, writing, learning, and life. We’ll see how this works. =)

2011-08-11 Thu 07:29

Figuring out how to plan for a month

I’ve been doing weekly reviews since October 2006 (210 weekly reviews over ~260 weeks, or about 80% coverage), so I’ve got a good sense of what fits into a week. I’ve also consistently done yearly reviews I tend to do ones by age more than by calendar year, as I think it might be more useful in the long run. Monthly reviews and plans have been sporadic, though, and maybe that’s because I haven’t sufficiently distinguished them from weekly reviews.

I’m starting to figure out what months are useful for: experimenting with habits. A month is a good chunk of time to make one change to routines or habits. It might not seem like a lot, but if I assume a life expectancy of 90 years (quite generous), that’s still something like 750 months. If I assume that 25% of those months (~190 experiments) will successfully result in a 1% cumulative improvement in my quality of life, then than’s still almost 6.5x awesomer than if I didn’t. Of course, those are totally thumb-in-the-air estimates, and I’m not accounting for diminishing returns (or senescence, or distraction, or whatever). But the time is going to pass anyway, so I might as well. =)

Tracking will help me get an idea of my actual success or relapse ratio. It’s a little harder to quantify the magnitude of improvement, so I won’t worry too much about that. As I accumulate data, I’ll be able to ask more interesting questions.

Calculation function for Emacs Lisp, just in case this is useful for anyone else.

(setq sacha/life-expectancy 90)
(setq sacha/birth-date '(8 12 1983))
(defun sacha/memento-mori ()
  (let* ((expected (list
                    (elt sacha/birth-date 0)
                    (elt sacha/birth-date 1)
                    (+ (elt sacha/birth-date 2) sacha/life-expectancy)))
       (days-left (- (calendar-absolute-from-gregorian expected)
                     (time-to-days (current-time)))))
    (message "~ %d years or %d months or %d weeks left; make the most of them!"
             (/ days-left 365)
             (/ days-left 30)
             (/ days-left 7))))

I should build this into my personal dashboard. Hmm…

Learning plans and time budgets: packing things into 2012

Nudged by @catehstn‘s recommendation of my blog to @Tending2Entropy as an example of goal planning in personal life, I updated my learning plan with the things I’m planning to learn next year.

It was easy to come up with a quick outline. There are so many interesting things I want to learn. The tough part, however, was thinking about what I might actually get to do.

What does my cognitive surplus look like? I wanted to get a sense of how much discretionary time I actually had on a regular basis. I have about 20 weeks of data since I resumed time-tracking near the end of July. So that my numbers wouldn’t be thrown off by the vacation we took, I focused on the last eight weeks (graph: 2011-10-16 to 2011-12-11).

Over the eight-week period, I got an average of 3.5 hours of discretionary time per weekday and 7 hours of discretionary time per weekend day. I can simplify that to an average of 4.5 hours per day, which comes out to 1642 hours for 2012 (not including vacations, which include more discretionary time).

Around 40% of discretionary time was used for social activities. Let’s say that another 30% is a buffer for breaks and other things that come up, leaving 30% for focused learning. That gives me a time budget of around 500 hours. I want to do more than 1,000. Hmm.

Prioritization is important. I can focus on the things I want the most, then see how the rest of the year shakes out. Plans will change anyway, and estimates are flexible. My first few priorities for personal learning:

  • Android development, so that I can save time syncing and get more of the data I want
  • Goal tracking (handy for keeping the rest of my time in line)
  • Behavioural change (trying small experiments)

Another way to deal with the gap is to shift more time. Over those eight weeks, tidying took about 0.7 hours / day, and cooking took about that much time too. Let’s say half of future tidying and all of future cooking is outsourceable at $20/hour. That’s an additional 384 hours for a trade-off of $7,680 after tax, which is a large chunk of money. I’d rather save the money and let it compound for later use, especially if I time chores so that they take advantage of low energy. Besides, cooking and other chores are partly social time too.

I can shift time in other ways. For example, I can use commuting time to learn more about Emacs, Org, and Rails, so that will help too. I can also use walking time to record life stories if I can figure out a workflow for dealing with audio or short notes.

Good to know what the size of the box is, and how much I want to pack into it! Let’s see how it all works out…

Quantified Awesome: Squishing my excuses

I’ve been fiddling with Quantified Awesome, this personal dashboard that I’m building so that I can keep track of what’s going on in my life and use that data to make it even more awesome. For example:

  • Tracking my time helps me make sure work doesn’t tempt me too much, and that I make time for both personal projects as well as connecting with other people. It also helps me improve my time estimates: How much time does it really take to walk to the subway station? How instant are instant noodles?
  • Tracking library books reminds me before they’re overdue, helps me collect my reading history, and gives me a greater appreciation for where my tax dollars go.
  • Tracking my clothes helps me remember to wear different types of clothes more often, makes it easier to donate items I don’t typically wear, and encourages me to try new combinations.
  • Tracking the produce we get from community-supported agriculture helps us avoid waste.
  • Tracking stuff helps me remember where infrequently-accessed items are.

It turns out that other people are interested in this too. 21 people have signed up through my “I’ll e-mail you when I figure out how to get this ready for other people” page, and my mom wants to use it too. That’s awesome!

Now I have to go ahead and actually build it so that other people can use it. That’s scary.

And like the way I deal with other scary, intimidating, procrastination-inducing things, I’m going to list my excuses here, so that I can shine a light on those assumptions and watch them scurry away like the cockroaches they are and, if necessary, squishing them with a well-applied flipflop.

  • Excuse #1: Idiosyncrasy. The way I work might be really weird, and other people may not be able to figure out what to do.
    • What’s the worst-case scenario? “I have no idea how this works!” I end up with lots of crufty special cases because I can’t figure out how to reconcile different ways of working.
    • What’s the best case? I adapt the system to the way other people work, and I get inspired by what they do. I build a lovely, flexible web app and API.
  • Excuse #2: Risk. I’m fine with loading my own data into an experimental system, but if I mess up and delete other people’s data, I’ll feel terrible. Also, they might trigger bugs.
    • What’s the worst-case scenario? Catastrophic data failure, nothing saved.
    • What’s the best case? Regular backups help me recover from any major mishaps, and careful coding avoids more common mistakes.
  • Excuse #3: Support. I’m going to spend more time handling bug reports and feature requests, and less time building little things that might be useful only for me.
    • What’s the worst-case scenario? People get annoyed and frustrated because I’m currently focused on other things, like my work.
    • What’s the best case? I get the system to become mostly usable for people, and I use my discretionary time to build more features. People’s requests inspire me to build more stuff and create more value.
  • Excuse #4: Documentation. I’ll need to write documentation, or at the very least online help. This means confronting the less-than-intuitive parts of the system. ;)
    • What’s the worst-case scenario? I describe what currently exists, get frustrated because I want to improve it, and end up cycling between updating documentation and improving the system.
    • What’s the best case? I describe what currently exists, and end up improving it along the way. I build online help into the system so that it’s easy to change. There’s a blog that helps people learn about updates, too.
  • Excuse #5: Offline access. A web-based time tracker might be of limited use if you don’t have web access often. I’ve been working on an offline HTML5 interface, but it’s still buggy.
    • What’s the worst-case scenario? Early testers try it out, but get frustrated because of the lack of offline access.
    • What’s the best case? I figure out the HTML5 offline thing. Someone else might be interested in building a native app, and we work together on fleshing out an API.
  • Excuse #6: Impatience. If I bring people on too early, they might get annoyed with a buggy system, and lose interest.
    • What’s the worst-case scenario? People give it a cursory try, and give up in annoyance.
    • What’s the best case? Early users are extraordinarily patient. We figure out a minimal viable product for each of them – the simplest thing that could possibly support what they want to do. Over time, things keep getting better and better. Also, I build a decent export interface, so even if people move on to a different system, they’ll still have their data.
  • Excuse #7: Privacy and control. A bug might accidentally expose people’s information, which is not fun. I also don’t want to have to police the system for objectionable content, considering the thumbnail uploads.
    • What’s the worst-case scenario? Someone’s private notes get accidentally published.
    • What’s the best case? People sign on knowing that I might have bugs, and don’t save any super-secret or inappropriate information on the system.

Okay. I think I can deal with that. So, what are the smallest, least-intimidating steps I need to take in order to get closer to opening up?

  • Write a quick test to make sure that people’s data will stay private. We’ll make people’s accounts private by default, although mine will stay mostly-public.
  • Make a list of things that people should be able to do right now. (Not including new functionality!) Gradually write tests to nail down that behaviour.
  • Make a list of things that people may want to do some day. Eventually set up an issue tracker.
  • Enable Devise’s invitable feature so that I can set up accounts for people easily.
  • Doublecheck backups.
  • Bring one person on. Then the next, then the next…

It will still be better than nothing, it will be a good learning experience, and participation is purely voluntary anyway.

One step at a time.