Chosen links

Links - 30th October 2022

Reminiscing: the retreat to comforting work.

In Work on what matters, I wrote about Hunter Walk’s idea of snacking: doing work that is easy to complete but low impact. The best story of my own snacking behaviors comes from my time at Stripe. I was focused on revamping the engineering organization’s approach to operating reliable software, and decided that it might also make sense to start an internal book club. It was, dear reader, not the right time to start a book club. Once you start looking for this behavior, it is everywhere, including on your weekly calendar. Snacking isn’t necessarily bad, a certain amount gives you energy to redeploy against more impactful tasks, but you do have to be careful to avoid overindulging.

Beyond snacking, which can be valuable when it helps you manage your energy levels, there is a similar pattern that happens when a business or individual goes through a difficult moment: under pressure, most people retreat to their area of highest perceived historical impact, even if it isn’t very relevant to today’s problems. Let’s call this reminiscing. When you see your very capable CEO start to micromanage words in a launch email, or your talented CTO start to give style feedback in code reviews, take it for what it’s worth: they’re reminiscing. If you spend the time to dig deeper, they’re almost certainly panicking about something entirely unrelated.

Teaching tech together

Expertise is more than just knowing more facts: competent practitioners can memorize a lot of trivia without noticeably improving their performance. Instead, imagine for a moment that we store knowledge as a network or graph in which facts are nodes and relationships are arcs[1]. The key difference between experts and competent practitioners is that experts' mental models are much more densely connected, i.e. they are more likely to know a connection between any two facts.

The graph metaphor explains why helping learners make connections is as important as introducing them to facts: without those connections, people can’t recall and use what they know. It also explains many observed aspects of expert behavior:

  • Experts can often jump directly from a problem to a solution because there actually is a direct link between the two in their mind. Where a competent practitioner would have to reason A → B → C → D → E, an expert can go from A to E in a single step. We call this intuition[2]: instead of reasoning their way to a solution, the expert recognizes a solution in the same way that they would recognize a familiar face.

  • Densely-connected graphs are also the basis for experts' fluid representations[3], i.e. their ability to switch back and forth between different views of a problem Petr2016[4]. For example, when trying to solve a problem in mathematics, an expert might switch between tackling it geometrically and representing it as a set of equations.

  • This metaphor also explains why experts are better at diagnosis than competent practitioners: more linkages between facts makes it easier to reason backward from symptoms to causes. (This in turn is why asking programmers to debug during job interviews gives a more accurate impression of their ability than asking them to program.)

  • Finally, experts are often so familiar with their subject that they can no longer imagine what it’s like to not see the world that way. This means they are often less able to teach the subject than people with less expertise who still remember learning it themselves.

The last of these points is called expert blind spot. As originally defined in Nath2003[5], it is the tendency of experts to organize explanation according to the subject’s deep principles rather than being guided by what their learners already know. It can be overcome with training, but it is part of reason there is no correlation between how good someone is at doing research in an area and how good they are at teaching it Mars2002[6].

Betsy Leondar-Wright coined the phrase “inessential weirdness” to describe things groups do that aren’t really necessary, but which alienate people who aren’t yet members of that group. Sumana Harihareswara later used this notion as the basis for a talk on inessential weirdnesses in open source software, which includes things like using command-line tools with cryptic names. Take a few minutes to read these articles, then make a list of inessential weirdnesses you think your learners might encounter when you first teach them. How many of these can you avoid?

Why “dark mode” causes more accessibility issues than it solves

There is research that shows that generally, for generic internet users, the best colour contrasts are:

  1. Black on white

  2. Black on grey

  3. Blue on white

  4. White on black

  5. Black on yellow

But that’s people with “normal” vision, not when you are designing for astigmatism.

And we know some people are designing for this audience — for example the way that at academic conferences now; white text on black background for slides is generally banned.

Why are we designing in dark mode — be honest now

Is it because it is cool or pretty? Or is it because we think it has some actual benefit for the user?

Let’s not pretend that we’re making screens better for night reading and offsetting what blue light does to your circadian rhythms, when there are already phone functionalities such as adaptive brightness to handle that for us.

Let’s not pretend we’re being sustainable and increasing phone battery life when we’re burning loads of extra dev time creating something users might not actually need.

Data-oriented design

Online release of Data-Oriented Design : this is the free, online, reduced version. Some inessential chapters are excluded from this version, but in the spirit of this being an education resource, the essentials are present for anyone wanting to learn about data-oriented design.

The joy of silly useless software

I was invited by the wonderful organizers of the “Gamez & ruleZ” conference to speak. I’m grateful to have been given an opportunity to discuss a topic that I’m passionate about: silly software (like desktop pets or other unusual programs that are hard to classify).

Following is my talk turned into a blog post. There are a lot of recommendations here, and I hope you enjoy these wonderful, strange, silly finds…

StimuWrite is a companion writing app for people who are neurodivergent, addicted to social media notifications, or would benefit from extra stimulation and feedback when they draft and take notes.

While you write, StimuWrite provides visual feedback in the form of a progress bar and emoji that evolve as you hit your word count milestones. If the environment is still too calm for you to focus, you can add a video background to simulate being in a cafe or floating in space.

When StimuWrite was announced on Twitter I was blown away by its reception. People loved it. Not only was there interest, but a need for it.

It’s worth underlining that it’s a writing app with lots of visual feedback. In itself, if you said that out loud, it would sound like a bad idea, but it’s necessary. It offers an environment that is visually stimulating, the opposite of calm, to help people that need extra stimulation.

This one I think is valuable because it’s a very self-aware solution to help neurodivergent people who need this type of space to make work in, and it also underlines how standard software can fail. The one-size-fits-all solution to UX and our usability rules are often not as inclusive as we think. So this is a wonderful example to delve into for exactly this.

Sometimes “breaking the rules” is necessary because you have to ask who these rules are even designed for. Not everyone can thrive in these very standard environments. This is a big reason why I think it’s important to look back at older era software and kind of re-examine what we lost in our march toward progress.

Judge the work

Joy is one of the base needs of a craft. Even novelists, who as a class excel at complaining about their craft, find joy in its actual practice. Most of the creative field do what they do out of a compulsion born from joy, not from addiction. They may hate it, but both love and hate — even pain — are orthogonal to joy. (That’s why psychiatrists earn the big bucks.) Artists do what they do because it gives them joy.

Joy also comes from expressiveness. This is where we arrive at the heart of our problem when we’re trying to choose a medium. You need a canvas that lets you say what you want to say, in the way you want to say it. What you don’t do is try to choose a canvas based on whether it increases your odds of a six-figure payday. You might choose it based on the odds of a regular payday, mostly out of a need for making the craft sustainable, not for getting rich. You do art because you have something to say.

In praise of ffmpeg

ffmpeg is notable for being one of the first large-scale FOSS projects to completely eradicate proprietary software in its niche. Virtually all multimedia-related companies rely on ffmpeg to do their heavy lifting. It took a complex problem and solved it, with free software. The book is now closed on multimedia: ffmpeg is the solution to almost all of your problems. And if it’s not, you’re more likely to patch ffmpeg than to develop something new. The code is accessible and the community are experts in your problem domain.

ffmpeg is one of the foremost pillars of achievement in free software. It has touched the lives of every reader, whether they know it or not. If you’ve ever watched TV, or gone to a movie, or watched videos online, or listened to a podcast, odds are that ffmpeg was involved in making it possible. It is one of the most well-executed and important software projects of all time.

1. This is definitely not how our brains work, but it’s a useful metaphor.
2. The ability to understand something immediately, without any apparent need for conscious reasoning.
3. The ability to move quickly between different models of a problem.
4. Marian Petre and André van der Hoek: Software Design Decoded: 66 Ways Experts Think. MIT Press, 2016, 0262035189. A short illustrated overview of how expert software developers think.
5. Mitchell J. Nathan and Anthony Petrosino: “Expert Blind Spot Among Preservice Teachers”. American Educational Research Journal, 40(4), 1 2003, doi:10.3102/00028312040004905. Early work on expert blind spot.
6. Herbert W. Marsh and John Hattie: “The Relation Between Research Productivity and Teaching Effectiveness: Complementary, Antagonistic, or Independent Constructs?”. Journal of Higher Education, 73(5), 2002, doi:10.1353/jhe.2002.0047. One study of many showing there is zero correlation between research ability and teaching effectiveness.