Like many, coronavirus-related things have been taking over my life; in the first few days of working fully remotely, I struggled to find an appropriate work-life balance. This resulted in me reading less than usual, which is reflected in this post.
Author: Vicki Boykis (writing within Normcore Tech)
Written by another data scientist, this post takes down the idea of numbers as a “source of truth,” instead suggesting that no numbers are the complete truth, and rather that they’re plagued with all of the messy context of the real world. Boykis cites several examples:
- the coronavirus mortality rate: we have no idea what the true mortality rate is, because everyone has their own method for correcting for undercounting.
- Spotify saying they have 75 million active users, but how do you define “active”? (This problem plagues almost every business.)
- GDP, often taken as an objective metric, does not include things like women’s domestic labor
- Research papers, which too often are the source for eye-catching, headline-worthy statistics, can have (and have had) calculation errors or bugs in code
This has helped me to conceptualize an idea I’ve had for a while: call it “data nihilism,” that numbers and data only have meaning to the extent that their context gives them meaning, and that devoid of that context they are worthless.
What I mean is that all the data that we trust and believe on a daily basis, is only accurate in a specific context, at a specific time, and at a specific level. If you dig deep enough, ultimately all of the data in the world that drives major and minor decisions alike is built on wobbly foundations.
Measurement ostensibly exists to try to get us closer to this “truth,” but in reality this truth cannot exist in as an objective of a way as we would like. I’ve been thinking a lot about this all week, especially given all the uninformed or context-devoid numbers flying around about coronavirus, and it’s given me a lot of ideas for future posts.
Thinking psycopg3 is by a pscyopg2 maintainer about their vision for the next major iteration of the library. Some of the changes include separating query statements and parameters, modifying the behavior of context managers and how they impact transactions, creating an optional C module, and integrating async code into the library.
They started a karaoke club in their house because the internet wanted it is an NYT article about Lion’s Roar Karaoke House. In late 2012, a couple got a call from a group of strangers who wanted to sing karaoke … at their house. The couple had previously run Lion’s Roar Entertainment, but closed it in 2008; somehow, though, the defunct business started appearing at the top of Google Search results. “Maybe someone is trying to tell us something,” one of them said, and so after three years of avoiding calls they went all-in and transformed their house into a karaoke house.
I found this from the MIT Technology Review newsletter Weekend Reads; the “tech connection” was a quote “it was like the Google algorithm was suddenly in our favor.” In hindsight, that line was more of a hook into an interesting and feel-good, but by no means tech-related, story, rather than anything that has to do with algorithms.
What kind of public space is Twitter? Is it a park where cranks shout through megaphones? Is it a public meeting where people voice concerns about decisions? Is it a newsstand where tabloids and newspapers put rumors next to facts?
They don’t answer it, but it’s prompted a lot of thought for me. A lot of people say that Twitter is not real life, and until recently I tended to agree. Others disagree, saying that the enthusiasm around presidential candidates like Bernie Sanders and Andrew Yang is very real, even though it didn’t result in a nomination (it didn’t have to for it to be “real”). The answer is somewhere in the middle, of course, but that middle interests me a lot.
The future of software is a sociotechnical problem is an article by Charity Majors, founder and CEO of Honeycomb. This is mostly a pitch for observability (and I’m still not super sure what that is), but Majors writes that we are “in the Middle Ages of software delivery”—citing a Stripe report that engineers spend 40% of their time on “miscellaneous technical bullshit”—then states that only a combination of technical fixes and social change will get us out of this hole.
A lot of the ingredients are things we’ve heard before: blameless retrospectives, good test coverage, interview processes that value people’s strengths, promoting people as team multipliers, training and education, code reviews and mentoring, shared values and organizational transparency, and much, much more. These are all sociotechnical ideas; code reviews are as much about the code as they are about the way in which you communicate; test coverage is worthless if the test suite is overridden on failure. Observability is one piece of the puzzle, and Majors suggests that “observability-driven development” can help to bring about technical change.