Every year, I like to pick one thing I’d particularly like to improve, in order to guide my goals and actions. My focus this year is on increasing the quantity of my output, which includes things like machine learning/programming work, math learned, writing published, talks given, and advice sessions. Broadly speaking, I plan to devise and test ways of doing things differently in order to achieve similar results in less time. I’ll focus mostly on finding principles and methods that work across multiple domains, although they’ll likely be somewhat specific to me.
Why quantity instead of quality?
People often worry about a quality/quantity tradeoff, but I don’t think that’s actually that common. For the most part, I expect changes that improve the speed of my work to improve the quality as well, due to having more iterations and faster feedback cycles. Plus, thinking about quantity is much more likely to lead to insights I haven’t had yet, while in many ways I’ve hit diminishing returns thinking directly about quality.
What results do I expect?
It depends on the domain, but there are probably several cases where I can double or triple my output over the next year. I’ve tried this in a few specific cases and seen significant results, and there’s probably a lot more low-hanging fruit. In addition, many of these types of improvements compound, so it only takes a small number of successes for a significant, permanent improvement.
Approaches I don’t expect to work
Deadlines and other methods of “forcing” output are other common recommendations, but I’ve mostly had negative results with things like this. While I can work something like 10%-20% faster by being stressed and “trying hard”, I’m usually a lot less creative in this mode, and over the course of a week I produce more if I’m calm.
Practice might provide some benefits, but it’s unlikely to hit the scale of improvements I’m looking for.
Outsourcing and delegation currently seems unlikely to work, largely because I’ve already picked a bunch of low-hanging fruit there, and most of the things I want to do more of are very specific to me.
Approaches I plan to try
At a high level, I’m mostly focusing on systematic changes to my workflow, or improving the processes I use to generate specific results. For example, Rachel Aaron has written about how she dramatically increased her writing output by paying close attention to her process and figuring out several ways to improve it.
Here are some things I plan to try:
This consists of defining what the output should look like in fairly specific detail before starting in implementation. I do this to some extent already, but I plan to go a lot farther, particularly by designing several sub-components and milestones before I start implementing.
In data science, this involves starting by designing what my data flow, objects, and pipelines should do in great detail before building the processes to implement them. Currently I tend to stop after just designing the data structures that serve as an interface to the outside world, e.g. other applications or machine learning algorithms, and then I start working on implementing them. Instead, I plan to go one step further and design the intermediary tables or objects required in the process of creating the main object.
Defining clear end conditions for a piece of work
When I started college, I had no specific plan for studying for tests. I would just study whenever I had free time, until it was time for the exam. This was very inefficient–it would often lead to far too much studying for one exam and not nearly enough for another. To get past this, I started studying in a way that consistently checked what I understood and what I didn’t, and then I would stop once I understood everything on the exam.
Similarly, creative work like writing or preparing talks is often subject to Parkinson’s law–it’s easy to just keep working until there’s a deadline. To avoid this, it’s critical to have a definition of what counts as done. It doesn’t necessarily have to be a perfect definition, but it should be something pretty objective, such as “I’ve revised the essay twice” or “I’ve gotten feedback from three people.” In software, this could involve writing tests at the beginning, having all tests pass, and having someone review your code.
If you spend an hour beautifully perfecting the wording of an essay only to throw out the whole paragraph afterwards, then all the time you spent polishing was wasted. It would have been much better to nail down the layout, then focus on getting it to the point where you’d be willing to show it to others. The broader lesson here is to figure out the piece of a project that has the highest uncertainty, and start iterating there, and do this sequentially until the project is done.
Updating on Difficulty
A mistake I frequently make: I consider several approaches, pick the one that seems best, and start working on it. Over the days, more and more information is revealed that makes it clear the approach will take substantially longer than expected–no one finding is damning, but altogether they mean a different path would definitely be better. At this point, I should re-evaluate and switch to an alternate approach…but I usually don’t. I have a few different ideas for how to fix this, including talking to people about my work regularly and doing weekly reviews.
Often I find that I’m not doing the optimal thing because it doesn’t seem like fun. For example, I enjoy writing code, and I don’t particularly enjoy writing tests, so I’ll tend to write tests much later than I should.
When this happens, I find it’s helpful to remind myself why I want to complete the project. I’m usually not just working on projects for fun–they relate to my external goals such as learning new things, earning money, or improving the world around me.