Interlude

I've got too much on to want to do this.

Where I'd like to go from here is:

1. Making good use of the time that you do have
2. Cheap ways of managing what you want to do in that time

Here's a quick dump of what I'd like to cover:

• Limit "in progress" stuff
• Ways to visualize what you're working on (esp. kanban)
• Half-arsing things as a key productivity technique
• Multi-tasking is the mind-killer
• Interruptions are the mind-killer
• Procrastination is the thief of time, and often makes people feel busier than they are
• Pomodoro is a great way of churning through things

Probably other stuff too. But this is going to have to be it.

I'm constantly doubting myself over whether I rely too much on experimentation vs sitting down and figuring things out.

When I go through a bunch of tests to figure out what's going on, I worry that if I were more intelligent, I'd be able to reason about code and not need to try things as much, saving a bunch of time.

Contrariwise, when I am deep in code trying to figure things out, I worry that I'm taking too much time trying to deduce things when I could save time and do an experiment or three.

Step 1. Get an accurate picture of your time

The next, easiest step for getting organized is to use a calendar, and use it properly.

If you're using something like iCal or Google Calendar then you want to have at least two calendars, which I'm going to call Appointments and Information.

If you have separate personal & work calendars, set things up so you can see them both in the one app.

The Appointments calendar should have exactly all the things on it which are things that you intend to go to, whether virtually or physically. It should have every obligation that you've have that must be fulfilled at a certain time and a certain place, and it should have nothing else.

Examples of good appointments:

• Church on Sunday at 6pm at St Saviours
• Weekly 1:1 with $manager at 4pm on Thursday
• Meet Bob at easyGym at 7:00am on Monday, Wednesday, Friday

Examples of bad appointments:

• Practice Latin vocab
• Gym
• Do taxes

All of the good appointments have specific places and people. If you don't go to those appointments, someone will notice. If you want to change those appointments, you have to talk to someone else.

By contrast, the bad appointments are just things that you want to do with some vague intent to do them at a certain time.

Having "Gym" down on your calendar at 11am on Tuesday might nudge you to get up from your desk & go work out, but it might not. It's just an intent to go to the gym at roughly 11am. Having an appointment to meet a friend at the gym to train together is an entirely different thing.

Why bother with this discipline? Because then your Appointments calendar provides a hard landscape to your day. You can look at your calendar and immediately see all of the things you have to do without having to do any mental filtering. You can entirely offload thinking about what the time is and how long you have until a thing, freeing up valuable head space to get things done.

By contrast, the Information calendar is just a way of storing any time-bound information that you have. e.g.

• birthdays
• deadlines
• dates for conferences you might like to go to

As soon as you notice either calendar deviate from reality, fix either the calendar or reality.

Once all this is done, you'll want to check your calendar first thing every day.

If all of this is obvious, and you're already doing it, then congratulations, you're already ahead of many people I've spoken with and clearly understand one of the key elements of time management: having a reliable exobrain.

Step 0. When you find yourself in a hole, stop digging.

Start saying 'no'...

To others

The absolute first thing to do is to stop making the situation any worse, and the way to do this is to stop agreeing to new things.

Saying 'no' can be difficult, but there are plenty of websites out there with tips on how to do it.

A favourite of mine is "I'd love to do that, but can't right now. Could you get back to me in a couple of weeks if you still need it done?" This puts the onus on the requester to get back to me, and still shows my willingness to help.

Genuinely busy people who are asking you for things would much prefer a swift & honest 'no' instead of a 'yes' without follow-through.

To yourself

Of course, the trickiest person to say 'no' to is yourself. However, the part of you that wants to do things and has great ideas is what got you into this mess, so you have to be ruthless with it. When you catch yourself starting something, say 'no'. Write down the thing you were starting and stick it in a drawer. We'll get back to it later.

To calamities

The other main source of new work is things going wrong.

If your car breaks, you probably have to fix it asap. But maybe if you're really busy and can afford it you can take cabs or public transport until your workload eases up?

If the wall clock in your lounge room breaks, it'd be good to fix it, but maybe you don't have to? Probably everyone who needs to know the time has a portable time keeper anyway.

When things go wrong, you normally have to fix them. This sucks, because you have to expend precious time, energy, and attention to maintain the status quo.

Before you do this, ask yourself if the status quo is really worth all that.

You can frame it as an experiment: how about we try without a second car/lounge-room clock for a week and see if we miss it?

The other day, my friend Jason Imms complained:

I can't find the time to come up with and implement a time management solution :/

At the time, I wasn't willing to give advice. Someone in that situation needs support & hands-on help more than they need random 140 character pontifications from want-to-be time management gurus like myself.

However, I've been giving the matter some thought, and want to share what I think of as an emergency triage approach to time management.

According to the Telegraph, the BBC is going to cut recipes from its website. Recipes. That means BBC Food will become a thing of the past. Goodbye cheesecake! Goodbye elegant cheesy mushroom starter things! We hardly knew you.

Why are they getting rid of it? Sometimes we cut services because they cost too much, other times because they just aren't very good. This time, it's because the BBC is just too awesome at publishing recipes.

We are taking down BBC Food because it is too good, because it is better than any alternative.

But does cutting the recipe section from the BBC website actually make anyone's life better? Was anyone really suffering because it was a little too easy to find twelve ways to cook with asparagus?

Obviously not. At least, not individual people. Newspapers, on the other hand, were being oppressed. They can't compete with the BBC online, the poor darlings, and hope that once the BBC stops giving us hints about what to do with artichokes, they can at last flourish as they were meant to.

Maybe so. Maybe the press are a bit hard done by and it's about time we gave them a break. Maybe.

I've got three strategies for solving problems:

1. Thinking about it
2. Trying things
3. Knowing the answer already

In a whiteboard interview, "thinking about it" doesn't seem to work for me, because I think of all sorts of stupid things on the way to figuring something out.

"Trying things" depends a lot on the interviewer. Some seem to wonder why I'm trying something so obviously wrong. Also, whiteboard code isn't executable, so trying things looks like asking the interviewer for the answer.

Knowing the answer already thus the most sensible approach.

Check your equipment #1

Before we can get on with proper sciencing, we're going to need to check our equipment.

Our primary equipment are brains. We each have direct access to one, and indirect access to many more.

I don't know what brains are made out of, but they are pretty useful. They also don't behave the way you might think.

Daniel Kahneman has written an amazing book called Thinking, Fast and Slow that goes into this in detail, and really ought to be read by everyone. You can also read about cognitive biases on Wikipedia.

In a nutshell, the first and most important thing we can do to be more scientific is to distrust our brains. Our guesses are probably wrong, our memory is probably wrong, the examples that we think of are suspect, the estimates we make are overly optimistic, we value stories over data, we find it hard to process information that doesn't fit with our existing opinions, we answer the questions we find easy rather than the questions that matter.

Next time: our next-most important tool, and some ways we can use it.

What is science?

As I said, I'm not a scientist, so I'm going to pull in a few ideas from Richard Feynman, who was a scientist, and whom a lot of people say was a pretty good one.

The test of all knowledge is experiment

I like that. I don't think it's entirely true, but if you're going to do science or be scientific, then you probably need to think that way.

Science is more than just doing a lot of experiments, it's also:

• making explicit guesses about reality
• designing experiments to falsify or verify those guesses
• actually performing experiments
• interpreting the results of experiments
• changing your beliefs based on the result of experiments
• sharing the process, details, results, and interpretations of experiments
• questioning the validity of experiments
• learning about past experiments and understanding what they mean
• making stories out of experiments to help yourself and others understand new things
• insisting on having evidence

And probably many more things. All of this is a lot of work.

Why we can't do science, continued

Initially, Zero & One are talking about heuristics for measuring how good something is: maturity, quality of tools, documentation. Then Zero tells an anecdote about someone who agrees with them.

Two rightly points out that this is a terrible decision making process, and then Zero and One start hashing out a way of doing an experiment. They quickly realize that there are way too many variables, and that nailing down a definition of "good" or "better" that can actually be experimentally verified is essentially impossible. All the things they can measure are incredibly specific, and they've got no way of mapping back from there to a general notion of "goodness".

So, what are we to do?

Like Two, we could use the difficulty of making rational, scientific decisions as a reason to stick with the status quo. Or like Manager, we could look to a trusted authority: the crowd; our instincts; a trusted advisor.

Can we do better? Is there a way we can actually use science?

Imagine a kind of documentation that appeared exactly when it was needed, and that could take the user's current context into account.

What could we do with such documentation? How good we make it?

This form of documentation exists today. We call it "error messages".

Why we can't do science: a parable

Say we're going to write a new computer program. Programmer Zero says we should write it in Rust, Programmer One says we should write it in Haskell. Programmer Two says we should be scientific about this.

Zero: Let's write our new web app in Rust!

One: No, let's write it in Haskell, it's much more mature.

Zero: Rust has much better tooling and documentation, and is has a gentler learning curve.

One: Haskell's awesome type system will prevent bugs before they happen. Besides, we don't need a systems programming language for a task like this.

Zero: Yeah, but nobody uses Haskell. Rust, on the other hand, was recently used for $AWESOME_THING and they said their experience of it was great and they just IPOd for five billion dollars.

Two: We shouldn't make such important decisions lightly. Let us be scientific about this.

Zero: OK, let's do an experiment. I'll spend a month writing it in Rust, while at the same time One can spend a month writing it in Haskell. At the end of the month, we'll see which is better.

Two: But how will we decide which is better?

One: Well, I guess which one is most feature complete, and performs the best.

Two: Performs the best how?

One: Since it's a user-facing app, I guess latency is the best metric?

Two: Maximum latency? Latency for all requests? Latency under what load? With how many servers? Would the Go one be better if it had lower maximum latency but required twice as many servers?

Zero: Yeah, also, we haven't mentioned bugs. Or maintainability. I don't even know how to measure that.

One: And I've got to do twelve interviews over the next month, and I'm on holiday next week. Maybe we'd get to the end of it and decide that Rust was better but actually it was just because I just couldn't do as much work.

Two: So we can't make a decent decision about which is better. Therefore, we should do it in Python, which is what we've used for everything else.

Zero: That doesn't make any sense.

(enter Manager)

Manager: I just went to a conference and everyone was talking about Go. Let's write the new thing in Go—I want to see it live in two weeks. Also, can we make it a microservice?

I'm calling this "Science for Busy People", but maybe it's not actually science. I'm not a scientist, and have never trained as one.

This stream is based on three assumptions:

1. Science is great
2. Science is expensive
3. You can't afford proper science because you've got things to do

The intended audience is working programmers.

I'm going to start with some introductory material—a parable, an explanation of that parable, defining some terms—and then I'm going to get into some specific things that I think can help.

Serious business!

Things that I personally think are optional, but are good ideas, especially if you've got a bit of momentum or you're hiring lawyers.

• Logo / branding
• Contributor agreement (@popey) [jml still doesn't think this is necessary or desirable]
• Release schedule (Bjoern Michaelsen)
• Roadmap (Jani Monoses)
• Documentation style guide

Additions from others:

• Somewhere to file bugs (@sil)
• Code of Conduct (@popey)
• Installation instructions (@sil)
• OS-specific packaging
• A name (@puzzlement, Jani Monoses)
  • Make sure people can search for it! (@puzzlement, @froztbyte)
• Forum for announcements (Jani Monoses)
  • Blog?
  • Twitter?
• Landing bot (@bigjools)
  • Something that acts on code review approval by merging, might not be necessary depending on overall setup. (e.g. Github doesn't have "Approve" it just has "Merge").
• A dependency list (Chad MILLER)
  • If you have a hermetic build process, you don't need another one of these
• Instructions / script for running from source (@froztbyte)
  • Remember, plenty of potential users/contributors will be unfamiliar with your language's toolchain! @froztbyte [good call - jml]
  • "./makethisrun --devmode should be able to give me all I need to tweak things. debug logs, warnings of missing packages/tools," @froztbyte

To write a computer program, you need to provide a bunch of other guff that has little to do with the program you are writing.

• Licence
• README
• Build system (ideally an 'hermetic' build system that insulates your build configuration from the surrounding environment)
• Test runner
• Documentation!
  • Something to build docs
  • Something to publish docs
  • API docs
  • Long-form documentation (e.g. how to, design)
  • Change log
• Release process
• Code review system
• Version control
• Web site
• Discussion forum
  • IRC?
  • Mailing list?
• Version numbering
• Coding standards
• Linter to support coding standards
• Continuous integration (ideally something that prevents merging patches that break tests)

Mucking around a lot with iPython notebook, using it together with pandas and ggplot to do rough-and-ready data exploration.

Folding

I'd really love folding support across markdown sections.

Hierarchy

In fact, I'd like better awareness of Markdown sections in general. It can be very easy for notebooks to get quite long. Being able to fold sections, or see a table of contents would help immensely.

Real-time collaboration

I've used Google Docs a lot for real-time collaboration. For that task, it's great. It's a fantastic way to run a remote meeting, brainstorm an idea, or coordinate a wedding.

I'd love to be able to do the same thing, but with iPython notebook.

One of the things that gets in the way is that the iPython notebook is an arbitrary code execution framework.

Experiments

Lots of the time I'm just exploring data, and that's cool. That needs to happen.

But sometimes I end up in the weeds and only later realize that I have a specific question I'm trying to answer.

If I have a question I'm trying to answer, a hypothesis that I'm trying to falsify, then I should write it down (see Hammock-driven development). Better yet, when I've managed to falsify it (or failed to do so), then I should write that down and somehow link it to the question or hypothesis.

Wouldn't it be great if the notebook itself somehow supported or encouraged this?

Tangents

Often when working on a document, I deliberately go on a tangent. Half the time I end up deleting the cells involved once it's done.

What I'd like to be able to do is keep the tangent, but flag it as a sidebar, or an appendix, or even another notebook.

After doing a bit more with static languages (esp. Rust), I think the thing is that static typing requires more design up front.

I'm not sure this is a Good Thing. Nor am I sure it's a Bad Thing. Sitting down and thinking about a problem before trying to solve it can save heaps of time and net you a better result (see Hammock-driven development).

In team situations in particular, it helps so much to write down the problem you're trying to solve.

But then there's a lot to be said for interactive exploration too. That's much harder in a static language, where you have to define your data types in advance. Where generally you don't have a REPL, and even if you do it's less useful than the equivalent dynamic one.

Buildbot

Check that it's passing before proceeding. If it's not passing, make it pass before even bothering to review anyone else's tickets.

If you can't make it pass, then at least try to understand the intermittent failures in advance.

Twisted Checker

I got a failure from the Twisted Checker for a branch that introduced no new changes, despite it being green on trunk. I don't know why.

Notes from #7633

• Style – Don't need to review for style-guide compliance – that's the twistedchecker buildbot's job
• Tests – There's a "buildbot" link in the "branch" field of the ticket description – check to see it's green before approving
• Actions – Always say what the next step should be

(rephrased from glyph's email)

twisted-dev-tools

Available at https://pypi.python.org/pypi/twisted-dev-tools

$ mkvirtualenv twisted

$ workon twisted
(twisted)$ pip install twisted-dev-tools
(twisted)$ mkbranch --help
Usage: mkbranch [options]
Options:
      --version  Display Twisted version and exit.
      --help     Display this help and exit.

Setting up dev environment

git set up for core developer

Relevant instructions from: https://twistedmatrix.com/trac/wiki/GitMirror

$ sudo apt-get install git subversion git-svn

$ git clone https://github.com/twisted/twisted Twisted

$ git config --file Twisted/.git/config --bool --add diff.noprefix true

$ cd Twisted

$ git svn init --stdlayout --tags tags/releases --prefix origin/  svn://svn.twistedmatrix.com/svn/Twisted/

$ git config --add svn-remote.svn.pushurl svn+ssh://svn.twistedmatrix.com/svn/Twisted/

$ git config --global --bool svn.rmdir true

Reviewing Twisted tickets

It's been a while since I've done this regularly. The technology has changed, and maybe the processes too.

This stream tracks notes, mostly made for my own benefit.

The documentation on the wiki is pretty good, but spread out over quite a few pages. Writing things down here helps me remember them, and maybe will act as a quick reference.

I've used various todo list systems & software, and I hate them all.

Here's roughly what I want. I'll try to remember to update as I think of things.

Projects

So I can

• make plans
• group actions together
• see progress
• limit work-in-progress

Contexts

So I can see only the things that it's possible for me to do right now.

Really, this is flagged for dependencies.

Technology

• Android support
• OS X support
• Encrypted cloud-based storage
• Offline usage
• Flawless synchronization
• Pluggable storage backend so I can comply with security policies of various employers
• Import and export
• Open format

Philosophy

• Easy capture of random ideas and things that come up
• Minimize sense of obligation for following up on random ideas
• Limit work-in-progress
• Remind you of why a thing is important
• Because I'm a human, that's often who it's for – a face
• Encourage me to say 'no' to things
• Work on one thing at a time
• Emphasise and reward things done, encourage the transformation of done tasks into meaningful achievements

With apologies to Frank Herbert and Nadia Boulanger

Attention

I must focus.
Continuous partial attention is the mind-killer.
It is the little death that denies all we have of life.
I will pay attention.
The distraction will pass over me and through me.
And when it has gone past I will affirm the value of what I am actually doing.
Where the distraction has gone there will be only one thing.
Only the present will remain.

I'm working on a project in my spare time to make doing my home finances easier. It's nothing serious, and I'm massively over-engineering it so I can have fun & learn things.

Presently, I'm rewriting one of the components in Haskell. Hmm. That's not true. It would be fairer to say that I've realized that a chunk of the code presently in Python is actually a separate component that ought to be run as a separate service, and given that, I'm rewriting it in Haskell.

It's a simple service that connects to a SQLite database (not my database, not my schema) and exposes a narrow set of APIs for things I want to do from that interface.

So far, it's in very early stages, but I've already been faced with some interesting questions.

Writing the code in Haskell has forced me to think very early on about how and when I want to run database queries.

Doing a database query requires doing IO, and if a function does IO that changes the type of the function. For example, a function that gets the balance for an account by doing a query might have a type signature like this:

getBalance :: Connection -> Account -> IO Amount

However, if you've already got all the information loaded (perhaps you've loaded the entire database into memory), then the function might look this:

getBalance :: AllTheData -> Account -> Amount

If this were in Python, I could reasonably defer the decision, because there'd be some messy object representing the state which would either have a connection or all the data or both, and the getBalance method would return an Amount and the calling code wouldn't have to care whether it did IO or not.

Is this a good thing? I don't know. It's interesting though.

If you are working on documentation and you haven't written down who it is for and why they are reading it and what they ought to get out of it, then you are wasting your time.

I am not against documentation. What I want to do is emphasize that the slap-dash way we apply the word often masks our mental fuzziness on deeper, more important issues: audience; purpose; outcomes.

Writing something out is an immensely valuable mental exercise. I find it clarifies thought, reveals areas of ignorance, and exposes assumptions.

But writing something for someone else? For a total stranger? That is both much more work and a very different kind of work.

Documentation Thought Experiment: imagine the user manual is named "Handbook of Being Badass With This" then make it so.

– @seriouspony

A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments.

– @KevlinHenney

When we complain about the lack of comments, what do we really mean?

We might mean that we don't understand what the code is there for.

We might mean that we don't understand what the code is doing, or that it took us a long time to do so.

We might mean that we don't understand why the code is written in this particular way, rather than some ostensibly simpler way we have in our heads.

When we complain about the lack of documentation, what do we really mean?

We might mean that we don't understand what a thing is actually for, and when we looked for an answer we couldn't find one.

We might mean that we couldn't understand how to use a thing.

We do not mean that we wish we could spend more time reading about that thing.