Burn After Reading - Issue #3

A late edition, courtesy of me having spent the last several days in bed with a virus!

You read the first 20 pages of a book and find no typos. Absence of evidence isn’t evidence of absence - you probably wouldn’t expect the probability of a typo in the entire book to be zero, but what might it be? John D. Cook explains the rule of three, a “quick and dirty way to estimate these kinds of probabilities”.

I’m a big believer in enabling access to data - earlier this year I was working on Somno, building an API to get data out of a patient monitor - so it was fascinating to read about what sleep apnea patients have been doing to take their treatment into their own hands. In a similar vein, there’s lots of interesting work around diabetes too, with HAPP, Nightscout, OpenAPS, and more.

An area that’s much more disappointing - Kaitlyn Tiffany writes about how “Period-tracking apps are not for women”, or rather, generally terrible-seeming, “designed for marketers, for men, for hypothetical unborn children, and perhaps weirdest of all, a kind of voluntary surveillance stance”. It’s a little cis-normative, but it’s a great illustration of a slew of common use cases and design considerations that just seem to be ubiquitously ignored.

I spent several years as part of an internationally distributed team, where the classic “What the British say vs what the British mean” chart got wheeled out on a periodic basis (usually my fault). Frankly there’s a lot of truth in that chart (even if it meant I could no longer describe something to my colleagues as “interesting” and have them take me at my word). However, then I learned about the German Arbeitzeugnis (reference letter) and the horrific/wonderful (depending on how you look at it) euphemisms and codes and nuances they contain - they make British English look clear and straightforward!

On the subject of distributed teams, Andreas Klinger’s article “Managing Remote Teams - A Crash Course” is a great piece that addresses a bunch of different kinds of team, potential benefits, potential issues, things to think about, and more - it very much lines up with my own thoughts and experiences. One point particularly stood out: in many cases, even the most co-located of teams often does _some_ remote work, whether it’s a salesperson onsite with a client, or someone going through their emails on their commute - it’s just a question of how much, how often, and how well supported it is.

In “interesting/terrifying legal cases”, a global manufacturing giant (Mondelēz) got hit by a malware attack, made a claim with its insurers (Zurich), and had it denied on the basis of an exclusion in the policy for “hostile or warlike action” by a “government or sovereign power”. Unsurprisingly, Mondelēz sued, and now there’s a multi-million dollar case that seems to hinge on the question “was this malware a state-sponsored attack”…

Finally, alas, British politics, but Tom Chivers offers a helpful explanation of some of the technical aspects…

An early electronics project at school had us building crude line-following robots with two basic on/off light-sensor/motor circuits. That works pretty well up to a point, but Andy Sloane goes into fascinating detail about the considerations and the maths of the more nuanced feedback systems that come into play if you want to actually do this at speed.

You’re working on some code, and you want to e.g. run tests or rebuild things as dependent files change. You might think to use a file’s mtime to determine this - after all, it’s what GNU Make does. However, apenwarr details the myriad problems with this approach, and how their redo tool does things better.

I liked this post by Max Woolf on “Things About Real-World Data Science Not Discussed In MOOCs and Thought Pieces” - pointing out that while there’s a lot of talk about models and tooling, that’s only part of the work. This seems a pretty common principle - law is only part of the work of a lawyer, medicine is only part of the work of a doctor etc. - but it’s still nice to see it explicitly called out occasionally, and as someone who is very much Not A Data Scientist, it’s useful to have a more balanced insight.

There’s been a lot of talk about open source, licensing and funding recently, and Bryan Cantrill’s “Open source confronts its midlife crisis” is a great look into some of the situations and problems that exist. If nothing else, the reminder that “licenses that are vague with respect to permitted use are corporate toxin” is an important one!

Finally, this Twitter thread of hacks that shipped in real games is wonderful. “Invisible washing machines”…!

Thanks for reading to the end - if you have any feedback, please, get in touch!

Cheers, Kristian