Category Archives: productivity

On this page:

Figuring out how my temporary sleep schedule interacts with programming, writing, and drawing

I was thinking about how I can use these snippets of time to improve in programming, writing, and drawing. I realized that although I can easily imagine how other people can write or draw using fragmented time (writers scribbling in notebooks on top of washing machines, artists doodling on the subway), programming seems a lot less tractable. It doesn’t feel like you can break it up and squeeze it into different parts of your day as much.

It is generally accepted that context switching is evil when it comes to programming. So I’ve been carrying around this idea that Real Programmers are people who can pull all-nighters hacking on tough problems, holding elaborate structures in their heads. Your standard hero programmer stereotype, with the pinnacle being someone either building complex, cool stuff, possibly maintaining large and useful open source software.

Hence this little mental disconnect. I’m pretty certain I can get there someday if I really want to, but probably not if I extrapolate from current circumstances. Even maintaining a tiny piece of software sounds like more commitment than I want at the moment. (Heck, I might go a week without responding to e-mail.)

Fortunately, I spent my first few working years in a corporate environment, where mentors showed me that it’s totally possible to be an Awesome Geek while still working a roughly 9-to-5 job, having families and hobbies, and getting plenty of sleep. Thank goodness. So I have this alternate model in my head, not of a Hero Programmer, but rather of solid contributors who keep making gradual progress, help teams of people become more productive, and who enjoy solving interesting challenges and expanding their skills.

So let’s say that I want to play with my assumption that programming is the sort of thing that’s hard to squeeze into the nooks and crannies of one’s day, at least not the way writing and drawing can. I know that I can go through technical documentation and design resources even if my mind isn’t completely awake, and I can still pick up useful things.

What is it about writing and drawing that make them suitable even in small doses, and how can I tweak programming? Writers can think about stuff during other activities. I can reflect on ideas while walking or cooking, for example. When I program, I still need more of that back-and-forth with a computer and an Internet connection, but maybe I’ll need less of that as I develop more experience. I can set pen to paper during any spare moment, sketching a quick line and seeing where it takes me from there. I might not be able to do that with implementation, but I can use that same playfulness to explore design. Behavior-driven development makes it easier to break projects down into tiny, clear steps, and have a way of verifying progress (without too much backsliding!). Getting deeper into frameworks and tools will help me do more with less effort when I do sit down at a computer.

Okay. I can do this. Worst-case scenario, I just move slowly until I get past this particular phase. I’ve seen role models who’ve pulled that off well, so that’s totally cool. Best-case scenario, I figure out how to hack around some of my current cognitive limitations, and maybe that might help other people who find themselves in the same situation too.

This could work.

Figuring out how to deal with sub-optimal times

There are days when I’m at the top of my game. It’s easy to think, learn, write, draw, code, be present. Somehow, time stretches to accommodate the different things I want to do. Those are good days. I have them frequently enough so that my optimistic brain considers this the default, although there are also Really Good days when things totally rock.

Then there are times when I feel fuzzy or blah or frazzled or stressed. I guess you could call them sub-optimal, although sub-optimal is a funny word because there’s so much space below “optimal” that you’d spend practically all of your time in sub-optimal zone. Anyway.

I was thinking about the different variants of fuzziness, frazzledness, and such things. When you’re feeling out of it, sometimes you don’t have the ability (or inclination) to pin down exactly why you feel out of it and what you can do about that – either to help you recharge, or to at least mitigate the downsides of being down. It makes sense to come up with some ways to recognize and work around your brain state.

2014-09-04 Suboptimal Sacha

2014-09-04 Suboptimal Sacha

Here’s a quick list of sub-optimal states I sometimes find myself in:

  • Sleepy: Pretty straightforward. Tends to happen if I get less than 8 hours of sleep (probably even anything less than 8.3), or if my sleep is messed up by interruptions, buzzing brains, etc. Manifests itself as slowness, tiredness, yawns. The fix is easy: take it easy, nap, or go to sleep earlier.
  • Sick: The occasional cold makes me feel all blah and fuzzy. Hard to think creatively during these times. Good time to sleep or play video games.
  • Stretched: This happens when I’m trying to pay attention to too many projects or open loops. I feel a little frazzled around the edges. I can generally deal with this by writing down all the tasks into Org Mode and scheduling them appropriately, but sometimes I still get stressed around calendar events or multiple places to check.
  • Buzzy: When my mind skitters to and fro, usually because it’s been overstimulated by computers or video games. Hard to focus. Can be addressed by walks or sleeping. Can be minimized by not using computers late at night, and not trying to multitask important things during meetings.
  • Fuzzy: Hard to focus, but in a different way from buzziness. When I feel fuzzy, my thoughts feel slow and it’s hard to grab onto something. It’s a good time to do straightforward tasks that don’t require much thinking, like accounting. I can also break down creative tasks into smaller less-creative pieces, so I can still get small chunks of writing or drawing done even when my brain is tired.
  • Speeding: Sometimes I overlook details or things I need to do. When we catch that, it’s a good time to slow down and ask people to doublecheck my work. Related to buzziness and feeling stretched. Checklists, processes, and automation help a lot.
  • Absent-minded: Sometimes I’ll blank out when it comes to where I’ve put something or what I was about to do because I wasn’t paying enough attention. Related to fuzziness. Habits, reminders, and lists help; also, W- helps me remember or find things.
  • Anxious: Generally around being late, messing up, or forgetting important things. When I’m awake and reasonable, I know that the world tends to keep on going and that people adjust, but early meetings still disproportionately interfere with sleep. I can calm down my lizard brain when I’m awake enough to do it. Sleeping is easier with backup alarms and wake-up reminders.
  • Annoyed/frustrated: When things are more limited than I hoped they’d be, or I have to figure out complicated workarounds. Can handle this by dissociating emotion from dealing with things like Internet Explorer. Also, taking plenty of notes helps, since I can avoid having to re-solve the problem in the future. If I can share my notes, all the better.
  • Embarrassed: Sometimes I mess up, and sometimes programming/automation helps me mess up on a grand scale. Whoops. Somewhat mitigated if I focus on moving forward and fixing multiple gaps. Having team members provide air cover helps a lot too.

I’d been feeling a little bit stretched lately. When I recognized that, I made lots of lists of ongoing tasks and open loops. That helped a lot. =) I feel a little bit fuzzy in the evenings, but certain kinds of drawing and writing actually help with that instead of making it worse. Hmm…

Don’t worry about your tools in the beginning: Avoiding premature optimization

“What tools should I buy?” “What platform do I start with?” “What’s the best option out there?” Geeks have a special case of analysis paralysis at the beginning of things. We try to optimize that first step, and instead end up never getting started.

Here’s what I’m learning: In the beginning, you’re unlikely to be able to appreciate the sophisticated differences between tools. Don’t bother spending hours or days or weeks picking the perfect tool for you. Sure, you can do a little bit of research, but then pick one and learn with that first. If you run into the limits, that’s when you can think about upgrading.

Start with something simple and inexpensive (or even free). If you wear it out or if you run into things you just can’t do with it and that are worth the additional expense, then decide if you want to get something better. I do this with:

  • Food: We start with inexpensive ingredients and work our way up as necessary.
  • Shoes: Upgraded from cheap to medium.
  • Bicycles: Still on the first bicycle I bought in Canada, since it was enough for me.
  • Ukeleles: Glad I just bought the basic one, since it turns out it’s not quite my thing.
  • Knives: Okay, we splurged on this one and started with good knives, since I piggybacked off W-‘s experience and recommendations.
  • Drawing: I tried the Nintendo DS before upgrading to a tablet and then to a tablet PC. For paper, I tried ordinary sketchbooks that cost $4.99 on sale, and have been happy with them so far – although I might downgrade to just having a binder of loose sheets.

Don’t worry about what the “best” is until you figure out what your actual needs are.

There are situations in which the cheapest or the simplest might not be the best place to start. You can easily get frustrated if something is not well-designed, and some inferior tools like dull kitchen knives are dangerous. That’s a sign that you’ve run into your choice’s limits and can therefore upgrade without worry. Yes, it might waste a little money and time, but you’ll probably waste even more time if you procrastinate choosing (more research! more!) and waste more money if you always buy things that have more capacity than you ultimately need. You can tweak how you make that initial decision–maybe always consider the second-from-the-bottom or something like that–but the important part is getting out there and learning.

Realistic expectations, ruthless elimination, and rapid exploration

“You’re pretty organized, right? Do you have a system for productivity that I could use?” someone said to me. She sounded frustrated by her lack of progress on some long-standing projects. I shrugged, unsure how to help.

I don’t consider myself super-productive. I am, however, less stressed than many people seem to be. I’ve been learning to keep realistic expectations, get rid of less-important tasks, and work in quick, small, useful chunks.

Realistic expectations: We tend to overestimate how much we can do, particularly if we’re looking a week or two ahead. Even if last week was derailed by interruptions, we hope next week will be a smooth ride. I’m guilty of this myself. I compensate by expecting little of myself – just one to three important tasks each day, moving forward a little bit at a time. If I find myself with spare time and motivation, I check my other tasks for something to work on. It’s okay if I end up procrastinating something. That usually means I spent the time on something I valued more.

Ruthless elimination: “But how do I motivate myself?” This is another thing that people often struggle with. I use different strategies depending on what I need. For example, I’m currently working on a project with a high risk of failure and a fair bit of work. For me, it helps to amplify the perceived benefits, downplay the small pieces of work that I need to do (it’s just a small task), and downplay the risks (failure isn’t all that bad). On some other projects, I might decide that my lack of motivation is a clue that I should just wrap up the project, get rid of specific tasks, delegate work, or transform those tasks into things I might enjoy more.

Rapid exploration: After I adjust for realistic expectations and get rid of tasks through ruthless elimination, I think of tiny tasks that will help me move towards my goals. That way, I can explore and get feedback faster. Then I try to get as much value as I can from those steps, usually ending up with blog post ideas and lessons learned in addition to the thing itself. This also means that I can squeeze work into 15- to 2-hour chunks instead of waiting for a 4-hour span of uninterrupted, energetic time.

There are a bunch of other things that help me out (keeping outlines of projects and tasks in Org Mode, documenting as much as I can, knowing my tools well), but those three behaviours above seem to be different from the way many people around me work. Hope that helps!

Three productivity tools

Kosio Angelov asked: “If you could use only three productivity tools for the rest of your life, which three would you choose?”

2014-05-14 Which three productivity tools would I use if I could use only those for the rest of my life #emacs #productivity

2014-05-14 Which three productivity tools would I use if I could use only those for the rest of my life #emacs #productivity

I’m totally cheating with my answers. I can’t imagine using only three tools. What counts as a tool, anyway? Is the Internet a tool? What about the scientific method? Are we talking about apps, applications, platforms, systems, frameworks? =) Anyway, these are the answers that came to mind. They’re not your usual suspects, but I’ll explain why I like them a lot.

Emacs: This arcane text editor from the 1970s is capable of far more than most people think it can. It’s not an application, it’s a platform. I use it to code, write, plan, connect, automate, calculate, and so on. People get intimidated by its learning curve, but for me, it’s well worth it. I’ve been learning and blogging about it for more than ten years. Based on what I’ve seen, I could probably keep going for decades. I love the way you can dig into how things work, tinker with the code to make it fit what you want, and combine different packages. Great user community, too.

I’m not sure what to say to productivity newbies considering Emacs. It takes a certain kind of person, I think. If you’re someone who likes constantly learning and tweaking, you’re good at learning from what other people have written, and you’re not afraid to do a little worse in order to do even better in the future, this might be for you. You don’t have to be a programming geek, although it helps.

Linux: Again, I’m cheating by including an entire operating system, and probably I mean all the little tools I’ve gotten used to rather than the operating system itself. But I love being able to use utilities like grep and find (thanks, GNU!), stitching programs together, scripting things, installing other tools… People have suggested that I look into Mac OS X, but it gets a little on my nerves. I like Linux more. There are some programs I want to run on Windows, though, so I end up using Linux in a virtual machine so that I can do my development in a proper environment.

Ruby:  I use Ruby for little automated scripts as well as special-purpose web-based tools like QuantifiedAwesome.com, which helps me track my time. It feels like the way my mind works. I used to use Perl for scripting and I’m learning Python, but Ruby has the least friction for me. This may change as I get deeper into other languages, but in the meantime, Ruby is a good language for the kinds of things I want to do.

—-

All of these tools take effort to learn. They’re not like, say, Boomerang for Gmail or ScheduleOnce, which are easy to pick up and have clear benefits. My favourite tools require imagination, but they open up infinite possibilities. I’m not locked into one way of doing things. I still have limits, but they’re the limits of my own ideas and skills. I think that’s what I like about these tools. They have depth. Whenever I reach for some new capability, I almost always find it.

So, if you’re a newbie and this sounds intriguing, how do you get from point A to point B?

I think I got here by being interested in learning, being unafraid of tinkering, and having the space to do both. When you’re learning a complex thing, you might feel frustrated and intimidated by it. Good games design that learning experience so that people enjoy small wins as they develop their skills, but not all topics are like that. Sometimes you have to enjoy the learning for its own sake.

… which is an odd message to share with people who are looking for productivity hacks, maybe, but it’s something I’ve been thinking about lately. There’s a cost to picking general-purpose tools that are perhaps not the best at one specific thing, but experience results in compounding benefits. There’s a cost to keeping both your schedule and your eyes open, but perhaps it can lead to surprising things. There’s a cost to choosing the path of learning rather than the quick fix, but who knows what the true cost is down the road?

Thinking about my TODO keywords

It’s been twelve years since David Allen published Getting Things Done, with its geek-friendly flowcharts and processes for handling tasks in an interrupt-driven life. The way I manage my tasks is heavily influenced by GTD. I think in terms of next actions, waiting, and someday, and I have weekly reviews. I modified the TODO states a little to reflect what I need. It’s time to think about those states again to see what I can tweak and what reports I could use.

I use Org Mode in Emacs to manage my tasks and my notes. I can customize it to give me different kinds of reports, such as showing me all of my unscheduled tasks, or all tasks with a specific category, or even projects that are “stuck” (no next actions defined). Thinking about my processes will help me figure out what reports I want and how I want to use them.

Here are different types of tasks and how I track them:

  • Things I can work on right now (next actions): TODO
  • Things that I can work on after a different task is finished: currently WAITING, but probably better to implement with org-depend
  • Things I will revisit at a certain date, but I don’t need to think about them until then: TODO, scheduled (I used to use POSTPONED)
  • Things that would be nice to do someday, but maybe are incompletely specified or understood: SOMEDAY
  • Things I have decided not to work on: CANCELLED
  • Things I have asked someone else to do: DELEGATED
  • Things I can ask someone else to do: TODELEGATE
  • Things I am waiting for (usually not based on date) and that I need to follow up on: WAITING
  • Things I can write about: TOBLOG. These are pretty optional, so I don’t want them in my TODO list…
  • If something is a duplicate of something else – remove TODO keyword and add link?

I use the following code for an agenda view of unscheduled tasks:

(defun sacha/org-agenda-skip-scheduled ()
  (org-agenda-skip-entry-if 'scheduled 'deadline 'regexp "\n]+>"))

(add-to-list 'org-agenda-custom-commands
   '("u" "Unscheduled tasks" alltodo ""
     ((org-agenda-skip-function 'sacha/org-agenda-skip-scheduled)
     (org-agenda-overriding-header "Unscheduled TODO entries: "))))

So the to-do process looks like this:

  • Every week, review my evil plans and projects. Check my agenda without the routine tasks to see what new things I’m working on. Schedule a few tasks to encourage me to make regular progress.
  • Every day, go through my Org agenda (C-c a a) and do all the tasks that are scheduled.
  • When I’m done or if I feel like working on something else:
    • What do I feel like doing? If there’s a specific activity that I feel like:
      • Go to the relevant project/section of my TODO list, or check the TODOs by context (drawing, writing, etc.)
      • Clock in on that task.
    • If there’s a specific task I feel like working on:
      • Find the task, maybe with C-u C-c C-w (org-refile) and work on it.
    • If there’s a new idea I want to work on:
      • Use org-capture to create the task, file it in the appropriate project, and then clock in.
  • If I have an idea for a task, use org-capture to create the task and file it in the appropriate project.

How do I want to improve this?

  • Maybe get more used to working with contexts? I have all these Org Agenda commands and I hardly ever use them. I tend to work with projects instead. Actually, working with projects makes sense too, because that minimizes the real context shift.
  • Get better at reviewing existing tasks. I started tracking the number of tasks in each state (DONE, TODO, etc.), which nudged me to review the tasks and cross old tasks off. If I streamline my process for capturing tasks, filing them, and reviewing them by project/context/effort, then I can get better at choosing good tasks to work on from my existing TODO list.
  • Estimate effort for more tasks, and use that more often I have some reports that can filter or sort by estimated effort. I don’t use effort that much, though. Does it makes sense to get into the habit of choosing tasks by estimated time as an alternative approach? I usually have fairly large, flexible blocks of time…
  • Tag things by level of energy required? I want to take advantage of high-energy times. So, when I feel alert and creative, I want to focus on coding and writing. I can save things like paperwork for low-energy times. I can tag some tasks as :lowenergy: and then filter my reports.

Hmm…