I posted something about how I organize my own work, and I touched on "multi-tasking," and I realized immediately that I had touched something that required a bit more explanation.

I feel like a bit of an outlier to suggest that people spend time learning how to multitask better, particularly when the prevaling conventional wisdom is just "increase focus," "decrease multitasking," reduce "context switches," between different tasks. It's as if there's this mythical word where you can just "focus more" taking advantage of longer blocks of time, with fewer distractions, and suddenly be able to get more done.

This has certainly never been true of my experience.

I was, perhaps unsurprisingly, a bit disorganized as a kid. Couldn't sit still, forgot deadlines, focused inconsistently on things: sometimes I was unstoppable, and sometimes nothing stuck. As an adult, I've learned more about myself and I know how to provide the kind of structure I need to get things done, even for work that I find less intrinsically fascinating. Also I drink a lot more caffeine. I'm also aware that with a slightly different brain or a slightly different set of coping strategies, I would struggle a lot more than I do.

There are a lot of reasons why it can be difficult to focus, but I don't think the why matters much here: thinking pragmatically about how to make the most of the moments we do have, the focus that's available. Working on multiple things just is, and I think to some extent its a skill that we can cultivate or at least approximate. Perhaps some of the things I do would be useful to you:

• fit your tasks to the attention you have. I often write test code later in the day or during my afternoon slump between 2-3:30, and do more complicated work with my morning coffee between 9:30 and 11:30, and do more writing later in the day. There are different of tasks, and knowing what kinds of work makes sense for which part of the day can be a great help.
• break tasks apart as small as you can do, even if it's just for yourself. It's easy to get a little thing done, and bigger tasks can be intimidating. If the units of work that you focus on are the right size it's possible to give yourself enough time to do the work that you need to do and intersperse tasks from a few related projects.
• plan what you do before you do it, and leave yourself notes about your plan. As I write code I often write a little todo list that contains the requirements for a function. This makes it easy to pick something up if you get interrupted. My writing process also involves leaving little outlines of paragraphs that I want to write or narrative elements that I want to pass.
• leave projects, when possible, at a stopping point. Make it easy for yourself to pick it back up when you're ready. Maybe this means making sure that you finish writing a test or some code, rather than leaving a function half written. When writing prose, I sometimes finish a paragraph and write the first half of the next sentence, to make it easier to pick up.
• exercise control what and when you do things. There are always interruptions, or incoming mesages and alerts that could require our attention. There are rarely alerts that must cause us to drop what we're currently working on. While there are "drop everything" tasks sometimes, most things are fine to come back to in a little while, and most emails are safe to ignore for a couple of hours. It's fine to quickly add something to a list to come back to later. It's also fine to be disrupted, but having some control over that is often helpful.
• find non-intrusive ways to feel connected. While it should be possible to do some level of multitasking as you work, there are some kind of interruptions that take a lot of attention. When you're focusing on work, checking your email can be a distraction (say), but it can be hard to totally turn off email while you're working. Rather than switch to look at my email on some cadence throughout the day, I (effectively,) check my phone far more regularly just to make sure that there's nothing critical, and can go much longer between looking at my email. The notifications I see are limited, and may messages never trigger alerts. I feel like I know what's going on, and I don't get stuck replying to email all day. [1]

This is, more or less, what works for me, and I (hope) that there's something generalizable here, even if we do different kinds of work!

[1]

Email is kind of terrible, in a lot of ways: there's a lot of it, messages come in at all times, people are bad at drafting good subject lines, a large percentage of email messages are just automated notifications, historically you had to "check it" which took time, and drafting responses can take quite a while, given that the convention is for slightly longer messages. I famously opted out of email, basically for years, and gleefully used all the time I wasn't reading email to get things done. The only way this was viable, was that I've always had a script that checks my mail and sends me a notification (as an IM) with the From and Subject line of most important messages, which gives me enough context to actually respond to things that were important (most things aren't) without needing to actually dedicate time to looking at email.

For a few years, rather than really double down on some kind of electronic note taking and task management tool, I've mostly done that kind of work long hand, using pen a paper. I'm not great at using a pen to write, but it can be fun, and I quite enjoy the opportunity to take a step back, slow down, and focus on some brain work. I don't really have a system, as such, though I did read the bullet journal website and I guess I probably stole some of those ideas.

I definitely keep a pad on my desk that's some kind of loose idea of "things I want to get done today or in the next couple of days." Its less a "todo list," in the sense that it's not really an exhaustive list of everything that I need to get done, and I don't use so that I can write things down and then forget them, but more so that when I sit down at my desk, I can more quickly find something useful to do, and that every few days when look over the previous list, I can get a sense of what I've done (or not done.)

I also, and this is perhaps more interesting, have a notebook that's just for brainstorming. I've sort of intentionally selected "half-size" (e.g. 6.5" x 8.25") notebooks for this purpose. My routine is pretty simple: make a point of sitting down with a pen and a blank sheet of paper periodically and just brainstorming or writing about a topic. It's really easy to fill a page and often easy enough to fill the facing page with a bunch of ideas about whatever topic it is, usually something I'm writing but also sometimes code or another kind of project.

I think I developed this practice when writing fiction, which I don't seem to do much of, any more, (though I've been making notes for a couple of years so I suspect it'll happen,) but the idea is less to be systematic about the notes, or to collect them in ways that will be textually useful in the future, but more as a way of focusing and putting all or most of your attention on a problem for a few minutes. Often, though, the notes are useful, both because they force you to answer questions about what you're working on and can function as a creative jumpstart, both when doing work as a thing to review and also because sometimes once you start doing the mental work moving into actual work (typically for me, typing) becomes compelling. I suppose there is almost a meditative quality to the activity.

When thinking about writing fiction, the "write a half sized page full of notes" about an anecdote from a character, or a bit of worldbuilding, or a description of a plot progression (at any scale,) makes a lot of sense and use a useful exercise.

---

In some ways, I suppose, this is a little bit if a follow up to my Get More Done post, as one of the things I do help begin to make progress or make sure that it's easy to focus and have a clear idea of what to do when you're ready to write more formally.

It's really easy to over think the way that we approach our work and manage our own time and projects. There are no shortage of tools, services, books, and methods to organizing your days and work, and while there are a lot of good ideas out there, it's easy to get stuck fiddling with how you work, at the expense of actuallying getting work done. While I've definitely thought about this a lot over time, for a long time, I've mostly just done things and not really worried much about the things on my to-do list. [1]

I think about the way that I work similarly to the way that I think about the way I work with other people. The way you work alone is different from collaboration, but a lot of the principles of thinking about big goals, and smaller actionable items is pretty transferable.

My suggestions here are centered around the idea that you have a todo list, and that you spend a few moments a day looking at that list, but actually I think the way I think about my work is really orthogonal to any specific tools. For years, most of my personal planning has revolved around making a few lists in a steno pad once or twice a day, [2] though I've been trying to do more digital things recently. I'm not sure I like it. Again, tools don't matter.

[1]	Though, to be clear, I've had the pleasure and benefit of working in an organization that lives-and-dies by a bug tracking system, with a great team of folks doing project management. So there are other people who manage sprints, keep an eye on velocity, and make sure that issues don't get stuck.

[2]	My general approach is typically to have a "big projects" or "things to think about" list and a "do this next list", with occasional lists about all the things in a specific big project. In retrospect these map reasonable well to SCRUM/Agile concepts, but it also makes sense.

Joey Hess' blog of his work on git-annex-assitant has been a great inspiration to me. Basically, Joey had a very successful Kickstarter campaign to fund his work on a very cool tool of his that he wants to expand to be a kind of drop-box replacement. As part of the project, he's been blogging nearly every day about the work, his progress, and the problems he's faced.

I really admire this kind of note taking, and think it's really interesting to see how people progress on cool projects. More than that, I think it's a cool way to make yourself accountable to the world, and help ensure things get done.

By the same token, when your project work is writing, increasing daily workload by writing notes/posts rather than actually doing work is a problem, on the other hand, given the right kind of templates, and a good end of day habit, it might be easy and a good habit.

Anyone else interested in this? Thoughts on using rhizome versus some other area of tychoish.com? So many choices!

After doing the first pass of editing on my technical book, "Systems Administration for Cyborgs" on a screen and feeling utterly buried by it, (See: /posts/the-editing-hole,) and I'm considering different approaches for the next book. Specifically, for this novel I have, I'm thinking about getting the novel printed somehow and then editing it "analog style."

I'd love to hear feedback from anyone who has done this, particularly recently. Particularly from people who are very digitally savy. Here's my pro/con list:

I'm stuck in an editing hole, and not only am I not editing the things I need to edit, I'm not getting anything done.

I'm at a point where I have about 25 things on my personal task list, and 16 of them are editing related tasks: edit the article in this file, edit this fiction, edit this documentation, edit these would-be-blog posts, and so forth. It seems like I went on something of a six month writing bender, and while I did a little bit of editing during this period, I have clearly fallen behind.

There are a number of factors:

1. I've been making a point of putting editing tasks on the todo list because I want to make sure that I actually finish projects rather than just abandon them. I've not been particularly good with follow through in the past few years, so that's been a big personal improvement project.

The sad part is that my editing queue is probably 10-20 times larger, but I've got some projects on the less-actionable back burner.

2. I'm not a very good editor.

I'm awful at copy (or otherwise) editing my own work, and while I know that I've become better at this in the past few years. I still know that it's not perfect and so it seems sort of futile, which makes it hard to get inspired to do editing.

3. I find writing to be rewarding, and given the choice I will probably always choose to write new stuff. While this is clearly a learned response to the kind of work, this doesn't make the effect any less real.

4. I find editing to be really difficult work.

This is probably related to #2, but editing wears me out. I find it difficult to spend long periods of time editing, which makes it difficult to make any really substantial progress on the pile of editing tasks.

As a result, I take a long time to edit things, I'm most effective at editing in short bursts. I often want to break up longer editing tasks with other kinds of work just to keep a clean mind set. After a week or so of this, I have almost everything else done on the list, leaving me with a big pile of editing that looks even bigger for the lack of other things on the list.

So now, I'm trying the following:

1. I'm working on making editing tasks smaller, which will turn into more editing tasks, but it'll be possible to face editing tasks in units less than 10 or 20 pages.

2. Make more tasks for other projects.

There are two ways to get stuff done: 1) You can be really focused and work on one project at a time until it's finished, or 2) you can be working on a lot of projects in parallel and when you start to loose focus, you switch to another kind of project. The idea is that you end up getting more done because you're being productive more of the time. I subscribe to the second theory.

Here's hoping it works!

Onward and Upward!

Assumption:

1. git is pretty awesome, but it's conceptually complex. As a result using git demands a preexisting familiarity with git itself or some sort of wrapper to minimize the conceptual overhead.
2. The collaboration methods (i.e. hosting) provided by git, which are simple by design to allow maximum flexibility, do not provide enough structure to be practically useful. As a result providers like GitHub (and BitBucket and gitorious) offer a valuable service that makes it easier--or even possible--for people to use git.

Caveats:

• there are problems with using centralized repository services controlled by third parties, particularly for open source/free software projects.

  There are ways that GitHub succeeds an fails in this regard. but this dynamic is too complex to fully investigate within the scope of this post.

• If you use GitHub as designed, and the way that most projects use nGitHub, then you have a very specific and particular view of how Git works.

  While this isn't a bad thing, it's less easy to use git in some more distributed workflows as a result. This isn't GitHub's fault so much as it is an artifact of people not really knowing how git itself works.

Assertions:

1. GitHub's "fork" model[^fork] disincentives people from working in "topic" branches.

2. By making it really easy for people to publish their branches, GitHub disincentives the most productive use of the "git rebase" command that leads to clean and clear histories.

3. There's no distinction between a "soft fork" where you create a fork for the purpose of submitting a patch (i.e. a "pull request") and a "hard fork," where you actually want to break the relationship with the original project.

   This is mostly meaningful in context of the other features that GitHub provides, notably the "Network" chart, and the issue tracker. In a soft-fork that I would intend to merge back in, I'd like the issues to "come with," the repository, or at least connect in some way to the "parent." For hard forks, it might make sense to leave the old issues behind. The same with the network chart, which is incredibly powerful, but it's not great at guessing how your repository relates to the rest of its "social network."

The solution: keep innovating, keep fighting lock-in, and don't let GitHub dictate how you work.

I spent a lot of time in the past few months thinking about "automation," as a project to take things that take a long time and require a lot of human intervention into things that just do themselves, and I think this is the wrong approach.

While total automation is an admirable, it's difficult, both because it requires more complex software to deal with edge cases, but also because it's hard to iterate into a fully automated solution.

Let's back up for a moment and talk about automation in general.

Computers are great at automating things. When you figure out how exactly to accomplish something digitally (i.e. polling an information source for an update, transforming data, testing a system or tool,) writing a program to perform this function is a great idea: not only does it reduce the workload on actual people (i.e. you.) I think the difference between people who are "good with computers," and people who are "great with computers," is the ability to spot opportunities for these kinds of automations, and potentially implement them..

To my mind the most important reason to automate tasks is to ensure consistency and to make it more likely that tedious tasks get done.

Having said this, rather than develop complete task automations for common functions, the better solution is probably to approach automation on the bottom up: instead of automating a complete process, automate smaller pieces particularly the most repetitive and invariable parts, and then provide a way for people to trigger the (now simplified) task.

The end result, is a system that's more flexible easier to write, and less prone to failure under weird edge cases. Perhaps this is a manifestation of "worse is better" also.

Thoughts?

Onward and Upward!