“The long term goal of software freedom is to eliminate the harm of proprietary technology. While we work toward that greater goal, we should seek to mitigate the harms that we cannot immediately eliminate. These recommendations aim to abate the damage of these systems, and also consider how these tools might counter-intuitively help us advance FOSS.”

And yet, I still eat meat. Why?

Partially, it’s because while I agree with most arguments against meat eating, I also think that by and large vegetarians overstate their cases. Most of the environmental and social impacts aren’t really effects of eating meat; they’re results of the choices we’ve made as a society about how we produce meat. Namely, our system of industrialized farming. We don’t have to produce meat in a way that’s environmentally damaging; we’ve chosen to. Likewise, poor health outcomes are a result of eating too much meat (and not enough variety otherwise) — not something inherent in meat itself.

My guess, though, is that these arguments aren’t actually that important to most vegetarians: I think that most are probably making the decision on a moral ground. They see killing animals as inexcusable, and sort of back into the other arguments because they’re easier to explain. That’s because “killing animals is wrong” isn’t a scientific/analytical argument. You can’t prove morality with CO2 emission numbers or whatever; it’s something you feel. It’s a matter of faith. And I don’t share that belief. I believe there are moral ways to raise and kill animals for food.

I’ll go even further: I eat meat because it tastes good, and I believe it’s OK to make decisions with downsides, even significant downsides, just because they make us feel good. Living a moral life doesn’t mean we have to live a miserable one.

But that said — I do believe that eating meat is carries some moral weight, and should be done deliberately and carefully. The environmental and social impacts are a fact — industrialized agriculture has so many nasty externalities.

So while I still eat meat, I apply a harm reduction mindset. I’m not a vegetarian, but I try to eat meat in a way that minimizes the downsides, both moral and physical. Specifically: when I eat out, it’s mostly vegetables and some fish; at home, all of our meat comes from friends and neighbors raising animals in small numbers following sustainable practices. I know this because I can go to their farms and take a look! This means I eat a lot less meat, avoiding the health consequences. And as a nice side bonus, the money I spend on meat goes to people I know and like, instead of soulless multinationals.

What I absolutely don’t_do is use my own ethical decisions to judge other people. These are my choices, not a framework to criticize the relative morality of other people. I recognize my privilege in being able to eat the way I do. I can afford to buy a year’s worth of meat up-front, a couple of freezers to store it in, and the electrical bills to keep those freezers running. I have the time and energy to cook from scratch. I have access to good grocery stores to get other sources of protein to supplement that meat. I live in a community that includes farmers raising meat sustainably, and so on.

And more importantly, I understand that my own choices come at least in part from a moral philosophy that’s as much a matter of faith as it is science, and I have the humility to recognize that people with different beliefs, or people making different choices, aren’t wrong just because I disagree with them. I’ll very happily discuss my choices with people who are interested, and explain the environmental and social impacts to people who might be receptive to changing their approach to eating meat to minimize those externalities. But I certainly won’t tell anyone who eats meat differently or more often than me that they’re a bad person, or morally compromised, or whatever. Doing that wouldn’t make me more moral — it’d just make me an asshole.

In fact, I barely talk about my choices around eating meat — because hearing people spout off about their morality is most of the time annoying and exhausting. It’s all true, but the only reason I’m writing about eating meat at all is because it’s a metaphor. This has really been about AI.

Goals:

Consolidate all my photos – old archives off a NAS, a couple of years of photos stored in Google Photos, and ongoing photos taken with my iPhone – into a self-hosted Immich instance running on my NAS (a Synology). iCloud remains as a capture tool; Immich is the storage, organization, and browsing interface.

Goals: Consolidate all photos — old NAS archives, Google Photos, and ongoing iPhone captures — into a self-hosted Immich instance on the Synology NAS. iCloud/Photos remains the primary mobile capture tool; Immich is the long-term archive and browsing interface.

Tools

• Immich - duh
• osxphotos - export photos out of Photos.app / iCloud
• immich-go - bulk upload photos to Immich (I found this did what I wanted out of the box better than the first-party immich-cli)

Immich setup and installation

Streightforward, following the Immich community-maintained Synology installation guide - this installs Immich as a Docker Compose project via Synology’s Container Manager interface.

My setup is 95% as-documented, with a few key config changes and differences:

• I pointed Immich’s built-in library to /volume1/photo - a dedicated photo drive - rather than the suggested default of the Docker directory (/volume1/docker on my NAS). This is so I can have the large photo library separate from all my various Docker detritus, mostly so I can set up different backup schedules for the different items.

• I configured Immich with a Storage Template to store photos in a date heirarchy. This is so that if something goes terribly wrong, I’ll still have a somewhat-navigable photo library just on the file system.

• I have a few tools I’m building on top of Immich (not covered here, may write about these later). These are JavaScript tools, and thus need Immich to send CORS headers to be able to consume the Immich API. Immich doesn’t have anything built-in to do this, so for me the easiest way to make this happen was with a Caddy sidecar; here’s the relevant docker-compose.yml parts:

  services:
    caddy:
      container_name: immich_caddy
      image: caddy:2-alpine
      restart: always
      ports:
        - "2283:2283"
      volumes:
        - ./Caddyfile:/etc/caddy/Caddyfile:ro
      depends_on:
        - immich-server
  
    immich-server:
      # as documented, except for ...
      expose: ["2283"] # ... instead of port mapping
  

  And the Caddyfile:

  :2283 {
          reverse_proxy immich-server:2283
          header {
                  Access-Control-Allow-Origin *
                  Access-Control-Allow-Methods *
                  Access-Control-Allow-Headers *
          }
          @options method OPTIONS
          respond @options 204
  }
  

One-time imports

Import raw photo directories:

immich-go upload from-folder \
    --server=https://im.jacobian.me/ \
    --api-key=$(op read op://personal/immich-go/credential) \
    --manage-burst Stack \
    photos-from-old-nas-to-import/

For Google Photos, I requested an export through the “Takeout” interface, which took a couple of days. immich-go is supposed to be able to operate on the raw zip files that you get from Takeout, but that didn’t work for me. No problem, I just unpacked them, and ran:

immich-go upload from-google-photos \
    --server=https://im.jacobian.me/ \
    --api-key=$(op read op://personal/immich-go/credential) \
    --manage-burst Stack \
    gphotos/Takeout

Ongoing sync from iCloud

Getting photos out of iCloud is easy: osxphotos works great, and has all sorts of options. There are several ways I could import those photos into Immich, depending on the workflow I want. I considered ditching iCloud entirely; if I’d done that, I would have uploaded my photos into Immich using immich-go upload from-folder or expored the upload from-icloud option.

However, I decided I want to keep using iCloud: there are aspects of the workflow I like (namely: photos transparantly syucing to all devices; easy sharing with family members), and I’ve read several accounts of the Immich mobile app being flaky, and my photo library isn’t big enough to make my iCloud spend a problem. So, the approach I’m taking is that iCloud stays as the primary way photos get taken and synced to my Mac, and then I’ll periodically back them up into Immich for archival, organization, publication, etc.

I decided the best way to do this is to export photos from iCloud using osxphotos on to my NAS, and point Immich at that directory as an External Library. I wasn’t sure I’d be able to figure out incremental uploads into Immich’s built-in photo library – but osxphotos does incremental exports, so this works nicely. The one tradeoff is that if I make edits to photos in Photos.app or on my phone, those won’t get synced to Immich. I’m OK with that: that’s not a thing I do except very very rarely.

So, here’s the little wrapper around osxphotos that does the export:

#!/usr/bin/env -S uv run --script
from pathlib import Path
from subprocess import run

HERE = Path(__file__).parent.absolute()

def main():
    # mount the network share
    run(["osascript", "-e", 'mount volume "smb://jacob@ds2/photo"'])

    run(
        [
            "osxphotos", "export", "/Volumes/photo/ios-photos",
            "--export-by-date",                   # organize exported photos into folders by date
            "--skip-original-if-edited",          # just export  edited versions of photos
            "--download-missing",                 # download full-res versions from icloud
            "--use-photokit",                     # "experimental" downloader, per docs, but more robust?
            "--exportdb", (HERE/"osxphotos.db"),  # store export state db here (be nice to NAS)
            "--retry", "3",                       # retry failed exports 3x
            "--sidecar", "XMP",                   # XMP "sidecars" (metadata) - immich reads these
            "--fix-orientation",                  # rotate images rotated in iphotos
            "--update",                           # incrementally update export
            "--only-new",                         # only export new files, not udpated ones
            "--added-in-last", "7d"               # not strictly necessary, but speeds things up
        ]
    )

if __name__ == "__main__":
    main()

I have this set up to run nightly on my Mac, and Immich set up to re-scan the external library about 3 hours later.

Next steps:

The one missing piece is shared Google Photos libraries: frequently, after a group trip, someone will set up a Google Photos album to share photos. I’d like to export those photos into Immich, but at a cursory glance it’s not super streightfoward to do this in a fully-automated way (Google Photos has a pretty limited API for shared albums).

The other planned next step is a triage and publication workflow. The whole point of getting images into Immich was to have a foundation for building my own tooling/workflow on top of it. Key to that is a way to quickly triage albums down to a concise subset, and publish them. I have plans here, and an intiial proof of concept, but nothing I’m ready to share/talk about yet.

Please vote!

How I’m ranking candidates

The DSF faces some significant challenges in 2026, particularly around increasing our budget and moving our community forward, and that shapes how I’m thinking about this election. Here’s what I’m prioritizing in candidates:

• Fundraising experience

  This is my top criteria. The DSF’s greatest challenge next year will be increasing our funding. We have ambitious goals that require substantially more revenue than we currently have. Anyone bringing fundraising experience moves to the top of my list

• Community management experience

  I’m grateful to everyone who’s contributed code to Django, but it’s not relevant experience for the board. – the DSF doesn’t write code. I’m looking for people with experience in community management, preferably (in order of priority):

  1. Direct DSF experience — working groups, committees, etc. This is my highest priority
  2. Other nonprofits of similar size and scope
  3. Related groups like Djangonaut Space or DjangoCons
  4. Broader Python ecosystem organizations like the PSF

  Experience trumps desire here. I want people who understand what they’re signing up for.

• Clear vision and specific goals

  I’m looking for candidates who articulate not just what they want the DSF to do, but how they plan to get there. Specific tactics and measurable goals carry more weight than general aspirations.

• Diversity of experience

  The DSF claims to represent a global community, and our leadership should reflect that. So, among candidates with the kind of experience covered above, I’m prioritizing candidates outside the US and Europe. Similarly, Django is used across many industries, but we’re overrepresented in traditional “tech” companies. So in the same way, I’m prioritizing candidates with experience in other fields – education, finance, (physical) engineering, government, nonprofits, etc.

Yes, this sounds self-serving — I’m a candidate and check several of these boxes. Not all of them, though! In fact, on my ballot, I’ve ranked several candidates above myself.

Still, even if you think I’m biased, please think about these criteria – I think you’ll agree they’re important for the DSF. The DSF faces some challenges in the next few years, and we need board members who can navigate them successfully.

Now go vote!

This is also the default for many small-to-medium-sized companies’ engineering organizations: while the engineering department is usually split into smaller teams, anyone from any team with sufficient time and interest is welcome to hop into another team’s slack channel or corner of the codebase.

However, there are situations where this doesn’t work (I’ll talk about a few of those situations below). When that happens, the impulse is to go full-on in the other direction, and work entirely in private. “Private” meaning: work done by a select group of insiders, with no mechanism for the broader company/community to get involved.

But… it’s not a binary! There are many working models that fall in between fully public and fully private. This blog post is about those middle-ground options. My goal is to convince you to think about using them more often. If working in public isn’t working, consider adopting a middle-ground option instead of retreating into fully-private.

Ends of the spectrum

The two options, as usually presented, are:

Working in private

All work is done by a select group of insiders. There’s no mechanism for someone outside the group to add themselves. Conversations happen solely within the group. Perhaps there’s some level of reporting out, but if so it’s a one-way communication: “look, we did a thing”.

The problems with this model, especially in the context of open source, seem fairly obvious. There’s no mechanism for feedback from outside the group. Work is presented as a fait accompli. This model is not great for building community, and it’s also pretty risky: if the in-group gets something wrong, they can go pretty far down the wrong path before finding out about it. This is how you get, for example, companies launching new versions of their product that are significantly worse than the older version¹. Or less dramatically, a group working in private on a pull request that never lands because they missed something critical early on.

Working in public

The other end of the spectrum: all work happens fully out in the open. As discussed in the introduction, this is usually the default for open source projects and, to a lesser degree, small-to-medium-sized companies. There’s almost always some level of gatekeeping, but the key part is: you don’t need permission or an invite to get started, you can just show up.

There’s a reason why this is the default for open source: it works! (Most of the time, that is – but we’ll get to that.) Open source projects live and die on the strength of their community, and this model optimizes for community engagement. It also maximizes your changes of getting great contributions from someone outside (or new to) your community.

When working in public doesn’t work

But from time to time, we run across situations where this “no permission required” model breaks down. Two examples that come to mind:

1. Design decisions. There’s a reason why “design by committee” is a pejorative. Good design relies on a strong vision, and too many voices only dilutes a vision. I’ve seen this hold true for both visual design and API design – matters of style and taste. These situations don’t have clear “correct” answers; there’s a universe of good options. That’s a recipe for paralysis, where it feels impossible to move forward because there are too many credible options. Or, if it does move forward, it does so as an average of many competing options, and thus is confused, or bland, or otherwise incoherent – because it’s no longer a design with a vision behind it.

2. Filibuster. Sometimes, a public conversation ends up getting dominated by one (or a few) loud voices who, for whatever reason, are willing to talk way, way more than anyone else. Instead of making space for community consensus to form, they dominate the conversation, drowning out other voices through sheer volume. People who might have good contributions don’t want to get involved because reading through hundreds of pages of forum posts, most by the same person, is exhausting. Thus filibusterers create a false sense of consensus as their point of view appears to dominate. (And they burnout/exhaust other community members in the process.)

These are real dynamics; anyone who’s worked in open source long enough has seen them happen. I’m thinking of several real-world examples of these dynamics as I write this. So it’s understandable that, when faced with one of these situations, people conclude that working in public is the wrong approach.

However, here’s the fallacy I want to address: faced with a situation that’s wrong for a fully-public working style, many people conclude the only other option is to do the work in secret, and only present it to the larger community when it’s done.

In between public and private

This is a wrong! There are all sorts of options that lie somewhere in-between “anyone can show up and contribute” and “only insiders allowed.” It’s quite possible to set up a working model that has most of the benefits of working in public – a wide net for contributions, community engagement and involvement, rapid and frequent feedback mechanisms, etc. – while also retaining many of the benefits of working in private – more rapid movement, less bikeshedding, ability to execute a clear vision, etc.

If working in public isn’t working, consider adopting a middle-ground option instead of retreating into fully-private.

Common successful patterns for in-between-public-and-private working models

While there are innumerable ways to structure a middle-ground approach, the ones I’ve seen be successful share a few common patterns:

• A clearly-defined charter or mission that lays out what the group is for, what its remit is, who the membership is, and so forth. This is a key bit of transparency that lets outsiders know who’s doing what and why. And having a clear scope keeps the the group on track, and prevents surprises (“I didn’t know they were working on that!”)

• Leadership buy-in: whatever “leadership” means in your context, it needs to support the charter of the group. Sure, occasionally that “leadership” may need to override a sub-group’s decisions, but the general expectation should be that whoever chartered the group has their back.

• Clear rules and procedures for adding and removing people from the group. This could be elections, appointments, an application procedure, etc. The specific mechanism is relatively unimportant; what matters is that outsiders need to be able to understand why the group composition is the way it is, and what mechanisms are available to join.

• Regular report-outs: the group needs to report on what its doing, frequently enough to (again) provide transparency and prevent surprises. Frequency varies a lot depending on the nature and scope of the group, but somewhere between weekly and monthly is a good starting point for most groups.

• Well-defined, structured mechanisms for broader input: finally, the group needs mechanisms to take feedback in. This needn’t be a free-for-all; it can be structured (feedback forms), timed (notice and comment periods), public or private, etc. What matters is that outsiders who want to contribute have a direction to channel their energy. If they don’t, it’ll spill out into the kinds of unproductive sprawling public discussions you were trying to avoid in the first place.

If working in public isn’t working, consider a middle ground

I hope this opened your mind to more options for working models beyond fully-public and fully-private. If you do end up choosing a middle-ground working model, get in touch – I’d love to hear about it!

This just isn’t true! Some planning is always better than no planning. In fact, you can get a surprising amount of value out of a very simple and fast technique: imagine a couple of scenarios – just two! – and game out what you could do to mitigate them.

I’ll cover a bit of background first, but if you just want to get to the exercise, skip ahead to that section.

Scenario-based threat modeling

What do I mean by “scenario”? There are a variety of techniques for doing threat modeling: systems-oriented (diagram a system and consider threats at each node in the system); data-oriented (map all the data in your system and consider threats to each bit of it); attacker-oriented (enumerate the possible “bad guys”), and so forth.

One of the very simplest, though, is to tell stories. Make up something that might go wrong, imagine how it might happen, and think about how we might mitigate the risk. These can be stories we make up from whole cloth, “ripped from the headlines” scenarios we’ve seen happen elsewhere, or (most commonly) scenarios “based on true events” that mix some reality with some imagination.

Scenario-based planning tends to work really well because human beings are great at telling and remembering stories. We think in narratives, stories prime our imagination. It’s easy for us to keep our risk scenarios in mind — far easier than remembering some complex threat model or risk plan or attack tree.

You only need a few scenarios to generate a ton of insight

With other forms of threat modeling (especially systems-oriented and data-oriented techniques) incompleteness can be a big problem. For example, a systems diagram that leaves off the build server that bridges testing and production leaves off a critical node, and leads to faulty insights about the security of your network perimeter. But with scenario-based planning, incompleteness is sort of inherent — there are a near-infinity of possible futures — and it only takes a very small number of scenarios to yield tons of insight.

It’s a similar dynamic to usability testing. In that field, Jacob Nielsen famously found that very small usability studies – five users – offer similar results to much larger studies:

The most striking truth […] is that zero users give zero insights.

As soon as you collect data from a single test user, your insights shoot up and you have already learned almost a third of all there is to know about the usability of the design. The difference between zero and even a little bit of data is astounding.

[…]

As you add more and more users, you learn less and less because you will keep seeing the same things again and again. […]

After the fifth user, you are wasting your time by observing the same findings repeatedly but not learning much new.

In a very similar fashion, with scenario-based planning, the very first scenario you consider yields a surprising amount of information, and after that there are rapidly diminishing returns.

I’m not aware of any sort of formal study here, so I can’t offer a number as specific as Nielsen’s “five”. But I can tell you, from a ton of personal experience, that considering just two scenarios – as long as they’re the right scenarios – can yield nearly as much actionable insight as a much more in-depth, complex, formal threat model exercise.

Two-scenario threat modeling

Thus, we get to what I’ve been calling two-scenario threat modeling. In this exercise, you¹ come up with two specific scenarios to guide your risk migitation conversation:

1. Worst-case scenario.

   This is the big, existential threat; the scary thing that keeps you up at night. An avalanche on a ski trip; a bank losing customer funds; a total data breach; a medical device being compromised to harm a patient; and so on.

   Usually this is fairly easy to imagine: most situations have a couple-three “really bad things” that everyone’s already thinking about. Don’t waste time trying to decide which of a few options is “worst”: this doesn’t have to be the worst-case scenario, it can simply be a worst-case scenario.

   This scenario can be pretty unlikely — though, make sure it’s at least reasonably possible — as long as it has very high impact.

2. Most-likely scenario with tangible impact

   This one’s a bit hard to describe. It’s not the most likely scenario, since these are often boring. E.g., the most likely problem for a web app is probably some sort of minor crash without data loss which just doesn’t have a lot of “meat” for discussing mitigation.

   Instead, look for a scenario that ranks somewhat high on both impact and likelihood. Something that’s fairly likely to happen, and that would really hurt if it did. Err on the side of higher likelihood: you want a scenario that’s as likely to happen as possible, while still having at least some impact.

   Some examples: a partial data breach; an attacker is able to escalate privileges, not to a full admin but to some sort of partially-privileged role like customer support; mild hypothermia; getting lost; a breach of embarrassing (but not existentially-threatening) internal documents; etc.

Be super-specific about both scenarios. Remember: tell stories. The examples I gave above are just starting points; a full scenario should include a detailed narrative. For example, instead of “partial data breach”, go with something like:

We accidentally deploy a testing version of our web app with debug mode on to a public domain. An attacker discovers this testing app, and is able to generate a crash which, because of debug mode, reveals an AWS credential. This credential that allows read-only access to some of our S3 buckets, one of which contains a partial backup of our user database. The attacker downloads this backup before we discover the error and take down the app. This backup contains about 30% of our user data, including names, emails, and zip codes; it doesn’t contain passwords, hashed or otherwise.

Write down both scenarios in detail. There are then any number of things you could do from here, from informal (e.g. brainstorm mitigations and come up with some potential projects to reduce risk) to formal (e.g. construct formal attack trees for each scenario). Perhaps I’ll write about some of those techniques in the future – let me know if that sounds interesting. The very easiest, however, is simply to circulate these scenarios widely, and encourage people to keep them front-of-mind during their work. Once again, this leans into our propensity for stories; people usually find it pretty easy to remember a couple of scenarios, and avoid making decisions that increase risks in those areas.

So there you go: a threat modeling / risk planing exercise that doesn’t take much time. Give yourself an hour for a brainstorm meeting, and a few more hours to write something up – boom, you have a useful threat model in under a day.

You do need a small baseline of trust and psychological safety with the group since it requires being a little bit vulnerable about your comfort level. So it’s probably best in situations with shared context, e.g. kayak or climbing clubs; or among groups with similar training backgrounds, e.g. a group of guides with similar certifications

It works like this: everyone individually thinks about the trip and the group’s objectives, and states their comfort with the trip as planned, giving a score of 1, 2, or 3.

• 3 means: “I’m super comfortable. This is well within my skill – so much so that I’lll be able to help others.”

  At a “3”, you’re not just getting through the day; you’ve got spare mental and physical capacity to help out others. This might be a Class IV boater on a Class III river they’ve run a bunch of times, or an experienced backpacker out for a short overnighter in easy terrain, etc.

• 2 means: “I can do this, I can look out for myself. but it will require focus.”

  At a “2”, you’re at your comfortable level – not above it, you’re not overreaching, but you’re doing something that’ll challenge you and require your full attention. You will not be available to help others.

• 1 means: “I’m uncomfortable or nervous, and I’ll need some help getting through the day.”

  A “1” doesn’t mean you’re over your head, or that you shouldn’t go on the trip; it means that there’s a reason you’re doing this in a group! You’ll be stretching some, and may need a hand to have an optimal day. For example, I’m going on a canyoneering trip next week where I’m going to be a “1”: it’s a canyon I’ve done once before, and I know there’s a very tricky move on the final rappel sequence. I needed an assist there last time, and I don’t think I’ve improved enough to attempt that bit unassisted.

The group then totals up the scores. Your total score should be around double the size of your team – e.g. if you’re a team of 6, you’d like a total score of 12 or more. Anything above that mark indicates you’ve got more help available than you have need for help – a good sign!

If the total score is below that mark, it’s a sign you should stop and think carefully, and even consider cancelling the trip or changing objectives. An average below “2” indicates that you have more need for help than you have help available, and that might be dangerous. At the very least, you should carefully discuss how you can increase your safety bargain.

This exercise can also prompt discussion with the “1"s about what and where they might need a hand. Often I’ve seen “3"s and “1"s connect during/after this exercise and make some specific plans for where/when/how to work together to increase safety/comfort.

I think this is probably most useful in wilderness risk mitigation, but you can probably apply it to other disciplines. If you do, I’d love to hear about it!.

You should use AI-powered tools to complement or increase your agency, not replace it.

Would you believe me if I told you that this was safe? That we’ve considered the risks very carefully, and mitigated them? Or would you say that someone who rappels down waterfalls probably isn’t thinking very clearly about risk?

The “people suck at thinking about risk” framing

There’s a common belief among risk professionals that people are inherently bad at thinking about risk. Specifically, that people inherently make poor decisions when confronted with risk of the “low probability, high consequences” variety (e.g. traveling in avalanche terrain, releasing software with known but difficult-to-exploit vulnerabilities, etc.). I’ve certainly said many times, and I think I mostly believe it. But in the last couple years I’ve started to question this foundational narrative, so I want to spend a few minutes thinking through the implications of starting from a different point of view.

The “people suck at thinking about risk” view certain has plenty of weight behind it. Talk to any risk professional and they’ll have hair-raising stories about people doing intensely idiotic things, believing themselves to be safe. (I once witnessed a person who could barely swim launch themselves into dangerous whitewater without any plan to get out, and, after being pulled out by their shoulders, continue on the trip blithely unaware that they had been moments away from drowning.) Any software engineer with a modicum of experience will tell you about launching software known to be unsafe or unstable, only to have management be genuinely shocked when the inevitable eventually happens. And then there’s the reams of social science research and pop psychology to back this up – Nicolas Taleb (Black Swan) has made a very lucrative career covering the “people suck at thinking about risk” beat, for example.

Experiences that challenge this framing

However, in the last couple of years, I’ve had some experiences that cut against this common narrative:

People have surprisingly keen assessments of their digital security risk

Over the last six months I’ve conducted dozens of digital security checkups (probably well over 100, but I stopped counting). My approach to risk during these calls has been to start with assuming that people’s concerns are valid, and moving directly to actions they can take to address those concerns. In other words, I don’t spend any time on questioning if their perceived risk is “correct” (unless that’s something they’ve explicitly asked for). If someone tells me they’re worried about being doxxed, I take that worry at face value and talk through what they can do to prevent and respond to a doxing.

This wasn’t a considered decision: it was purely pragmatic. I have 90 minutes with someone, who I’m almost certainly meeting for the first time, and I want that time to be as valuable as possible. Starting from an assumption that the risk analysis is correct, and moving immediately to giving them tools and techniques for risk reduction just seemed like a way to make the best use of the time.

What really surprised me was discovering that nearly everyone I spoke to seemed to have a pretty solid grasp of their risk! Almost nobody came to me with movie-plot threats or paranoid conspiracy theory nonsense. Instead, people had pretty keen assessments of their risk: activists were afraid of their communications being monitored; pregnant people were nervous about crossing state lines to get health care; therapists working with trans people were nervous about their EMR systems being compromised; content creators worried about being doxxed; and so forth. With very few exceptions, people came to me already zeroed in on exactly the threats I would have likely identified as the most risky to them, without any prompting or help on my part. If most people are bad at thinking about risk, why wasn’t I seeing that?

“Risky” outdoor activities are much less risky than they seem to an outsider

And then, I’ve had some shifting of my thoughts on risk through my outdoor adventures. In the last 3-4 years I’ve picked up some new forms of wilderness travel that carry more objective hazard: canyoneering, packrafting, and backcountry skiing. It’s common to characterize people who engage in those activities as “risk-seekers”, or as having a “high risk tolerance”, but I think that’s incorrect. Sure, a few people are — but they’re a minority. Communities around these sports have strong cultures of safety; the people who engage in these activities think about risk in a much more sophisticated and systematic way than I’ve encountered nearly anywhere else. To put the finest point on it: these communities are significantly better at thinking about risk than the software and security communities. I apply risk tools I learned outdoors to computer things far more often than I apply risk tools learned at a keyboard to my “risky” outdoor activities.

Many people — including me — are drawn to these activities not by the risk but by the challenge of risk mitigation. It’s tremendously satisfying and empowering to develop the skills that allow making something that could be dangerous acceptably safe. Many (most?) people who engage in these sports aren’t “risk-seekers”; rather, they’re “risk-mitigation-enjoyers”.

Return to the picture at the top of this post. If you’re unfamiliar with canyoneering, the “people suck at thinking about risk” framework would lead you to think that I’m most likely deluded about the risk. But the “trust people to assess their own risks” framework will lead you to conclude that we’ve thought carefully about doing something like this, and taken proper steps to mitigate risk. And indeed, if we spent time talking through the risks and the safety systems we’re using to mitigate them, I think you’d conclude, as I have, that the most dangerous part of the day was driving to and from the trailhead.

It’s counterintuitive, but I believe that engaging in activities with more hazards has made me more safe outdoors, rather than less. That’s because these activities have forced me to think about risk much more carefully, and learn more tools to mitigate those risks.

Implications of a “trust people to assess their own risks” narrative

So, what would it mean if, instead of assuming that “people suck at thinking about risk”, we started from a foundation of trusting someone’s risk assessment?

The major benefit is that we get to skip a whole complex risk analysis discussion and skip directly to the giving people tools to mitigate risk. Practically-speaking, I’ve found it very difficult to convince people to change their risk assessment; unless they’re explicitly asking for help calculating risk, telling someone they’re wrong about their risk assessment is unlikely to go over well. I once encountered a group of young men getting into a position for a fairly dangerous cliff jump – a jump that kills about one person a year¹. I tried to convince them not to jump, but obviously that didn’t work. How often does telling someone they’re thinking about risk “wrong” actually work?

But what if that’s because people aren’t actually taking “too much” risk, but instead they’re taking the right amount of risk for them, and really only need better tools to manage their risk? What if instead of telling them not to jump I’d told them where the bolts were and encouraged them to get the gear to rappel next time?

This is basically a harm reduction approach to risk. Instead of trying to convince people to change their behavior wholesale, we give them tools to make their current behavior safer.

Here’s a good example from the security field: password management. This came up in most of the digital security reviews I performed; nearly everyone had questions here. There’s a “correct” answer here according to conventional wisdom in the security industry: use a password manager, and use different passwords for every site. But the people I spoke to had a very wide range of digital expertise and – let’s be real here – password managers aren’t exactly the easiest piece of software to use. Nearly everyone I’d spoke to knew about password managers, most had tried them, but many had had terrible experiences of getting locked out of something important, and had fallen back to some other technique.

The “people suck at thinking about risk” framing would tell us that these people are making incorrect risk/reward judgements. Yes, password managers are hard to use, but the risks they mitigate make it worth it to power through. This framing would tell us we need to help these people understand that risk better, and once they see how risky their behavior is, they’ll choose the password manager.

Man, I don’t know. That feels pretty dismissive of the actual lived experience of trying to use the tools balanced against that actual practical real-world impact of an account breach (which, for most people, ends up being more of an annoyance than a life-changing event). So the approach I took was to assume that people were basically correct about their risk/reward judgement, and to try to give them suggestions and nudges to improve their current behavior. If they were using the same password everywhere, I’d explain about credential-stuffing attacks, and encourage them to use a unique password on a few of their most important accounts (email, banking, medical records, etc.). If they were writing passwords down somewhere, I’d help them make sure that it was a good somewhere. If they were using a password manager but struggling, I’d help debug or suggest an easier-to-use password manager. And so on.

Is this the “right” approach? At the end of each of these calls, very few of the folks I spoke to were doing the best possible thing according to conventional wisdom. By that mark, no, not great. But nearly everyone I spoke to about passwords left the call a little better protected than they were earlier that day. I think if I’d tried to browbeat people into using password managers I’d have had little success. A world where I help dozens of people make a modest improvement feels better to me than one where I’m only able to convince a small handful to make a huge improvement.

There’s a pragmatic wisdom to starting from a position of trust. Maybe people aren’t always making perfect risk decisions, but treating their concerns as legitimate is often the only way to have a productive conversation about risk at all.

This is a conversation-starter, not a strong argument

I must admit that this approach makes me deeply uncomfortable in some contexts. I can’t bring myself to “trust people’s risk assessment” about vaccines, for example. There’s objective scientific evidence here, and anti-vaxxers are just totally wrong.

So I’m not trying to make a strong argument here that “trust people’s risk assessment” is a better way of framing risk than “people suck at thinking about risk”. But I am arguing that we should keep both framings in mind, and probably choose the “trust” approach more often than we do.

What do you think? Get in touch!

3. There’s no single point below which you are “really” ultralight, that’s just gatekeeping. There are instead two important inflection points:

   1. The weight below which your hiking speed is more or less unaffected by the pack.
   2. The weight above which your pack is noticeably heavy and uncomfortable.

   Importantly, these inflection points differ for each person and for each pack — the comfort zone for a flimsy frameless pack is quite different from that of a full suspension load hauler.

4. Adding weight as long as you don’t cross an inflection point is basically free. Cutting out luxuries or spending money to get lighter when doing so doesn’t change your subjective experience of backpacking is an exercise in gear hoarding or showing off online, not something that actually matters.

5. “Base weight” is a ridiculous concept. What matters is the weight on your back. A better metric than base weight is “average pack weight”: how much are you carrying, including food and water, at the midpoint of your trip? (Or the midpoint between resupplies.)

6. Making gear lists and weighing individual items can be fun (I love me a good spreadsheet), and is a useful exercise to figure out where the weight is coming from. But it’s totally useless if you don’t weigh your actual pack — with food and water.

7. For any trip longer than a couple-three days, efficient food weight matters more than gear weight. Seven days worth of food at 100 calories per ounce weighs over 15 pounds; at 125 calories per ounce you save 3 pounds. Or you could spend $800 on a Dyneema tent and save 6 ounces.

8. SmartWater bottles suck. They don’t last, contributing to plastic waste; the caps are easy to lose rending them useless; the narrow mouth makes the hard to fill from shallow water sources and hard to add drink mixes too; and they melt if you put boiling water in them, so they can’t be used as a hot water bottle in cold conditions, narrowing your safety margin. The Nalgene has been the right answer all along.

9. The point of a trip is to have fun. Maybe Type 2 fun, but fun all the same. Generally speaking you’ll have a better time with a lighter pack, but that’s not a law of the universe. Once you’ve reached the point where cutting out gear is leading to a much worse experience, stop and add back some luxurious.

10. Stay off r/ultralight. Bring the gear that’s appropriate to your trip objectives and conditions.

I needed to replace a rubber hydraulic hose retention strap on my tractor. The part’s $40 + shipping – ludicrous for a 6x2" strip of rubber – so perfect to try to replicate. I have some TPU filament that’s of similar flexibility, let’s go.

For V1, I just replicated the geometry exactly - including, without thinking about it, some little relief holes around the main hose holes:

In the original rubber part, these holes serve to weaken the rubber around the hose holes, allowing the strap to be stretch around the hoses. But 3D printing is different: 3d printed parts make a few solid permitter loops around the outside edges of the part, and then weaker sparse patterned “infill” around the rest of the part:

Thus, in the 3d printed part, these holes actually make the part stronger in those areas — precisely the opposite from the conventionally-manufactured rubber original. Oops!

The fix was to weaken those holes in a different way more suitable to 3d printing:

(I also used the “grid” infill patterns, on the suggestion of a friend, because it’s weaker in the vertical direction and thus allows the part to flex a bit more than other infill patterns that are designed to be strong in all three dimensions.)

Potential Causes Of Accidents In Outdoor Pursuits

1. I’m leaving the tech industry. Hopefully “for good”; if not, at least “for now”.

2. As such, the content on this blog is going to shift, perhaps dramatically. I’m going to be writing about a broader range of topics that interest me (projects around my hobby farm, wilderness trips, emergency medicine) – more writing for me, less writing for some imagined audience. (I’ll probably still end up writing about some of the same topics as I’ve been covering since 2020, just less often.)

I’m writing this post mostly to give myself permission to make that change, and to give readers the opportunity to unsubscribe/unfollow if they’re not interested.

If you’re interested in more details about why I’m leaving the industry and what’s next for me and this blog, read on.

Leaving the tech industry

I left what I hope will be my last tech job in October. In many ways it was the perfect job: work I enjoyed, great clients, co-workers I loved (and still miss), at a company whose mission and ethics I aligned with. And despite all that I found myself increasingly burnt out. I started telling people that “I love my job, but I hate my career.”

I’ve been working in tech more or less non-stop for more than 25 years, and in that time my feeling about the industry has changed dramatically. When I began, I held straightforwardly techno-utopian ideas: I believed that technology was an unalloyed force for Good, that the computer revolution would bring about a more just and equitable society. I thought the industry was going to create a Star Trek-esque post-scarcity society.

I cringe at past-Jacob’s naiveté. It’s been incredibly demoralizing to discover what the tech industry actually did was to invent surveillance capitalism, create exploitative “gig economy” business models, create a new generation of robber barons, enable the rise of global fascism, facilitate genocide, and I could go on but Christ I’m exhausted.

I’ve been thinking about leaving the industry since at least 2016, but haven’t been brave enough to do so. This career pays really well for easy work (physically, at least), and it’s all I’m good at. Doing something different is terrifying. But I’m able to afford a change in direction, despite the massive pay cut, so I’m doing it.

I want to be super-clear about this: I’m in no way criticizing anyone who makes a different decision. Leaving a good tech career is a terrible financial decision, and I absolutely won’t criticize people who’re unable or unwilling to make such a bad decision. This is about me: I’m able to make this move, so I’m going to. There’s no judgement of anyone else here, explicit or implied.

I still find computers themselves incredibly exciting. When I first learn to program, being able to make a computer do whatever I wanted felt like a superpower – and it still does! I’m not planning a total exit from anything computer related; I don’t think I could. I plan on continuing to be involved in the Django community and with the Django Software Foundation. I’m continuing on as an advisor to a couple of small companies I’ve been working with (with a change: I’ll step down if/when those companies do a traditional VC raise). I’m remaining open to limited advising/consulting work – though, I’m going to be pretty picky about who it’s for. And I’m sure I’ll always write software, it’s just too fun and useful a skill.

My plan is to go into emergency medicine: I’ll be training as an EMT this fall, and I’m starting to volunteer with our local county Search and Rescue team. I plan to work as a EMT for a year or so, and then perhaps work towards becoming a Paramedic.

I don’t know if this’ll work out. It might not. But I’m giving it a shot.

Changing the focus of my writing

I’ve been writing here since 2005. At first, this was a typical early-2000s personal blog: I wrote whatever I wanted – technical posts, recipes, live updates, whatever. Then there a long fallow period starting around 2010 when I wrote sporadically, just a few posts a year.

In 2020 I rebooted the blog, with a very specific editorial focus: tech leadership, focused on software engineering and security. I wrote with a fairly specific audience in mind: engineering managers and technical leads, working in software development and information security. Mostly the theme was: things I wish someone had told me before I messed it all up. I put a concerted effort into building an audience for this content, and I think I’ve been pretty successful at it. I’m happy with the results, at least. I’m sure I’ll keep writing about these topics – I remain fascinated by risk decisions, and will almost certainly continue my Thinking About Risk series.

But as I step away from tech, I find the things I’ve been writing about since 2020 less and less interesting. I’ve been wanting to write about a broader range of topics for well over a year, but have felt constrained by my own editorial choices. So a large part of writing this post is just to give myself permission to stop writing for this imagined audience, and go back to writing more for myself, for the pleasure of writing itself.

The editor in my head is telling me that I need an effective ending to this piece, and that I shouldn’t publish it without one. But that’s the same guy telling me to stay in my lane, so…