summaryrefslogtreecommitdiff
path: root/inboxes.mdwn
blob: 5ebe71f20298ec8c44a4688f2d3ff1c09364c451 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
Inputs and inboxes
==================

Consider how you deal with e-mail. All your e-mail arrives,
automatically, unbidden, unwanted, unloved, in one or more inboxes.
You might have one inbox for work, and another for personal use.
Further, you might have automatic filters that move some incoming
e-mail into other folders: software developers are often on many
discussion mailing lists, each of which goes into its own folder.
Each such folder would be a separate inbox.

A common anti-pattern for people is to keep e-mail in their inboxes.
They read it, and leave it there. The next time they read e-mail, there
might be some new mail, which they read, and leave there. Eventually,
the mail piles up a lot, and it gets hard to find a specific mail you
may need. Even more importantly, it gets hard to know which mails still
require you to do something. Perhaps there was a mail from your boss
you need to re-read? Or a mail from your mother that you need to reply
to? Or perhaps you replied to her already? Can't remember if you did?

Treating an e-mail folder both as an inbox and an archive of old mail,
and mixing it further up as a list of things to do, leads to confusion,
angst, and stress.

Let's make a small change to e-mail handling. Let's keep only
unprocessed e-mail in the inboxes, and do one of the following things
for every e-mail in each inbox, after reading it:

* delete it, if it is unlikely to be of further use; for example, spam,
  or stupid jokes from friends
* reply to it immediately, if you can, and it will only take a minute or two;
  for example, your mother asks if you'll be visiting next weekend, and you've
  already made plans with your partner to go on holiday, so you can reply
  at once saying sorry, not this weekend
* move it to a "needs replying" folder, if the mail requires a reply, but
  you don't have time to do that right now
* forward it to someone else, perhaps with a cover letter, if it's their job,
  not yours, to deal with it; for example, it might be a question only your
  boss can answer
* move it to an archival folder, if you think you might need it later on

(Compare the above list with "do, defer, delegate, delete, or file" from
the Quickie overview chapter.)

When you have time, you look into the "needs replying" folder, and reply
to one or more mails in there. After you've replied, you delete or archive
the original mail.

With this change, you have a better handle on your e-mail. You know that
anything in the inbox is unknown and needs to be processed, and anything
in the "needs replying" folder needs some action, and that anything you
might need later is in the archival folder. No other mails require any
action, and any mails that do require action are easy to find.

This will make you be much more relaxed about your e-mail. You never need
to worry whether you've replied to everything that needs replying. A further
benefit is that you're likely to reply to mail much faster than before.

Other kinds of inputs
------

The same processing principles work for all kinds of input, not just
e-mail. You should collect, whenever possible, all inputs in your
life into inboxes, which you regularly process until they're empty.
For each inbox item you decide whether to discard it, do the required
action immediately, do it later, delegate it to someone else, or
whether the item just needs to be filed.

Hackers tend to mostly deal with digital inputs, but there's always
some physical ones as well. If nothing else, TPS reports and voicemails
about their
cover sheets. If you have more than a couple of inboxes, you may
need to keep a checklist of them. For physical inboxes, it is often
easiest to have as few as possible, but experiment with what works
for you.

Your phone may also be an inbox. For example, text messages, voicemail,
notes you write on the phone, photos and videos you take, etc., are all
inbox fodder.

When an input can't easily be put into an inbox, put a proxy there
instead.

Inbox processing
----------------

Some inboxes you should empty frequently, several times a day. Some
can be done more rarely. For example, I usually process my
physical inbox once or twice a week, since any items that go into
it tend not to be urgent.

When you've processed an item from the inbox, you need to remove it
from the inbox. This means you need to have a place to put it, even
if it is only the trash. We will cover filing systems and other related
tools later.

Bug trackers: not really inboxes
--------------------------------

Hackers tend to deal with bug trackers, ticketing systems, and similar
systems. These are not purely inboxes. They're also sort of project
lists, and next actions lists. I have found it most efficient to use
them as places to trawl for inbox material. It's not possible to
remove items from bug trackers just because you've decided what to do
with them. Instead, I review the list of open bugs, and see if there's
anything there that's new or that I need to deal with. If there is, I
add a proxy into my own inbox (or, sometimes, directly as a next action).
I might have a project in my GTD system for a particular bug.

It's often the case that the total number of open bugs is so large
it's overwhelming. I have found only one way to deal with that: keep
dealing with subsets of the bugs that are most important, and try to
handle bugs at least as fast as they're reported. The rest of the
bugs may have to languish for a while, but if there's more of them
than you have time for, that's unavoidable.

Inboxes a la Lars
-----------------

Here are the inboxes I use:

* physical inbox: letters and other mail, notes written on paper, etc.
* wallet: receipts, other bits and pieces that get collected during the day
* notebooks: notes made while out and about and phone/laptop wasn't available
* backpack: random stuff tends to get collected there
* phone text messages
* phone call log
* phone notebook: I use a note taking application on my smartphone as
  a replacement for a notebook, when I can, because my handwriting font
  is abysmally hard to read
* e-mail: this is two inboxes (personal vs work); I no longer have a separate
  folder for each mailing list, everything goes into the same inbox
* feeds: blogs, news sites, etc.
* home directory for each computer I regularly use: tends to collect
  random downloaded files, notes, etc.
* web browser bookmarks: I move any bookmarks I want to keep to
  a link page on my website, the actual bookmarks are just a quick
  way to save something for later
* all of my bug trackers: I develop software, each project has a bug
  tracker, and those need to be reviewed; unfortunately, it is not always
  possible to treat the bug tracker as a proper inbox as separate from an
  archive
* inbox.mdwn: a plain text file (actually using markdown syntax),
  an all-purpose digital inbox for ideas, notes, URLs, phone numbers, etc.
* all my ikiwiki instance's comment moderation queues
* unprocessed photos from camera phone, real cameras
* laundry that is drying or is dry: this sometimes gets delivered on my
  desk by my partner, I then need to fold it and put it away; at other times
  I realize it's dry fast enough to take it down from the clothesline first

Information overload
--------------------

Sometimes processing inputs in this more efficient manner is still not
enough. It may be that you're getting so much input that it's just
not possible to deal with all of it. In that case, you need to filter
away unwanted stuff automatically, or stop it from being sent to you
in the first place.