Does Baby Have Hat

It’s April Cools! Last year I wrote about parenting, in 2023 about friendship bracelets. and in 2022 about cocktails. This year it’s a bit of a meandering stroll through some ideas around mutual aid and self-reliance.

Maternity wards

If you walk around the maternity ward at Kaiser Permanente’s Sunnyside medical center outside of Portland, Oregon, you might notice the same two things I did. The first was how many signs were posted on the hallways describing the maternity team’s KRs and displaying charts showing that they are meeting them. My favorite metric was the one called, “Unplanned Descents to the Floor,” which is a poetically bureaucratic way to describe falling.

The second thing is that on every nurse’s desk there was a basket of tiny knit and crocheted hats. They are free, donated by members of the community, so that babies have something to keep their heads warm. It’s not a need-based thing. Babies just happen to be born totally hatless, and new parents often forget that newborns need a hat for warmth. I had one kid already, and I still forgot when planning for my daughter’s birth last summer.

I was reminded of this kindness when I saw a BlueSky post¹ about a talk by Sydette Harry via Code for America.

The biggest thing I say when I go into any room as a researcher or a tech person is how are we answering this one question: does baby have hat? My mother knits hats for the NICU in my neighborhood. My mother is like many other mothers, fathers, […] elders, who make things for small children because they lack them.

When we go to make code, […] we are filling a need. […] It’s not innovative. The innovation is not you’re doing something new. Crochet has been around for centuries. The innovation is that the person, a baby, didn’t have a hat. Now a baby has a hat. That is the innovation.

Harry is speaking to much broader goals and topics than me, but her call to action boils down to, “first, talk to people to learn what they need.”²

Super tech support

Indeed, I like to talk to people. I’ve always been interested in learning more about what work is like for my non-software friends, and generally what work is like in different industries. I was jealous to read Jessie Frazelle’s 2019 blog post about shadowing two friends each for a day of work in medical and government roles.

In lieu of having that kind of opportunity, and as a means of stirring up conversation, I’ve taken to asking my friends in non-tech jobs, “If you could automate any part of your job, what would it be?” They’re never particularly good at answering it, perhaps because they just aren’t steeped in that mindset. But it often leads to interesting conversations in which something about computers frustrates them.

One friend revealed that a nontrivial part of their work involved copying and pasting huge amounts of data between Excel spreadsheets, and the amount of data being copied was so large that the computer would just hang for a few minutes while it worked. Another explained how they needed to aggregate data from a bunch of different sources to make a monthly report. A third had a tedious process of building Google slides presentations that were used as a classroom assignment. Yet another admitted to having huge website hosting fees because they used full-resolution images and didn’t know how to compress or optimize their website.

What always strikes me about these conversations is that, once I understand the problem, and once I refresh myself on how to use the relevant tool, it can often be solved in slightly less than an hour. Sometimes it involves me writing a Python script and teaching them to double-click it while dealing with an occasional token refresh. Sometimes it’s finding the right Chrome extension. Sometimes it just requires helping them better learn how to use the tool that they’re already using, because the feature they need is hidden somewhere in the UI. I’ve come to call these small-batch tech problems.

Small-batch tech problems are not always about work. But work is a big part of our lives. Work also forces our conflicts with technology to be resolved, one way or another. Usually the human relents to the seemingly capricious whim of the computer, compensating for technology’s failures (and their own lack of expertise) with time, effort, or money.

By contrast, I have another friend who is much more self-driven. He had a highly clerical job that involved data entry and copying things around spreadsheets. He eventually taught himself how to use AutoHotkey, a Windows scripting tool for automating UI interactions, and he reduced his job to a few hours a week. During that time, he then studied enough programming to switch to a video game development career. But as he tells it, his manager didn’t like the idea of him automating his job, and when my friend did it anyway, the boss only found out because my friend’s work output had significantly fewer errors than his colleagues. His small-batch tech problem was a gateway to a broader sort of agency.

Does user have agency

I don’t have anything resembling proper evidence for this claim, but I suspect there’s no culture in the software industry of people helping others in their community with small-batch tech problems. There are some heartwarming examples, like this MomBoard e-ink display for a parent with amnesia. But most examples I see are limited to helping family members, and are usually in-depth and extravagant-or else they wouldn’t be featured in the algorithmic feeds that I happen to browse.

I rarely hear about tech people solving small-batch tech problems. I get no sense that we have a culture of helping people compress images to save people on hosting fees, or writing a script to help someone automate an annoying part of their job. Instead we write frameworks and apps, trying to solve some imagined problem at scale or to theoretically obviate the problem entirely. More often than not, we fill the world with more stuff that doesn’t ultimately solve a problem. Instead of a baby getting a hat, we get a 15th competing standard. Instead of reducing unplanned descents to the floor, we scatter more obstacles in the path. And instead of building self-reliance with technology, we transfer their reliance to a new piece of technology.

Upon reflection, I have come to believe one truth: why have these skills if I don’t use them to help the people in my life?

In her talk, Sydette Harry points out that the problems of those most in need are more systemic, like not having stable internet access, or having no way to navigate a system to appeal a problem, like being locked out of an account. Those are hard problems to solve systemically. One could argue that me, a rich white guy Google engineer, helping my friends and neighbors with their tech problems only exacerbates the tech divide. My skills are really only relevant to helping people who are also comfortably nestled within the information economy that makes automated spreadsheet munging valuable.

And there are these other typical ways I am told to help: volunteering at Black Girls Code, donating money to various organizations, or spending a day helping out at a local public school (all of which I do, though I could always do more). These might have long-term, indirect value, but what they lack is immediacy. I can’t point to any of these techy volunteer events I’ve ever done and say, yes, now baby has hat. If I could work with these people regularly, and build a relationship around building math or tech skills, that would be different. But these kinds of opportunities are one-off. I never see the beneficiaries of my volunteering again.³

Immediacy is important. Showing up to consistently deliver value is important. They can be the difference between your manager valuing your work and deciding you don’t make the cut for layoffs. It’s the difference between people seeing their government as helpful and expedient, versus voting for a dictator. You need to know that what you’re doing actually helps, and the people being helped by tech need to see it. Part of what builds this immediacy is being around to see the value materialize and continuing to build on it. Turn one good experience into more conversations, and eventually into building self-reliance with computers.⁴ At a time when tech companies—including the one that employs me—are actively making their products more opaque and less reliable, showing people how tech should work for them is a first step toward more people having the self-reliance and agency over their computers that programmers enjoy.

Thanks to Predrag Gruevski and Hillel Wayne for feedback on a draft of this article. Hillel pointed me to an 2004 article by Clay Shirky that also discusses this topic.