In February 2015 I published a post called How I learned how to work.
It promised three things, then supplied four: efficiency, predictability, recovery and research. I noticed the extra item at the time and carried on. At least that part of the article was accurate.
The advice was quite specific. Use task-management software. Stop using email for everything. Time repetitive tasks. Write down how you solve problems. My target for the year was to automate anything I did for the third time.
It is useful to have the original wording. Otherwise it would be easy to remember a much tidier set of ideas.
Repetition was a clue
The automation target put a number on repeated work: doing the same task again when a script might handle it.
The useful question in that advice is what makes the task repeatable. Can you describe the input, the operation and a correct result? Are you repeating the same job, or do three superficially similar requests need different judgments?
For a fixed operation, a small script can make sense. For a task whose meaning is still changing, writing the instructions down may expose the uncertainty before automating it does.
That is how I would qualify the old target now. Counting to three is simple. Deciding whether the three things are actually the same takes more attention.
An estimate could be compared with something
The post suggested recording how long repetitive work took. Its example was a report table, from the database through to the interface.
There is something useful in the scale of that example. It names a piece of work small enough to finish and compare with a previous attempt. It also leaves room to ask what changed when the next one takes longer.
The record only helps if the comparison makes sense. A familiar table and a table with an unfamiliar data source are not automatically the same task because their screenshots look similar.
I would keep that question beside the estimate: what work are we assuming is the same?
Some knowledge needed to leave my head
Under recovery, the old post recommended keeping procedures in mind and writing down solutions for next time. Those two ideas pull in different directions as more people depend on the work.
I have since written about that change in the Delivery Hero account. A small team could carry a surprising amount of context informally. At a larger scale, the work had to depend less on the same few people remembering or deciding everything.
The old advice to record a solution still makes sense. The audience for the record has become more important. Can someone else find it? Does it explain when the solution applies? Is there enough context to recognise when it would be the wrong thing to do?
That is a more useful revision than replacing the old list of tools with a new list of tools.
Leave the old post where it is
The 2015 article also describes a fifty-minute work block followed by a ten-minute break. That tells you what I wrote about my routine then. It is not evidence that this is how I arrange a day now.
The same applies to its enthusiasm for particular products. They belong to the period in which the piece was written.
I would leave that article intact and put this response beside it. The original gives us the claim. A later piece can examine it without quietly improving the earlier version of me.