How to not be late

Being late bugs me.

I don’t mind so much when other people are late (within reason) but I really hate being late myself, and I hate it when other people make me late.

In observing how this comes about recently, I’ve come to realise that a lot of why people are late is because they just don’t know how to be on time.

Fortunately, this is easily remedied. Being on time is in fact very simple. It may not be easy, but it’s simple.

If you wish to be on time, you need to aim to arrive early.

Why? Because if you’re arranging to arrive on time, then if anything goes wrong you will be late. And given the tendency to optimism in planning, things will go wrong more often than not.

This is particularly true if you have scheduled connections to make. If your trains run every half an hour, then being five minutes late for your train will make you half an hour late for the next stage of the journey. These things compound.

What this means is that if you want to not be late on a multi-stage journey you need to plan for redundancy. Tight connections mean you will be late.

The other way to not be late is of course simply to not aim to arrive anywhere in particular at any particular time. When you’re in control of your own schedule, this is entirely viable, but it’s much harder when coordinating with other people.

Making taxes progressive through redistribution

There are a whole bunch of cases where as a society we decide we want to reduce consumption of something, but it’s difficult to do so through individual choices. This might because of the non-obvious bad effects of something (sugar, alcohol, smoking) or because of negative externalities (atmospheric carbon leading to climate change, water use leading to aquifer depletion, overfishing).

In general I am a big fan of doing this through taxation: Want people to use less of a resource? Make it more expensive. It’s got a pretty good track record of working, even in the face of convincing arguments that it shouldn’t work in this case.

But there’s a pretty bad problem with this approach: It’s deeply regressive. If you raise the price of a luxury then poor people are much more likely to have their life negatively affected by taking that luxury away from them because it represents a much more significant percentage of their budget. Rich people will either slightly adjust their usage down or simply not notice because it’s such a small percentage of their budget.

This sucks for a variety of reasons. As well as generally disliking things that increase inequality, the poor are rarely the biggest consumers (this is particularly important in the case where we’re doing this because of externalities)!

I’ve been prepared to bite that philosophical bullet for sufficiently important things (carbon tax) but not ones that are just speculative health interventions (e.g. sugar) and been on the fence for major public health interventions (e.g. alcohol).

But it turns out there’s a really simple solution to this which significantly reduces the number of bullets in my diet. It’s not original to me, but I’ve clearly not been paying to the right circles because neither I nor the couple of friends I’ve asked have heard of it before. I only heard of it because I independently thought of it and then did the research for prior art rather than assuming nobody else had.

The solution is this: You impose the tax, you collect all the revenue from it, and then you distribute all or some of that revenue equally amongst every resident of your country (or whatever area you’re taxing over).

The result suddenly becomes massively progressive, because anyone who is using a less than average amount of the resource is actually in net profit. Note that because of the power law nature of wealth, a significant majority of the population have a less than average amount of income.

This has been talked about in the context of carbon tax, with e.g. the citizens’ climate lobby lobbying in favour of it in the US, but I think it’s a more general solution which could be applied to a number of problems. This is particularly true because there’s a one-time infrastructure setup cost (how do we send money to every resident of the country every month/year/whatever?) after which adding other redistributive taxes into the system becomes easier.

This infrastructure is actually a big feature of the scheme for me. As well as the intrinsic benefits of it, it becomes a nice transitional step to a universal basic income because they require the same infrastructure. It would be easy to e.g. add a small additional income tax that went straight into the redistribution pot.

All in all, I think this is a great idea. I’m going to be thinking about it a lot more, and I’d like to see more discussion of it.

It might be worth learning an ML-family language

It’s long been a popular opinion that learning Haskell or another ML-family language will make you a better programmer. I think this is probably true, but I think it’s an overly specific claim because learning almost anything will make you a better programmer, and I’ve not been convinced that Haskell is a much better choice than many other things in terms of reshaping your thinking. I’ve never thought that you shouldn’t learn Haskell of course, I’ve just not been convinced that learning Haskell purely for the sake of learning Haskell was the best use of time.

But… I’ve been noticing something recently when teaching Python programmers to use Hypothesis that has made me reconsider somewhat. Not so much a fundamental reshaping of the way you think as a highly useful microskill that people seem to struggle to learn in dynamically typed languages.

That skill is this: Keeping track of what the type of the value in a variable is.

That may not seem like an important skill in a dynamic language, but it really is: Although functions will tend to be more lenient about what type of value they accept (is it a list or a tuple? Who cares!), they will tend to go wrong in interesting and confusing ways when you get it too wrong, and you then waste valuable debugging time trying to figure out what you did wrong. A good development workflow will typically let you find the problem, but it will still take significantly longer than just not making the mistake in the first place.

In particular this seems to come up when the types are related but distinct. Hypothesis has a notion of a “strategy”, which is essentially a data generator, and people routinely seem to get confused as to whether something is a value of a type, a strategy for producing values of that type, or a function that returns a strategy for producing the type.

It might be that I’ve just created a really confusing API, but I don’t think that’s it – people generally seem to really like the API and this is by far the second most common basic usage error people make with it (the first most common is confusing the functions one_of and sampled_from, which do similar but distinct things. I’m still trying to figure out better names for them).

It took me a while to notice this because I just don’t think of it as a difficult thing to keep track of, but it’s definitely a common pattern. It also appears to be almost entirely absent from people who have used Haskell (and presumably other ML-family languages – any statically typed language with type-inference and a bias towards functional programming really) but I don’t know of anyone who has tried to use Hypothesis knowing an ML-family language without also knowing Haskell).

I think the reason for this is that in an ML family language, where the types are static but inferred, you are constantly playing a learning game with the compiler as your teacher (literally a typing tutor): Whenever you get this wrong, the compiler tells you immediately that you’ve done so and localises it to the place where you’ve made the mistake. The error messages aren’t always that easy to understand, but it’s a lot easier to figure out where you’ve made the mistake than when the error message is instead “AttributeError: ‘int’ object has no attribute ‘kittens'” in some function unrelated to where you made the actual error. In the dynamically typed context, there’s a larger separation between the observed problem and the solution, which makes it harder to learn from the experience.

This is probably a game worth playing. If people are making this error when using Hypothesis, they I’d expect them to be making it in many other places too. I don’t expect many of these errors are making it through to production (especially if your code is well tested), but they’re certainly wasting time while developing.

In terms of which ML-family language to choose for this, I’m not sure. I haven’t actually used it myself yet (I don’t really have anything I want to write in the space that it targets), but I suspect Elm is probably the best choice. They’ve done some really good work on making type errors clear and easy to understand, which is likely exactly what you need for this sort of learning exercise.

Seeking recommendations for better sleep data

OK. Lets start with the problem.

The ultimate problem is that I often/usually wake up feeling like shit. I am in the process of attempting to determine whether this is caffeine related by removing caffeine from my life, but I would describe myself as something like 80% confident that it is not. I don’t believe I have sleep apnea, but checking that is also something I will be trying to do at some point.

I have been using a Jawbone UP for sleep tracking. I am considering replacing it with a Ouija board in order to get more useful and relevant information. It appears to be categorically unable to detect whether I am actually asleep, let alone what sort of sleep I am currently experiencing (though I have been getting some benefit out of the sleep tracking functionality).

However, it has highlighted one interesting thing: I noticed this morning that my heart rate spiked to > 100bpm twice last night. My “normal” heart rate is somwhere in the region of 55bpm, so that’s quite a spike.

And I think I’ve seen that before, just based on the shape of the graph, though it’s not consciously registered.

So why don’t I look at the data?

Well, I’d love to! Except Jawbone throw away all the detailed heart rate data that’s more than 24 hours old, and don’t let you access the detailed data even from the last 24 hours. I’d be fine with scripting a data export and just dumping it somewhere, but it’s completely impossible in a classic internet of things “You thought that just because you own the device you can actually make use of its functionality? Sucker” backstab.

So that’s the proximate problem: I would like to answer the question “Does my heart rate routinely spike during the night and is that indicative of something?”

The obvious way of answering this is using some sort of continuous recording of heart rate data which has the controversial and exciting feature of my actually being able to access the data.

I only really need this while I am asleep, but it would be nice to have it while I’m out and about too.

So, here is approximately what I am looking for:

A wearable heart rate monitor with accurate data. I am perfectly happy for this to be a chest strap based one rather than a watch.
Which I can get a complete data export from. Ideally I would be able to do this for historic data without needing a nearby bluetooth capable device to send the data to live.
That isn’t ruinously expensive (definitely not > £100. Ideally more in the £50 region).

I currently have three contenders:

A fitbit. They provide full historical heart rate data and an API you can get it from. I am mostly not just going straight for this one because I’ve heard fairly bad things about the accuracy of the fitbit’s heart rate monitoring.
A Zephyr. People seem to mostly be recomming the ruinously expensive Bioharness, but they also have the merely slightly pricey HxM. I do not believe I can get historic data out of them only live. These are mostly recommended because they are accurate and have a good bluetooth API.
Get a cheap chest strap monitor that speaks the standard heart rate service bluetooth specification (there are some really cheap ones), and try out the various android apps that speak it, then later if that works well, write a small Python script to just dump it to a database and run it on a raspberry pi or something next to my bed.

I’m currently most tempted to try the third option first despite it being the “worst” in many regards (requiring the most manual effort on my part). Heart rate service is pretty standard, as far as I can tell, so I can experiment with a heart rate monitor that costs ~£15 and upgrade if the data looks promising (e.g. the Polar heart rate monitors are supposedly quite good and speak heart rate service).

I am however not very satisfied by any of these options, and am open to general advice, recommendations, etc on any of the above, on any point from the proximate to the ultimate problem. So please share. Comments are open on this post, and you’re also welcome to tweet or email me.

First Past The Post is not the problem, districts are

It will come as no surprise to anyone that I am thoroughly against the systems used for electing representatives in both the UK and the US.

What may come as a surprise is that I’m pretty much indifferent to the fact that they both use first past the post, or simple plurality voting.

Don’t get me wrong. First past the post (FPTP from now on) is a rubbish voting system. It has essentially no redeeming values that are not also shared by approval voting, which is in all ways a superior system to it (I’m not massively in favour of approval voting, but it’s unambiguously better than FPTP). The point is not that FPTP is good, it’s that in this context it is irrelevant.

The reason it is irrelevant is that almost any choice of voting system in its place would produce just as bad or worse results, because the most major failure is in how we are applying voting, not the voting we’re doing.

To see this, consider the following scenario:

We’ve got some geographical districts and each one gets exactly one representative.
The representatives are divided into two parties. Call them the Purple and Green parties.
The purple party has 50.1% of the populace who think that Purple is amazing and Green is literally the worst. The other 49.9% think the opposite.
This division is uniformly spread over the entire country with little to no local variation

What happens? Well, you get an entirely purple house of representatives! Because in each district you have a strict majority of people who prefer Purple. Green gets exactly zero representatives despite the fact that 49.9% of the populace are strongly in favour of Green.

This is manifestly ridiculous, and the resulting government cannot be said to have any significant democratic mandate over an equally ridiculous 100% Green party. I’ll leave it up to you to decide how many more seats they should have than Green, but I’ll take it as read that getting all the seats is not an acceptable answer.

And getting this scenario required almost nothing about first past the post. If you replaced it with approval voting, alternative vote, range voting, whatever, the result would still be the same, because it boiled down to a simple majority vote and the majority in each district genuinely preferred Purple.

The choice of voting system influences what sort of distortions you can get. As your voting systems get better the above tends to be the only sort of distortion you get, but it will always remain possible. With districts, you can always take whatever single result you’d get if you ran the vote over the whole populace and just give them 100% of the seats by just spreading the population out this way (note: There are some technical conditions required for this to be strictly true, but it is in practice true with basically everything).

In practice the distortions are usually not this extreme because most of the time the distribution is not uniform. But that doesn’t make the result more representative of the populace, it just makes it a consequence of the vagaries of where people happen to live. You then get Gerrymandering happening, which is essentially the art of deliberately creating these distortions in a way that furthers your political aims.

The only way to avoid this problem altogether and also have districts is to have a system where some districts can genuinely have a majority preference for a candidate but that candidate still doesn’t get elected. This isn’t as unreasonable as it sounds. Two examples of reasonable ways to do this are random ballot and biproportional apportionment. However both of these are niche and you’re unlikely to get them.

Amongst systems with mainstream support, you really need to do away with districting in part or in whole. You need to move to a full proportional representation system across the whole country, or across larger multi-member districts.

But one thing you can’t do is just tinker with the system that you use in each district if you want to make a difference. Changing the voting system you use within districts is just rearranging deck chairs on the titanic, and continuing to focus on first past the post as a problem is just going to get you another vote on the optimal deck chair rearrangement at best rather than getting people off the sinking ship.