Automated patch minimization for bug origin finding

Ok, so you know git bisect? You take a commit history and try to find the commit that introduced a problem.

Imagine you had the problem that git bisect solves but uh you hadn’t been very good about commit discipline and you had a whole bunch of large messy commits, several consecutive ones not in a working state, and it wasn’t really clear what happened where.

Not that I know anyone in that situation of course. This is a purely hypothetical scenario.

Well it turns out there’s a solution to this too, and it’s possibly better than git bisect.

First you write a script to detect the case you want. You can do this with git bisect too, but people rarely bother because you only need O(log(n)) tests. In this case you’ll need a lot more than that so you should do this. Running a test and grepping its output is usually sufficient here. This script exits 0 if the code exhibits the problem or non-zero otherwise.

These usually end up terrible. It’s OK – it’s genuinely a one off and you’re not going to have to maintain it. Here’s the relevant part of mine:

export PYTHONPATH=src 
if python -u -m pytest tests/cover/test_flatmap.py -kmixed_list 2&amp;&gt;1 &gt; test.log  ; then 
  echo "Test passed"
  exit 1
fi
 
grep -q "Extra items in the left set" test.log
grep -q "'0'" test.log

i.e. you run the test, it should fail. Further, it’s output should contain some particular lines. Sometimes you’ll find that your script wasn’t specific enough and you’ll need to add more conditions.

Now you do what you do to start git bisect off: You find a pair of commits, one after the other, where the latter one exhibits the property you want to isolate (e.g. “This particular test fails in this particular way”)

Now, you take the patch between these two commits:

 git diff --no-prefix master andsoitbegins &gt; working.patch

(yes, my branch is called andsoitbegins. I’m not good at branch names. Or possibly I’m excellent at branch names, you decide)

This produces a patch file. We’re now going to perform file based minimization on that patch to try to find the smallest patch that causes the problem.

I still don’t have a good go to minimizer – I tried using delta for this and continued my streak of never getting a good result from doing so, so once again I wrote my own terribly crappy file based minimizer (Update: Now I do. It’s still a bit rough around the edges but works great for me). Here you go:

One of these days I’m going to bite the bullet and just package this all up into a good piece of standalone software. Today might be that day, but it probably isn’t.

What this script does is it repeatedly replaces the contents of a file and reruns a test script to see if that matters. It does this by deleting large chunks of lines then small chunks of lines. If those produced an invalid patch that we can’t apply, it just exits early and doesn’t bother running the test.

Here’s the full test script:

This cleans up the repo, applies the current patch in working.patch and then runs the tests as described above.

In the end our starting 6kloc patch file is turned into the following:

--- src/hypothesis/searchstrategy/strings.py
@@ -204,10 +204,10 @@ class StringStrategy(MappedSearchStrategy):
         )
 
     def __repr__(self):
-        return u'StringStrategy()'
+        return 'StringStrategy()'
 
     def pack(self, ls):
-        return u''.join(ls)
+        return ''.join(ls)

I had accidentally made the text() strategy return raw strings instead of unicode. This caused surprisingly few problems, but did break at least one unrelated test.

The first part of the patch is actually not required to reproduce the problem. What it was needed for is to locate the relevant lines – there are multiple pack() methods in this file, so apparently patch needed help to disambiguate.

In conclusion: This worked really well. It took what would have been quite a complicated piece of detective work and automated it. A++ experience, and I’ll definitely add this to my general box of tools.

2015 in review

I don’t think I’ve done these in previous years, but they seem to be a thing this year and according to todoist I’m due a blog post (overdue by 3 days actually), so here we go.

So… 2015. That was a weird year, huh?

This year I have:

Moved country (again)
Upgraded my internet celebrity status from D-list to C minus-list if you’re in specific niches
Earned precisely £0 (note: This is a slight technicality).

What happened?

Well, if you may recall, in 2014 I moved to Zurich to work for Google. Despite what people thought from the timing of the post, this was not an April fools joke but an actual thing.

It didn’t really work out and I lasted about 6 months. For a variety of reasons, Google was not a good environment for me, and between that and it hampering my ability to work on my own stuff in my spare time, I got a lovely inside view of what happens when the sub-clinical depression I’ve been mostly coping with all my life removes the ‘sub-‘ from its name (OK, I didn’t actually get diagnosed, because I figured out how to self-medicate through a judicious application of quitting my job instead).

So, starting the new year unemployed was pretty great, even if I was still in one of the most expensive cities in the world.

I’d intended to work on a variety of projects, and actually spent the initial part of the year brushing up on combinatorial optimisation and learning about integer programming. But I had this weird little project called Hypothesis that I’d written back in 2013 to learn Python, and for some weird reason people had started using it, so I thought I might fix a few bugs, maybe work on some features, etc.

So, um, yeah.

For me 2015 has basically been the year of Hypothesis. This was very much not intended from the outset. I originally intended to put in a couple months work on it. I even made a concerted decision to give it up. Now I’m building a business around it.

It’s been an interesting experience for a number of reasons. It involves research to solve practical problems, randomized algorithms, combinatorial optimization, API design, coming up with good abstractions, and software quality. All it needs is voting to become my ideal project.

…voting and financial viability that is. Which is why I’m trying to build a business around it.

The business side of things is going OK. I’ve had some work this year (which I have not yet paid myself for from the business’s bank account, which is why £0 earned in 2015), and a bunch more scheduled for the new year. If I can keep up my average income over the next three months for the rest of 2016, I’ve got something pretty sustainable. I don’t yet know if I can, but I’m a lot more hopeful about the possibility than I was 3 or 4 months ago.

This has also got me to go to a lot more conferences and give talks, which has been a rather great thing for me. Turns out getting up in front of a few hundred people and talking entertainingly is a thing I can do. I had no idea. I credit this blog with a lot of that.

Other things than Hypothesis have happened this year too…

Writing

Obviously I’ve written stuff this year. I always write stuff. Notable things I’ve written here on this blog include:

This was also the year I got into writing fan-fiction.

It started with Stargate Physics 101. While this is Stargate fan-fiction, it’s really a comedy about software testing and existential threats. “I send this to software developers to teach them about testing” is an actual thing I have been told about this piece. “My job is a lot like this, but with fewer genderqueer werewolves” is an actual thing I have said about this piece.

I’ve also since been writing The Rules of Wishing. This is fan-fiction for Disney’s Aladdin.

I’ve also started writing docs.drmaciver.com, which is facetiously described as a handover manual for being DRMacIver but is mostly a catalogue of stuff right now.

Living situation

For the first time (not counting holidays) in more than a decade, I’ve been living with my parents since May. It’s been an interesting experience.

The living with my parents part has been fine actually. We get along fairly well, even if I occasionally start arguments about shower lengths and ham sandwiches. The real problem with living with them is that they live in the country, and the country is bullshit.

One result of living in the country is that I’m doing much less walking (if this sounds backwards to you, I assure you it is not. Living in the city naturally integrates a lot of walking into your life. Living in the country mostly surrounds you with roads that are not safe to walk on and would take you an hour to get anywhere), which means that my overall fitness level is way down. I’ve been actively trying to combat that in the last month or so, which seems to be having some effect.

Another consequence of living here is that it really helps me grind my driving skill. I’ve probably driven about an order of magnitude more total hours in the last 6 months than in the rest of my life put together.

This has both been interesting and frustrating. I’m still politically quite against cars, and I don’t really like being so dependent on them. However, it’s taken my driving skill from “I don’t think you should trust me behind the wheel of a car” to being pretty OK.

Beeminding

I went from wildly enthusing about beeminder to just quietly using it. It petered out for a while, but now is picking back up again.

My two main things for beeminding are todoist and exercise. I’ve also got some tagtime goals for work and reading non-fiction.

What next?

My plans for 2016 are mostly “do what I’m doing now except more so”. I’m in the process of getting back in shape. I’d like to do that, but more so. I’m in the process of building a business. I’d like to do that, but more so.

I would definitely like to move back to civilization. I’m giving strong consideration to this being not London, but it will have to be somewhere London accessible.

Another thing that will happen in 2016 that I’m excited about is that 2016 will involve travel to at least two countries I’ve never been to before. I’m going to Namibia in January (and offering a great deal on Hypothesis training until I do!), and later in the year I’ll be going to Mexico for my brother’s wedding.

I tend not to travel much, so both should be interesting experiences.

Other than that, I have some interesting research directions I want to take Hypothesis/Conjecture in, and may be exploring some plans for how to focus on that. Watch this space.

On criticizing programming languages (without criticizing their users)

You may have read Aurynn’s piece on contempt culture and programming languages. It’s been doing the rounds. I recommend reading it, and this piece is not an argument with hers. It’s merely a write up of some adjacent thoughts I’ve had on the matter (some of which I’ve discussed with Aurynn on IRC).

To quote from it:

it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.

Notably there are three (and a half) statements that Aurynn mentions as popular to make:

Other languages sucked
the people using them were losers or stupid
if they would just use a real language, such as the one we used, everything would just be better.

What’s interesting is that these statements absolutely look like one statement in most arguments, but their truth value is different.

Other languages sucked

Yes, this is absolutely true.

Of course, every language is someone else’s other language.

All programming languages fall into one (or both) of two categories: Terrible to use or not yet ready to use. Sure, there are degrees of each, but if you think a language is great, you’re wrong. The best you can hope for is less bad.

PHP and Java, two examples cited in Aurynn’s post, are shitty languages. PHP more than Java (some of the recent Java stuff actually looks quite nice, and I have more sympathy for what Java is trying to do than I used to), but both have a lot of problems.

The people using them were losers or stupid

For me, I think this is the heart of the problem with the narrative that Aurynn is criticizing: Languages don’t care if you make fun of them, or call them bad languages. Languages don’t have feelings. People do.

It’s OK to make fun of Java’s baggage of erased types embedded within the language that it carries over from pre 1.4. It’s better to constructively acknowledge that it’s a problem and talk about other ways that problem could have been solved, but ultimately posting ridiculous programs and saying “lol, Java, you so silly” isn’t really hurting anyone.

But saying “Oh god, why are you using Java? It’s the worst and you should feel bad for that decision” is hurting people. And, in case this is unclear, hurting people is bad.

If they would just use a real language, such as the one we used, everything would just be better

This point is not even wrong. First, it embeds the half statement I mentioned “such as the one we used”, because aside from the fact that all languages are equally “real”, the one you are using is probably terrible too. But even setting that aside: The chance that someone has the option to switch languages is very low.

I am a reasonably senior developer with a reasonably large amount of negotiating clout. I have only once in my career got to choose what programming language I used during my day job (Scala, for a green field project. It didn’t go very well).

The best you can realistically hope for is right of refusal: You can choose not to take a job because of the programming language involved, or to preferentially seek out jobs which involve a particular programming language, but if the jobs aren’t there, or you can’t get them, you’ve no magic ability to just decide to create one where you get to write in your favourite language.

What this means when you’re saying someone should change to a new language, in the overwhelming majority of cases their options are one of:

Quit their job and hope to luck into finding one in a new language that you prefer.
Persuade their company that they should switch to a new language.
Do a vast amount of free labour and pretend that their day job isn’t their real language.

Hopefully when spelled out that way it’s obvious what a ridiculous set of choices this is.

Making the programming language you write in the sole determiner of your job is an awful idea. I’m not saying the programming language doesn’t matter, but when you compare it to working on good projects with good people for good compensation in a good work environment, it should be obvious that if you’re making it your primary consideration you’re making some really bad life choices.

Persuading a company that they should switch to a new language is basically a non-starter, and rightfully so. You can start new projects in a new language, although this itself may not be a great idea, but when you’ve got an existing project and infrastructure written in one language, switching that over to a new language is going to be a lot of work. Even if it that work pays off in the long term (it probably won’t), in the short term it’s an almost impossible sell.

So really what we’re saying when we want people to use new languages is mostly another variation on the theme of “your worth as a developer is measured by the amount of free labour you do”. This continues to be bullshit.

Why are we doing this anyway?

Ultimately, I think a lot of this problem comes down to identity. As software developers, we have too much of our identity bound up in the tools we use. We’re not software developers – we’re Java developers, or Python developers, or Ruby developers. And of course we use a mac/linux/Windows. Who the hell would choose one of those other options? I’ll tell you who: Emacs users.

But seriously. We get very personal about our choices. This makes it hard to criticise the tools people use, because it so easily turns into criticising the people who use them. Equally, it makes it feel like when people who choose things differently than us, they’re criticising our choices and thus criticising us.

We need to move past this. Our jobs are not to develop software. Our jobs are to develop software to solve problems. The software is a mechanism, not an end goal, and every constraint we put on this limits our ability to solve those problems.

It also limits our ability to improve the tools that we consider so important: Part of why I think it’s important to be able to criticise languages is because I want those languages to improve. We’ve come a long way in the last 50 years of language development, but we still have a long way to go. It would be as much a shame to stop here as it would be to release a language that ignored most of those 50 years of development.

But equally, if it’s important to criticize it’s more important to criticize well. If you can’t criticize well, don’t criticize at all. So I’d like to finish with some suggested guidelines for constructive criticism:

Criticize, don’t mock.
Criticize things, not people. Ideally don’t even criticize the people responsible for making those things (I’m not good at this one). Even when people are at fault (and as discussed, they usually aren’t), criticizing them just makes it personal and makes it less likely that a productive conversation is going to happen.
Be specific. Nothing “sucks” generically, but something about it might be bad. Even when something does suck, this isn’t useful criticism but mere venting. If you’re using that thing regularly then venting is fine, but otherwise it’s an extremely unclassy move.
Focus on effects, not aesthetic preferences. “I hate this syntax” is not a useful criticism. “I keep confusing this syntax with this other syntax” is. Although in general people over focus on syntax anyway and “This feature keeps causing this concrete problem” is way better.
Things arise through vast amounts of historical context, and come with a vast amount of inertia. Change is hard, and comes with a lot of problems. Most of the time, criticism will never result in fixing the problem. All it can do is try to establish how you can do better next time.

Mentors as a service

This is an idea I keep coming back to in my head. It’s possible it already exists and I just haven’t seen it, or that it’s a niche that’s sufficiently well served by things like coding bootcamps, etc. (though making them serve this niche is somewhat problematic).

I’m not quite motivated enough to try it myself because it doesn’t really play well to my strengths, but I thought it might be worth putting out there to see what people think.

The starting point:

Getting more junior developers into the industry is a good thing. You’ve got the generic problem that everyone struggles to hire good developers, the diversity of tech problem, and of course it’s great to be able to help people get a good job in a well paying industry.

But we’re also really bad at hiring junior developers. We’re bad at hiring in general, but the proxies we use for hiring break down especially badly for juniors. This makes hiring for the roles either even more of a time sink than hiring normally is or a complete crapshoot.

Then once we have hired junior developers we’re also bad at that. The problem is that junior developers require a lot of support. This takes up a lot of time from your more senior developers. They may also just not be very good at it – teaching is a specialised skill, and even developers who are otherwise good communicators may not be great at it. The result is that a lot of junior developers flounder because they are not properly supported.

This may not be your experience – some companies are much much better at hiring junior developers than others are – but it’s been mine, and I believe it to be sufficiently common that there’s a problem here to be solved.

And I think there’s a business to be made in solving it, and a business of the best sort: One where you can make money off helping everyone involved in the process be better off.

Both of these problems are for the most part generic:

Junior developers are much more interchangeable in terms of their skills than senior developers, because the primary characteristic of a junior developer is ability to learn. You might want some basic sorting by aptitude and preferences – e.g. someone like me with the visual skills of a brick you probably shouldn’t sort into front-end (note: This almost happened to me), but for the most part there’s a fair bit of flexibility here.
Most of the questions a junior developer will have are things like “What’s a list comprehension?” and “git wtf?!”. They’ll definitely have questions specific to your company, but so will intermediate and senior developers. The real difference with juniors is the absence of the basic skills.

Both of these seem like they don’t have to be solved by an individual company.

Imagine the following setup:

Our hypothetical company, JuniorDevCo, is constantly interviewing potential junior developers at a rate that is designed to give them a constant pool of candidates (say somewhere in the 10-50 range depending on hiring rate).

Someone can then come to them and say “We are looking to hire someone for $ROLE”. JuniorDevCo will vet the company, negotiate a salary for the role, and then suggest a couple of candidates (probably just the 5 who it’s been longest since they’ve been interviewed unless there are specific requirements) for the company to meet and pick amongst in the obligatory step to give the company a sense of agency.

So far what I have described is also known as “a recruitment agency”, or at least is close enough to one that it doesn’t seem particularly interesting.

The interesting bit is that when you hire these developers they come with an associated mentor, and access to JuniorDevCo’s internal help system (I am imagining this is something morally equivalent to “A slack channel with a bunch of people employed by JuniorDevCo on there to help + some sort of knowledge base with good documents to send them in response to specific questions). They meet with the mentor regularly to discuss how things are going and to get guidance, and they can message them for help at any time.

In exchange, JuniorDevCo gets a decent monthly fee, and a bonus if after one year the junior dev is still employed at the company (at which point the company can choose to either keep paying for them to have a mentor or not as they prefer).

Would this work?

I don’t know, but I think it could.

Some specific thoughts:

It takes a very real pain point and says “Hey, so, this is costing you a lot of money, everyone hates it, and you’re not getting good results. If you pay us less money than it is costing you then we can make the pain go away and get you better results.”
A process of constant hiring lets you really refine the process and see what works. It also helps a lot in analysis of things like bias – is your process decently gender neutral, does it have a racial bias, etc? These are the sort of things you can do if you’re hiring at a high rate and are lost in the noise if you’re not.
Making the numbers work out in terms of how much you charge might be tricky, but you’re saving a lot of time from senior developers, so it should be viable to get a senior developer rate per mentor, and good tooling and a good knowledge base can help keep their workload manageable.

It seems weird that setups like this don’t already exist, which is probably a sign that I don’t know the right keyword to google for and they actually do already exist. It may also be that there is a fatal flaw in the plan that I’ve not yet seen.

Edit to add: Having said that this doesn’t play well to my strengths, of course parts of it do. In particular I’m thinking that the remote mentoring part is something that I both can do quite well and could easily offer as part of my general business. If this is something you think your company would be interested in, drop me an email.

Effectiveness of personal greenhouse reduction vs donation

Epistemic status of this post: I am not an expert, but I am reading people who are. There is every chance that I have messed up somewhere so if you know about this area I welcome correction, but in the absence of that the numbers seem relatively robust.

General disclaimer: This is UK centric. The general theme and advice is probably quite portable, but the specific numbers will vary quite a lot depending on who and where you are.

Due to a combination of long-running family arguments and the fact that now that I’m earning money again I’m planning to invest a lot of my earnings in charitable giving, I’ve been looking into various ecological statistics and costs and I’ve come to the following conclusion:

Based on typical UK lifestyles, it is very hard for any personal ecological intervention to be more cost effective at reducing carbon emissions than giving money to an effective climate change charity.
The amount of money you need to spend to go carbon negative is surprisingly small.

Here are my calculations. Note: I am deliberately rounding things up on the grounds that these are ballpark figures.

Based on the UK greenhouse gas emissions national statistics from the government, the UK is currently emitting the 568.3 million tonnes per year of CO2 equivalent greenhouse gasses (467.5 million tonnes of CO2, the rest is other greenhouse gasses).

Based on this report from the committee on climate change, this is artificially low due to CO2 imports from countries that do manufacturing for us, and the real CO2 emissions are probably something like 80% higher than that. This comes to 841.5 million tonnes of CO2 equivalent.

The current population of the UK is 64.1 million. So dividing 841.5 by 64.1 (the millions cancel), you get about 13.1 tonnes of CO2 per year per person.

Note: This includes a whole bunch of industrial usage that you have no direct control of. e.g. if everyone in the UK became vegan overnight (which according to this Guardian article can save up to about 1.5 tonnes per year if you’re starting from a meat rich diet), all the cattle and other agricultural animals aren’t going to evaporate, we’re just going to export more. You will reduce demand, and thus production, but you’re probably not able to reduce your “share” of the production to zero. So this is already an overestimate of how much greenhouse emissions we can actually exert a direct influence over.

Now, lets arbitrarily double and round up on the grounds that you might be a high carbon footprint person if you’re eating more meat than average, driving everywhere, etc. We’re trying to create a comfortable overestimate of how much you could reduce your carbon footprint. Your mileage may vary.

So lets say for the sake of the argument that you personally have a carbon footprint of up to 30 metric tonnes of CO2 equivalent.

How much would it cost for you to offset this?

Note: Although I have some doubts about the efficacy of any given choice of carbon offsetting, atmospheric carbon is the ultimate fungible resource. Distribution matters a bit, but ultimately the amount of CO2 in the atmosphere is what matters the most, so I think thinking in terms of offsetting here is completely valid.

Anyway, cost. There seem to be a variety of reports.

This guardian article (note: from 2011) claims that £8 / tonne is “typical”. That would make this a price of £240 / year.
The fixed offset calculator from the world land trust claims that we should be paying them £450 / year to offset 30 tonnes of carbon
This analysis from Giving What We Can claims that Cool Earth are extremely effective to the tune of saving one tonne of carbon per £0.85 donated. That would make a £25.5 / year donation to them effective at offsetting these 30 tonnes!

Obviously this is quite a range. However, even the upper bound of £450 is just not that large (for poorer people and families obviously it’s much more significant, but note that within the UK at least poorer people are also likely to have smaller carbon footprints. I do not know how much of this is mediated by the fact that poorer people are disproportionately likely to be urban). Especially when you consider that this is a significant overestimate of how much you are likely to need to offset.

What this means in practice is:

If the analysis of their effectiveness is at all believable (I have a reasonable amount of non-expert confidence in it, but I have not done a close reading of the report), a recurring donation of £10 / month to Cool Earth is probably enough to make you significantly carbon negative. Even if it is an order of magnitude too optimistic, £20-30 / month should still be enough to make you carbon neutral unless your lifestyle is truly exorbitant for the UK.
If a personal intervention costs you something you value as much as £10 pounds per month it’s probably not worth it and you might want to consider offsetting instead.
Even if you want to reduce your personal ecological footprint, you should strongly consider giving money to a charity such as Cool Earth, because it lets you make your net ecological footprint go negative.

This suggests the following rules of thumb:

If a personal intervention net costs you money, it’s probably not worth it. Give the money to Cool Earth instead.
If an intervention requires a regularly (say as often as once a month) recurring action that each time you perform it you would rather give £1 to Cool Earth, you should consider not bothering and giving a bit more recurring money to Cool Earth instead.
If you have particular habits that have a high carbon cost per instance (e.g. long distance travel), consider offsetting them with a donation each time.

2 requires a little unpacking. It would of course be better to do both. However, my thesis is that you are more likely to stop doing annoying actions than you are to stop recurring donations: One requires active intervention to keep doing, the other requires active intervention to stop. Moreover, we tend to have a “virtue budget” where because we feel good about ourselves for doing one thing we’re likely to do less of another (I have seen Science on this but do not currently have a cite, so take this information well salted). So given the relatively low effectiveness of doing things which will annoy you, the high chance of stopping them, and the comparative effectiveness of less annoying alternatives, it’s probably better to just go with the less annoying alternatives.

Personal interventions that are probably worth it:

Loft insulation if you are living in a house you own and do not currently have it. This will save you money as well as reducing your carbon footprint. Therefore the cost is negative and thus always going to be better.
Replacing light bulbs with LED ones as and when they break: Saves you money, costs you no time and reduces your carbon footprint.
Other cost saving ecological measures for your home are probably worth it too. I’m not super familiar with this area because London living means hardly anyone I know outside of my parents own a home. There’s probably something interesting to say about the ecological costs of renting here.
If you can take public transport instead of driving you probably should, but this is not a practical intervention for many people because whether you take public transport tends to be more a function of where you live than an easily changeable aspect of your llife.
If your diet is high meat then eating more vegetarian meals is probably a good thing anyway and will save you money without costing you time, but bear in mind that you could eat meat every day and chuck £10 to Cool Earth at the end of the year and still save more carbon than by going vegan, so this is probably not a valid reason to go vegetarian.

Addendum and other considerations

There is more to saving the planet than CO2 emissions, but it’s a pretty good start. However, other considerations may affect the validity of some interventions. For example although you save comparatively very little CO2 by going vegan, you do probably save upwards of 1000 litres of water per day, and water is significantly less fungible than CO2 because of the difficulty of transporting it. So decreasing your meat consumption may be a valid intervention after all, or you might want to just chuck another £10 / year at some charity building desalination plants, I don’t know. More research needed.
Even if the estimates of their effectiveness at CO2 offsetting are wildly overstated, Cool Earth’s approach helps poor communities and preserves biodiversity, and thus seem like a worthwhile charity strictly on those grounds. However if they were contributing literally zero carbon offsetting benefit, Giving What We Can’s DALY comparison against the Against Malaria Foundation (who I have currently let my donation to lapse, but will be resuming it once I’ve sorted out my finances) makes Cool Earth the less compelling alternative of the two.
With any charity, there is a point of diminishing returns. Cool Earth do not appear to be at that point yet according to the Giving What We Can analysis (which is a few years old, but showed sufficient headroom that they are probably still going strong). It is very unlikely that we can achieve the needed global carbon reductions purely through direct offsetting. I have no idea if Cool Earth could productively use £640 milion per month (everyone in the UK giving them £10 / month), but I doubt it. However we are currently so far from that point that I think it is not a major concern.
Medium and long-term, we still need systemic change. Short-term, we have the emissions equivalent of a Wonga loan and almost nothing matters except for paying it off. In order to balance these two it is probably worth diversifying your charitable giving and giving some of it to advocacy groups. More research needed one effectiveness here (the linked Giving What We Can piece has some analysis here. It’s a few years old though and the analysis of effective advocacy probably changes faster than effective climate change interventions).