Productivity changes

Resolutions

Last year, I decided to try having month-by-month goals instead of trying to do new years resolutions.

Nov was NaNoWriMo which was what gave me the idea. That was a big commitment, which I think averaged out to about 2h per day, with some "thinking time" on top. Dec was to recover. Feb will be "start new job".

Jan was "learn some rust, if possible contribute to rust compiler". That was a bit speculative, I wasn't sure how big a goal was reasonable. But it turned out fairly well. I think I got a reasonable handle on the basic syntax, and the borrow checker concepts which most people find a hurdle to getting to know it. I build a couple of "hello world" programs to be sure I understood the building and packaging system.

And I built the compiler from source, and submitted a pull request to fix one of the "easy" documentation issues from the issue tracker, and learned how the project was organised. Which is now accepted!

So I think on balance that was about the right amount and specificity of goal. And I count it as mostly a success.

I reckoned the time spent stacked up something like 1 week of work, minus overhead faff, was about the equivalent of an intense weekend hackathon, or a not-very-intense project over a month. Nanowrimo was about twice that (more on some days likely). And some projects lend themselves to a brief burst of activity and others to a longer steady progress.

I'm simultaneously pleased that I *can* expect to focus energy on some projects and actually get somewhere with them. But also depressed that there's only so many months and each lets me achieve comparatively little.

I have lots of ideas of what I might do, but not sure what is most worthwhile to spend that effort on. Some coding projects. Some self-improvement projects. Some social things.

Daily todos

I shifted my daily todos a bit incorporating some ideas from bullet journals (as linked by ghoti).

I started keeping my daily todo-list IN my diary, and when I've done an item, changing the "-" bullet point to an "x" and moving it down to the bottom of the list. So what I'm GOING to do naturally becomes a diary.

I also started, instead of having subheadings, having a few different types. "=" bullet point for largish task. "-" for anything small but needs to be today. "s" for social-type task. (todo and social get postponed in different circumstances and consume energy in different ways.)

It feels easier to plan what I WANT to do, without feeling like I've failed if I don't do all of it.

I also started keeping my actual diary in multiple bullet points with a different bullet, instead of strung together. I'll see how that goes.

I feel like I'm slowly re-evolving a system lots of people already recommended to me. But I couldn't just *do* it, it depends on having confidence that putting things in a list actually works, and I've only slowly acquired that.

Likewise, maybe I don't need to record so much. But doing so was a step in the process of not worrying about it so much. And what's useful I keep, and what I don't need I've got better at just deleting, and not thinking "but I might need that one day".

Similarly, I keep a parallel diary I call my therapy diary for rants where I know they won't seem as persuasive in future but I have to make them. "WHY WHY WHY can't I just do X without screwing it up" "why does y keep going wrong". "this happened and now I feel really bad about it". The idea was, I'd think through the things later and come to terms with them. But actually just writing them down helped a lot. Now I've ranted in it much less often that I did to start with.

Rust: contributing and branchin

I was pleasantly surprised how easy it was to contribute to rust. It seems like there's a combination of things.

I don't exactly know who the driving forces are in the project. But I think several people are employed by Mozilla to work on rust development, which means there is some full-time work, not only scrabbled moments.

There seems to be a genuine commitment to providing an easy on-ramp. Everything in github seems fairly up-to-date, which makes it a lot easier to get an idea of what's what. Bugs/issues are sorted into many categories, including ones that are easy, suitable for newcomers, which is very welcoming.

There is a bot which takes pull requests and assigns them to a reviewer, so most don't just languish with no-one accepting or rejecting them. The reviewer is chosen randomly from a pool appropriate to the component, and reassigns it if someone else would be better.

Even just spending a couple of days pushing the equivalent of a "hello world" patch through (what is the term for "the effort to make a one-line change with no significant code change"?), it felt like I was part of a project, with ongoing activity about my contribution, not someone screaming well-meaning suggestions into a void.

This isn't rust-specific, but it was the first time I used github for much more than browsing, and it was interesting to see how all the bits, code history, pull requests, etc interacted in practice.

Rust itself had an interesting model. A reviewer posts an approval on the pull request. *Then* a bot runs tests on all approved requests in descending order of priority, and merges them if they pass.

That means, the default assumption is that if a commit to master fails a test for some platform, nothing needs to be rolled back -- further pull requests continued to be tested and merged (assuming they don't gain any conflicts). And "master" is always guaranteed to pass tests.

Currently patches are either tested individually, or ones with inconsequential risks (documentation changes and the like) are tested in a batch. It seems to work well. It relies on the idea that most patches are independent, that they can be merged in any order, which usually seems to be true.

If you took the idea further, you can imagine ways of making it less of a bottleneck. Rather than just testing all patches which happen to be submitted at the same time, you can easily imagine a tier system. Maybe priority. Or maybe, have minor tests (eg. just that everything compiles and some basic quick tests of functionality which is known to have changed) to gate things through a first stage, and find problems quickly, and then a second stage which catches obscure errors but is ok to test multiple patches at once, because it doesn't usually fail.

In fact, I can't imagine working *without* such a system. At work we have a nightly build, but it would have been easy to add a tag for "most recent working version", and that never quite occurred to me, even as I suggested other process improvements.