What if Maintainer Burnout Isn't Burnout

Imagine you're staring at your 11th AI-generated pull request of the morning.

The code looks ... fine. The description is polished. Bullet points, a clear rationale, tests, and updated docs. But when you ask the contributor a question about why they'd chosen this approach over the one used everywhere else in the codebase ... nothing. Because they don't know. They'd never read the codebase. An agent had generated something plausible-looking, and a human hit submit.

You're not tired. You're not overworked. Not exactly. You just can't remember why you started doing this.

Yes, this is about AI, but it's also about what open source maintainers were experiencing even before AI.

Doctor Burnout

Dr. Joseph Silletti is a urologist who wrote a piece for MedPage Today called "What if Burnout Isn't the Problem?" 1 He'd noticed something about his colleagues that feels ... familiar.

They weren't exhausted. Or at least, exhaustion wasn't the only problem. They were still showing up. The work was manageable. But they'd lost something. Silletti describes it as "quietly losing the thread of why the work mattered in the first place." 2 (emphasis mine)

He says we're calling it burnout. But it's not burnout. Not exclusively. It's something else.

Burnout is a specific psychological construct: emotional exhaustion, depersonalization, diminished sense of personal accomplishment. It's a tank run dry. 3

Languishing is different. The term was coined by sociologist Corey Keyes 4 and popularized by Adam Grant during the pandemic. 5 It's the space between mental illness and flourishing. Stagnation. Disconnection. Dimming purpose. The tank has fuel. You've just forgotten where you were going.

Silletti puts it perfectly:

It isn't that we can't do it. It's, what's the point? 6

Is that how you're feeling, staring at those pull requests?

Open Source Has the Same Disease

The open source community has been treating maintainer distress as burnout for years. The Tidelift 2024 survey found that 60% of maintainers have quit or considered quitting. 7 The top reasons: competing life demands (54%), loss of interest (51%), burnout (44%).

But look at that list again. Loss of interest is number two. That's not the tank running dry. That's disengagement. That's someone who still can do the work ... they just don't know why they're doing it anymore.

The maintainer quotes from a 2025 report on burnout in open source sound exactly like Silletti's clinicians:

"Some also had a sense of directionlessness and loss of meaning in their OSS work." 8

"It starts feeling less like building and more like running unpaid support for strangers." 9

They're not describing a tank run dry. They're describing a tank running fine ... pointed at nothing.

The Sediment

Silletti's key metaphor is administrative sediment. He writes about how healthcare accumulated non-clinical work over years. Each piece was reasonable on its own. Each piece had its own justification.

Taken individually, none seemed unreasonable. Taken collectively, they have quietly buried the work that gives medicine its meaning under an ever-growing layer of administrative sediment. 10

Open source has its own sediment. And it accumulated the same way. Slowly, without malice, each piece seeming reasonable at the time.

Open source was never just about writing code. Each maintainer will likely have their own why for doing open source, but I think it centers around building. Building a library, building relationships with likeminded people, building understanding.

But it is always about building.

GitHub popularized the idea of social coding. It allowed for strangers to submit issues. Some of those strangers also submitted Pull Requests for those issues. Some people would only do a single issue, or a single PR. Others would stay around, forming a community.

The people that helped to form a community were always outnumbered by those that just stopped in to drop a PR or two. The community members were also outnumbered by those that reported issues. Over time, the people that reported issues went from having a sense of 'just wanted to let you know' to 'you need to fix this now'. And the 'you need to fix this now' crowd feels like it went from being a small percentage of reporters, to a larger percentage.

Maintainers that were simply offering up something for free were suddenly being treated as tech support. Sometimes by large companies that weren't paying for anything.

And so, as an open source maintainer, issue triage for entitled reporters replaced writing code. PR reviews replaced building features. Security patches replaced creative problem-solving. "Community" management replaced technical mentorship. One analysis found that maintainers spend 80% of their time on support and "community" management, and only 20% actually writing code. 11

Nobody did this to us on purpose. Each task arrived with justification. A bug report needs triaging. A contributor needs guidance. A security advisory needs a response. Each one, individually, is the right thing to do.

But here we are. The meaningful work, the building, got buried under the maintenance work. And we called the result burnout.

Then the Slop Showed Up

Suddenly AI slop arrived, and it made everything worse. But not in the way everyone thinks.

The volume numbers look like pure burnout, I'll grant that. AI-generated pull requests take roughly 12 times longer to review than human ones. 12 Daniel Stenberg, the creator of curl, killed their bug bounty program entirely, writing that "the never-ending slop submissions take a serious mental toll ... hampering our will to live." 13 GitHub added PR caps as an emergency measure. 14

But read what maintainers are actually saying. It's not "I'm too tired." It's this, from RedMonk:

"AI slop is ripping up the social contract between maintainers and contributors essential to open source development." 15

The social contract. The relationship.

The thing that made open source maintenance joyful was that someone cared enough about your work to try to improve it. You mentored them. They learned. The code got better. The community grew. That's the social contract.

AI slop doesn't add work. It replaces human connection with mechanized noise.

When the work becomes pointless, when you're closing PR #50 from an agent that couldn't tell you what design patterns your project uses if its "life" depended on it, the question isn't "I need a break."

It's "what's the point?"

That's not burnout. That's languishing. And slop is pouring gasoline on that fire.

Why Our Fixes Aren't Working

Here's where the framing matters. Silletti again:

The solution is one of subtraction, not supplementation. 16

We've been treating open source maintainer distress as a workload problem. And our solutions reflect that:

Pay them. Get more contributors. Add tooling. Build AI triage bots.

But slop is more contributors. AI triage bots just automate the emptiness. GitHub's PR caps reduce the volume but don't restore the meaning.

The yoga class for clinicians is the "pay maintainers" campaign for open source. Both treat symptoms without addressing the core issue: the work itself has lost its meaning.

Silletti proposes a test for healthcare leaders. He says they should ask of every task: does this bring the clinician closer to the patient or further away? 17

Here's my version for open source: does this task bring the maintainer closer to building or further away?

Triage of intentional, well thought out and reported issues? Closer. PR review for a human who wants to learn? Closer. Mentoring a new human contributor? Closer. AI-generated spam? Further.

Is it Burnout or Languishing?

Christina Maslach, the person who literally invented burnout research, I think would push back hard on this whole framing. Her three-dimensional model already includes cynicism (detachment from work) and reduced personal efficacy (loss of belief in your competence). 18 Those overlap heavily with the idea of languishing introduced earlier.

And her Six Areas of Worklife framework lists values as one of the mismatch areas that cause burnout. A values mismatch IS a meaning crisis. 19 So maybe languishing is just burnout without the exhaustion dimension? Maybe the distinction is academic.

The slop numbers are real. Twelve times the review time. DDoS-level volume. When you're drowning in 500 AI-generated PRs, calling it a "meaning crisis" might feel like calling a flood a water quality issue.

I get it. I might be wrong. Maybe Languishing is just Burnout by a different name ... but I don't think so.

Maybe It's Both

I think the truth is exhaustion and emptiness, feeding each other in a loop:

  1. Slop increases the workload. Exhaustion sets in. (Burnout.)

  2. Exhaustion reduces capacity for the meaningful work. Disconnection grows. (Languishing.)

  3. Languishing kills motivation to keep fighting the slop. More slop gets through. Workload increases.

  4. Repeat.

But here's the thing. The intervention matters. If we only treat the burnout side (reduce workload, add tooling, cap PRs), the languishing continues. If we only treat the languishing side (restore purpose, reconnect to meaning), the workload crushes people before the reconnection takes hold.

We need both. But we've been doing neither. We've been doing GitHub Sponsors and calling it done.

The distinction isn't about diagnostic purity. It's about what you reach for first. If you call it burnout, you reach for workload reduction. If you call it languishing, you reach for purpose. The loop needs both interventions. But we've only ever tried one.

What Do We Actually Do?

Silletti's prescription:

They must examine the job itself and identify the sediment of nonclinical tasks. The solution is not to work harder, or faster, or more resiliently through that sediment. The solution is to remove it. 20

For us, that means:

  • Remove the slop. Not just cap it. Reject the premise that all contributions are equal. A PR from someone who understands your codebase is worth a thousand PRs from an agent that doesn't.

  • Protect the social contract. The maintainer-contributor relationship is the meaning. Don't let AI industrialize it into spam.

  • Ask the question of every maintainer task: does this bring you closer to the building or further away? And if it takes you further away ... maybe stop doing it.

I'll be honest. I maintain a few, trivial, open source projects. I'm on the Django Software Foundation board. I'm on the Django Commons admin team. And I've felt this. Not the exhaustion, the emptiness. The mechanical closing of PRs. The realization that I'm going through the motions.

So what do we actually do? Start smaller than a framework. Next PR that lands in your queue, run it through the question above before you touch it: does reviewing this bring you closer to the building21, or further from it? If it's further, close it. Full stop. Do that ten times and you'll know more about your own maintainer practice than any framework could tell you.

And name it correctly. Not burnout, not laziness. Languishing. The tank has gas, we just forgot where we were pointed. Naming it right is the first task on the list, because you can't fix a diagnosis you keep getting wrong.

  1. https://www.medpagetoday.com/opinion/second-opinions/122202 ↩︎
  2. https://www.medpagetoday.com/opinion/second-opinions/122202 ↩︎
  3. https://pmc.ncbi.nlm.nih.gov/articles/PMC4911781/ ↩︎
  4. https://sites.prh.com/languishingbook ↩︎
  5. https://www.nytimes.com/2021/04/19/well/mind/covid-mental-health-languishing.html ↩︎
  6. https://www.medpagetoday.com/opinion/second-opinions/122202 ↩︎
  7. https://www.sonarsource.com/the-2024-tidelift-maintainer-impact-report.pdf ↩︎
  8. https://mirandaheath.website/static/oss_burnout_report_mh_25.pdf ↩︎
  9. https://www.reddit.com/r/opensource/comments/1q76f90/the_maintainer_burnout_is_real_and_it_is_getting/ ↩︎
  10. https://www.medpagetoday.com/opinion/second-opinions/122202 ↩︎
  11. https://medium.com/@sohail_saifii/the-open-source-maintainer-burnout-crisis-nobodys-fixing-5cf4b459a72b ↩︎
  12. https://webmatrices.com/post/vibe-coding-has-a-12x-cost-problem-maintainers-are-done ↩︎
  13. https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ ↩︎
  14. https://www.coderabbit.ai/blog/github-gives-maintainers-a-throttle-for-the-ai-pull-request ↩︎
  15. https://redmonk.com/kholterhoff/2026/02/03/ai-slopageddon-and-the-oss-maintainers/ ↩︎
  16. https://www.medpagetoday.com/opinion/second-opinions/122202 ↩︎
  17. https://www.medpagetoday.com/opinion/second-opinions/122202 ↩︎
  18. https://pmc.ncbi.nlm.nih.gov/articles/PMC4911781/ ↩︎
  19. https://www.demenzemedicinagenerale.net/images/mens-sana/Burnout_Organizational_Predictor.pdf ↩︎
  20. https://www.medpagetoday.com/opinion/second-opinions/122202 ↩︎
  21. keep in mind that building could mean one of many different things, and it's what you think of as building ↩︎

A Giant Pain in the Ass

Content Warning: This is a highly personal post about a cancer diagnosis.

On Feb 16, 2026 I was 'prepping' for a routine colonoscopy that was scheduled for February 17th at about 1pm. For those of you unaware what is involved in 'prepping' don't google it, but just know that your Gastroenterologist wants the 'end' of your GI tract 'clean'

This also involves a lot of not eating. So you can get hangry. Or at least most people do. I had felt something wasn't quite right for a while. Nothing I could really put my finger on, I just didn't feel right. So when it came time for the prep it turned out I wasn't really hungry anyway. I couldn't really eat the weekend before either, and had been having issues sleeping. I was stressed about what my colonoscopy would show. At least subconsciously I was worried.

On the day of my colonoscopy the staff at the office were all really nice. I even got a "First Colonoscopy" sticker!

I was wheeled into the procedure room, introduced to the doctor and told to look at the wall. The next thing I knew I was being wheeled out to the recovery room. I laid there for a few minutes and then I saw my wife Emily. I was still a bit groggy from the anesthesia but I was so happy to see her. It was the best feeling.

She came next to the bed I was laying on and the doctor came over. He let Emily know that she may want to sit down. She said she preferred to stand. The doctor then told me that during the procedure they found a tumor.

You have cancer

I let the phrase sink in ... "You have cancer" ... "I have cancer".

The doctor was not very comfortable delivering this news. You could tell this wasn't the type of thing he was used to doing. Emily even heard him saying "at the other place I don't have to tell patients this".

I think he tried his best to be positive about the diagnosis, but honestly it was a pretty shitty delivery. He kept saying things like "you're young" (at the time I was 47) ... "you're good looking" ... "you're married"

I didn't really understand why any of that mattered.

I have cancer

He then proceeded to let me know that the tumor had likely been there for years, maybe five. Had asked me if I had any symptoms, was there anything that felt off. How could I have not known something was wrong. I have cancer and it's my fault I didn't know sooner.

He also let me know that I'd need to have an ostomoy bag. For the rest of my life.

I have cancer ... that's all I could hear.

I cried. I cried in front of several people that I had never met before. I cried in front of my wife.

I have cancer. And I don't know anything about it at this point other than it seems like everyone I know with colorectal cancer died from it.

I have cancer.

I'm going to die

... those two phrases kept going through my head

I cried.

As an aside, I told a friend of mine how my cancer diagnosis was delivered to me. This friend has had many cancer battles / scares during their life. I figured when I told them my story they would say it wasn't so bad. Turns out it was. Even they were like, "Holy Shit. That's awful!"

After a few minutes, and once Emily and I were a bit more able to see the world, I was wheeled out to our car. We drove home. We didn't say much. What is there to even say? I have cancer.

We got home and although I could eat again, I wasn't hungry. I was afraid I'd never be hungry again.

That night I couldn't sleep. Or the night after. Or the night after.

The next day I had a follow up with a different GI doctor. He was basically like, "There's no new information. Why are you here?"

But we had questions. What are the next steps. Who should we contact? What do we do? The one question I didn't dare ask, "Am I going to die?"

For the next 16 days I lived in the grayest of gray areas. I could barely sleep, or eat. I lost about 8 pounds.

Emily and I spent time working to make sure that all of our affairs were in order. Are all of the banking apps installed on your phone? Do you have all of the passwords? Does the car title need to be updated? The title for the house? How do we do our finances?

We make a good team in that we each have our 'assignments'. We're pretty autonomous in those assignments. We'd talked about "cross training" on some of them, especially the financial stuff, but there just never seemed to be the time.

And now it felt like we didn't have the time but were going to have to make it. I felt like I was writing transition docs for leaving a job. But in this case I was afraid of the job I might be leaving.

To use any other word than brutal to describe these days wouldn't do justice to the way we felt. And even then it doesn't really begin to cover it.

During that time we told a few people. A very few people. Telling people made it real. Telling people was like delivering a trauma to them. Telling people led to questions. Questions we didn't have the answer for. Brutal.

I had nights where I would cry. Especially if I was alone. I have cancer, but there were things that still needed to happen. Emily had a major work event that she was responsible for. She had coworkers and friends she was able to rely on, but that didn't mean she didn't have to do things. Away from home. Away from me.

My Aunt had the same cancer diagnosis I do and she was helpful and caring and loving and kind and all of the things you need from a family member. But she didn't know the future. She didn't know if I was going to die. And so when the words, "You're going to be fine" came from her, they were nice, but hollow. I have cancer. I might die. I am scared.

On March 5th I met with a surgeon. Before meeting with the surgeon I needed to have an Abdominal CT scan done. It was completed about a week before I met with the surgeon. I had the results 2 days before meeting with the surgeon. I couldn't look at them. I didn't want to look at them.

The day of the surgery consult came. He was going to tell me the next steps. From what I heard surgery was likely to be my next step. My wife and I went to the appointment, she's been going to all of my appointments with me.

The staff were so nice and friendly and helpful. I started in one exam room and was moved to another exam room. My first thought was, "Oh no, was I in the 'you're going to be fine room' and got moved to the 'You're going to die' room? But the nurse let me know the reason for the move. A simple reason. No big deal. Except it was. It was the biggest deal. But she took the time to let me know the why of the move.

I went through the exam. Emily came back so the surgeon could talk to us.

All of the fear, and horrible anticipation. What ever he said next we were going to work through it. We were going to figure it out.

At the end of all of this, "we" might end up being just "she".

And the doctor said ...

It's actually not bad. We seem to have caught it early. We'll want to do chemo and radiation before reevaluating surgery.

I cried. This time I cried because it was the first hope I'd had in almost 3 weeks. I cried because my birthday was in 2 days and I had friends I was going to hang out with and it will be an actual happy party and not a pre wake party.

Since the surgeon I've seen a few more doctors. An oncologist and a radiation oncologist. Each appointment was mostly what one might expect. A brief conversation about potential side effects of the treatment. Which are pretty horrific if you think about them for too long. I try not to.

My treatment will be 5 days a week for 5 1/2 weeks of radiation and chemotherapy. Reevaluation of the tumor for potential surgery 6 - 12 weeks after that.

I'm sleeping better, but still not great. I eating better, but still not a ton.

And then ... for a few weeks ... nothing. Paper work is getting processed and I'm waiting for an MRI. The important part about the MRI is that it will tell me what stage and grade my tumor is. Once that's completed and the results are read then all of the doctors will have what they need to allow me to officially begin my treatment.

That being said, I have a tentative start date for my treatment. Unless my MRI shows something unexpected, I'll start my radiation and chemotherapy treatments on April 13. Officially. Fifty Five days from when I was told I had cancer to start of treatment. I'm not sure if this is a long time or not. It felt like a long time. A really long fucking time.

As part of the treatment you go in for a prep session. During this session they fit you for the device that blasts your tumor with radiation. In my case they also gave me 3 tattoos. One on either side and one right below my belly button.

I always thought my first tattoo would be of something way cooler 🤷🏻‍♂️

Before my diagnosis I had some plans for this year. I was going to go to PyCon US, PyOhio, and DjangoCon US. I even toyed with the idea of going to North Bay Python.

I won't be able to do any of these. Although my treatment will be done by late May, I'm not sure I can commit to much travel. I'm not sure how I'll be feeling.

Also, anywhere from 6 - 12 weeks after the end of my treatment I get re-evaluated for surgery. If the tumor is gone and the various docs feel like there's no risk, then surgery might not be required. If there is a risk, then surgery will be required.

The outcome of the surgery will be a colostomy bag that is either temporary (about 6 months) or permanent.

I'm less than 2 months into my cancer journey and there's still so much I don't know. Still so much that just can't be known. And honestly that's the hardest part.

My prognosis is good. My family and I are optimistic. But there's still so much we can't know. We hope that this will be a 'blip' and that by 2027 or 2028 we can go back to what ever normal is. But we just can't know.

One of the things I've really focused on over the last 2 months is trying to find the good things. I saw someone post on Mastodon (sorry, I can't find the original toot) about finding what they called glimmers. Those small things that make you happy.

I try to do that every day. A song I haven't heard in a long time. A friendly face while I'm out and about. A text from a person I haven't heard from in a while. Going for a swim. These are all things that I was taking for granted. I will likely end up taking them for granted again. But for now, I am really trying to be more appreciative of them. I'm trying to be more present.

Anyway, for those of you out there in that are 45+ and haven't gotten a colonoscopy. You should. We seem to have caught this early in the process. My prognosis is good. If someone hadn't told me I had cancer I would mostly have no idea.

Year in Review 2025

I was hoping to have this written and posted last week, but for Christmas this year Santa brought me a cold which knocked me on my butt for a few days.

I had done a bit of prep, but wow, when I look back at 2025 it was a pretty big year for me personally.

Professional

I celebrated 17 years at my current employer. While this isn't a nice round number sort of anniversary, about 6 months before the actual anniversary date I was promoted to an Associated Vice President and joined the Senior Management Team. This has been a goal of mine since about 2010 and after a lot of hard work (and honestly more than a bit of good luck) I "made it".

In addition to the promotion at work, I also helped to lead a multi department team to a successful upgrade for a major application AND helped to lead a major network migration for our EHR that went really well. Two major projects accomplished in the same calendar year was a pretty good feeling.

We also do annual employee satisfaction surveys and my department had a 96% satisfaction rating. This is a really good feeling as a leader. We get shit done AND people are happy to do it!

Since 2021 my department has consistently scored above 90%. This isn't just me though! I have a great management team that helps to make this happen.

Over this same time period I've had 7 people leave the department1. Five of them because of retirement. I really like that where I work is a place you retire at more often than not! That, along with the high satisfaction rates, suggest that my management team and I are doing something right.

Django and Python

On the Django and Python side it was also a really big year. In February I spoke at PyCascades in Portland, Oregon.

In September I spoke at DjangoCon US in Chicago, Illinois. This was my THIRD talk at DjangoCon US2

I was also active with Django Commons on the admin team, was a Djangonaut.Space Navigator in Session 5 for 2 amazing Djangonauts, and got to hang out at Jeff's Office Hours pretty consistently (though not as often as I would have liked!)

The biggest accomplishment was getting elected to the DSF Board and then being elected Treasurer of the Board. This is still all very new and I'm trying to feel my way around, but I've got some amazing support and I'm really looking forward to working with the board in 2026 and beyond.

Technology

A few weeks ago I watched Jeff Triplet migrate various infrastructure for DjangoPackages.org from Digital Ocean to Hetzner with Coolify. This got me to dive into that ... pretty deeply. I spent a lot of my December PTO3 working to migrate my servers from Digital Ocean to Hetzner managed with Coolify. I plan to write more about that later, but needless to say, as of December 29, 2025 I had successfully migrated everything off Digital Ocean to Hetzner.

Personal

Music

Watching live music is a lot of fun. My wife Emily and I really enjoy doing this. We didn't get to see as many concerts as we would have liked to, but we were still able to see a few. Kelsea Ballerini (with our daughter Abby) and Benson Boone at Crypto.com arena in Downtown Los Angeles, Sessanta at Acrisure Arena, Third Eye Blind4 at a local casino, a show at the Grand Ole Opry in Nashville, Tennessee as part of a conference I attended. We also saw about 5 or 6 different bands in 3 days at different venues while we were in Nashville (though sadly we didn't get to see a show on the stage at the Taco Bell Cantina which feels like a real miss!) though we did get to see The Steel Drivers at the historic Ryman Auditorium

We also saw Post Modern Jukebox at the Fox Theater in Riverside. We stayed a few days to get out of the heat of the Coachella Valley, but were shocked to learn that Riverside is only about 15-20 degrees cooler. And when it's 115-120 here it can still be above 100 there!

We still had a great time and it convinced me even more that the wild idea my friend Mario and I had to pitch Riverside as a location for DjangoCon US 2027/2028 was actually a really good idea, not just a wild idea 😀

Hockey

I went to a ton of hockey games. To start the year off I went to the Cactus Cup and saw 4 NCAA Division 1 games in 2 days. The best part was sitting behind the goal right at the glass and seeing just how fast (and LOUD) the game can be.

Teddy Bear Toss 2025

I was pretty exhausted (but happy) by the end of it.

I also got to see 36 Firebirds home games (regular season5 and post season6), 2 Firebirds road games (both in San Diego against the Gulls), and was able to attend the AHL All Star Competition at Acrisure Arena in February.

On the NHL front I went to a game to watch the LA Kings host the Seattle Kraken (the Firebirds big kid club) and while I was in Nashville for a conference in November I got to watch the Nashville Predators play the Calgary Flames.

My favorite hockey-related experiences this year though were the Teddy Bear Toss game (even though the Firebirds lost) and getting to greet the players in the tunnel before the game

Teddy Bear Toss 2025

Baseball

Sadly we only made it out to a few baseball games this year. We saw a few California Winter League games one Saturday in February, and one game out in Rancho Cucamungo to see the Dodgers Low A Affiliate the Quakes play. The Dodgers won the World Series, and that was nice, but I didn't see any of their games in person this year.

Family

This year Abby started her second year of College so Emily and I continue to be empty nesters most of the year7

One of my favorite highlights from the year include Abby coming home from college for the weekend for my birthday last March to surprise me. A completely unexpected visit that literally made it one of the best birthdays ever. I read something earlier this year that once your child leaves your home for college, or whatever, they'll have spent about 95% of the time they're EVER going to spend with you. This hit me pretty hard. Like wanting to sob uncontrollably hard. So for Abby to come home to spend time with me for my birthday was the best gift ever.

Conclusion

Looking back it was a pretty great year. Lots of accomplishments, lots of great memories. The year started off with lots of fear and trepidation. I still have that (in spades) but I also am starting to have a bit more hope.

I don't have any lofty goals, and I didn't do the same kind of Theme planning that I've done in the past. This year it just didn't really work for me, so I'm pausing on that exercise.

That being said, if I was going to have a theme for 2026 it would be 'The year of Intentionality'. I've spent more time this year than I would have liked doing things but not thinking about what I wanted to do. I just did them because they were easy or it's just what I always do. For the last few weeks I've been trying (with varying degrees of success) to be more intentional in my actions, and my plan is to continue that into 2026.

Here's hoping to a great 2026!

  1. The department is 13 people ↩︎
  2. DCUS 2023, DCUS 2024 ↩︎
  3. Paid Time Off / Vacation ↩︎
  4. yes, they are still a band ... no this was not my idea! ↩︎
  5. This includes games for the 2024-25 and 2025-26 season ↩︎
  6. just 2025, obviously ↩︎
  7. I might just be misremembering, but when I was in college we didn't have this many breaks, and they weren't this long! ↩︎

Migrating to Raindrop.io

With the announced demise of Pocket by Mozilla I needed to migrate all of my saved articles to 'something else' by the end of the month. I've actually tried to migrate from Pocket a few times over the years. I landed on Instapaper for a while, but it never really clicked for me. I tried a service called Devmarks that Adam G Hill runs, and I really liked it, but for whatever reason I stopped using it. I had also previously tried Raindrop.io ... and I'm not really sure what drove me away from it, but it didn't stick for me at the time.

Since I didn't have a choice about Pocket I did a bit of purusing my options, and finally landed on Raindrop.io again. The process of migration is pretty painless. I just export out the links from Pocket and then import them into Raindrop. No fuss ... no muss. Raindrop even checks for duplicates and allows you to not import them!

So, I imported everything (all 11,500+ articles!) and started to incorporate Raindrop into my workflow. This basically just means saving things to Raindrop instead of pocket, and then checking Raindrop instead of Pocket every week to make sure I'm all caught up on my articles to read.

Over the last weekend I was looking at how all of the imported items in Raindrop were put into the 'archive' collection and decided that I could probably do something about putting them into proper collections.

With the help of Claude Code, I was able to put them into better collections. There were some stragglers and I decided that I could categorize them on my own (there were less than 100).

I started going through these last ones I kept coming across articles for iOS7, or an app that I think I liked in 2015 but isn't on the App store anymore. I came across this article (which I also tooted about on Mastadon) from September 4, 2014 with the title What the Internet of Things Will Look Like in 2025 (Infographic). It's wildly naive, but a fun read nonetheless.

Needless to say it was the only gem in the 100 articles that I went through. I had so many saved articles that aren't 'Evergreen'. I then started looking at some of the articles that had been categorized and came across stuff for Django 1.11, Python 3.8, and other older stuff.

These were great articles when I read them, but I don't know that I need them now. In fact, when I looked at my general workflow for using any read-it-later service, I essentially save it to read later. If it's sitting in my read-it-later service for more than 4 weeks I'll either delete or just archive it.

So really, unless I'm planning on doing something with these articles, I'm not sure that I need to keep them. And that's when it hit me ... I can just delete them. All of them. I don't need to keep them. If they are truly impactful, I can write up something about them in Obsidian. If I really think someone else will get something out of my reaction I can write it up and post it. But, if I'm being honest with myself, this is just digital clutter that isn't "sparking" any joy for me.

So, just like that, I went from having 11,000+ links to having 0. And I have no ragrets.

I'm sure there's some deeper story here about physical things and just letting them go as well, and maybe I'll be able to apply that to my non-digital life, but for now, I'm just going to revel in the fact that I was able to offload this thing and just not ... care? Be sad? I'm not sure what the correct term would be here.

Regardless, it was a good exercise to have gone through, and I'm glad I did.

A New Project at Work

I was added to a work email that was requesting a not-so-small new project that was going to need to be completed. The problem that needed to be solved was a bit squishy, but it had been well thought out, and it had an importance to it that was easy to see.

There was still some workflows and data that needed to be reviewed, but overall it was on a good path to having a real project feel to it.

One question still outstanding is, what platform will this project be implemented on? In our EHR, or on a separate web app?

During my weekly project review meeting with the Web Development team I let them know about the potential for this new project and that it would likely need to take priority over one of our current projects. The start is still a couple of weeks away so we have time to plan for it (as much as we can anyway). We looked at the project board and determined a ranking of the current projects. We decided on the project that would likely get bumped if this new one ends up with the web developers. And just like that we had a contingency plan for how to plan for this project given our current constraints.

Now, this project may never make its way to the web development team, but having that conversation with the manager, and then during our standup today, to let the team know that this might be something that will need to be worked on by them felt right. No surprises in a few weeks. No randomness about what projects we'll be working on ... just a bit of planning to prepare for something that might never come.

Eisenhower said, "Plans are nothing, planning is everything."

The team appreciated being in the loop about a potential project and being able to align expectations moving forward. I felt grateful that this was brought to my attention well before it was submitted as a request. The requester now has a bit more information on who to speak with internally, and it really felt like we were working together to solve a problem in a very professional way.

I wish all projects started like this. It would make life way easier and not so much like this

Firebirds 2024-25 Season

The 2024-25 season for the Coachella Valley Firebirds ended on May 9th with a 2-0 loss to the Abbotsford Canucks. Overall, that series saw the Firebirds score

This isn't surprising given exactly how young the Firebirds were this season, but it was disappointing.

Coach Laxdal talked a lot about how young the team was and how on any given night we would have anywhere from seven to nine rookies that were in the starting lineup. And in a team of 24, that's a pretty big portion of guys out there who are very young.

That being said the disappointment is palpable the this is the earliest that the Firebirds have ever exited the postseason. Granted this is only their third year but we are typically used to seeing hockey for another seven weeks. When put into that perspective, it is really disappointing.

Still, I think there were some really bright spots from this year, including Leyton Roed, Jani Nyman, Nikke Kokko, Ryan Winterton, and Ty Nelson.

At the start of the season, I did indicate to a friend of mine (who also has season tickets) that I had pretty low expectations for the Firebirds and may have even indicated I wasn't sure that they would make the playoffs. The Pacific Division has 10 teams and 7 of them make the playoffs. I may have been a bit too pesimisitic in that analysis.

During the first round the Firebirds swept the Wrangerls 2-0. This is great, but they did manage to blow a 3-0 lead in game 1. The were able to win that game, but it took two plus Overtime periods (it ended a few minutes into the third OT).

Game two of that series did see the Firebirds win 2-0 with Nikke Kokko getting his first professional AHL shutout, which was great . But it's also a bummer that it took until the 74th game of the season for him to get his first shutout of the season. 1

In six games, the Firebirds were 3-3. They scored four goals, two goals, one goal, five goals, one goal, and no goals. They were 0-17 on the power play, and they gave up two, count them two, 3 goal leads.

Needless to say, this was just a hard set of games to watch. The season was hard to watch as a fan. The Firebirds would find ways to lose games. In previous seasons these were the games that they would find some way to win!

There was an article in the Desert Sun that spoke about how proud Coach Laxdal was of the players and how much effort that they gave. And I agree, they did give a lot of effort and he spoke about how young they are.

And again, they are young, and missed their captain Max McCormick for basically two thirds of the season. But they did have some veteran players out there Mitchell Stephens, Brandon Biro, Cale Fleury and Gustav Olofsson. Unfortunately it was just too much to try and overcome.

One of the things that Coach Laxdal also commented on was exactly how much younger next year's team might be. And so while I am again very excited about watching hockey in six months, which is just so long away. I am lowering my expectations for the 25-26 season even lower than they were this year. I'm really hoping we make the playoffs, but won't be surprised if we don't.

And that's going to be okay ... because even bad hockey is still hockey. And I love hockey, and even when they lose, I love watching the Firebirds.

  1. During the regular season, there was exactly one shutout by Victor Ostman ↩︎

The Invisible Decision-Makers: Why Systems Ignore Their Users

The Origin of Systems

When thinking about systems it's easy to think that they have always been there, or been that way. This isn't true of course. The systems that are in place were put there, by people. People that made decisions. Decisions are what I want to focus on here.

In general when making a decision about the implementation of a system you would want to engage with the stakeholders of that system. This of course implies that you can identify at least some of those stakeholders.

But sometimes there aren't any key stakeholders other than regulations, or best practice, or some other nebulous thing that needs to be met. These are the decisions I really want to focus on.

The Illusion of Success

Take a security system for instance. The basic tenets of the security system are that it keeps 'something' safe. If the thing to be kept safe is still safe after the implementation of the security system then the people that implemented the system can claim success. They can look at the evidence that since the security system was put into place the thing has been kept safe.

Of course, it's entirely possible that the thing was never in danger, and that the previous system was doing just fine. In fact, it could be that the security system is actually making it harder to keep the thing safe. It's just harder to see because all you're looking at are potentially meaningless metrics like. Questions like is the thing safe after implementation of the security system don't take into account if the thing was 'unsafe' before? This can lead you to think that the new security system must be responsible for the safety of the thing.

Something else that can be happening is that the security system has caused the people responsible for keeping the thing safe to work more hours, hire more people,who are oftentimes keeping the security system running.

Questioning Purpose

The more we look into a system like this, the more we might ask, "Why is it there?"

There can be a couple of reasons, but I'll focus on one in particular. The person ultimately responsible for keeping the thing safe can show with some kind of metrics that the thing is safe with the new security system, whereas they couldn't under the previous system. There weren't any reports or metrics that showed what was going on, which is why the system was implemented in the first place.

OK ... so that's how some systems can be put in place.

User-Hostile Systems

What about systems that are hard to use, or maybe actively hostile to their users? How do those get put into place? I would argue that the reason we see many user hostile systems in place is because they are decided upon not by their users, but by their ability to meet regulations, AND their ability to maintain by a support system. The consideration of the user is secondary, or maybe not even thought about.

Think about any Enterprise software you've ever encountered. Would you say that it was a joy to use? Would you say that onboarding was simple, and that new employees loved to use it? My guess would be no.

Why Bad Systems Persist

So if the users don't like it, why is it in place? Two reasons:

  1. It meets some kind of regulation (this could be a government regulation, but it could also be a regulation of a guild, or union, or something else)
  2. It's easy to maintain by the support system

For any software that meets these criteria you are likely to have users that don't like the software, because they are always an afterthought. The primary responsibility of the software developers of these types of systems is always the regulators, and the support infrastructure.

The first because they have to keep producing software that is compliant in order to be sold with a specific rating or seal of approval.

The second because if the support team can't easily support it, they're going to find an alternative solution that they can support.

Conclusion

It's a simple decision of maximizing for the people that enforce the rules (regulators) and that make the decisions (support). The users of the software don't matter. At all.

This is why you will see software for widget processing that could benefit from bulk operations, keyboard shortcuts, or being browser agnostic and they just aren't. The only considerations are: Does it meet the regulations? Is it easy to support? If the answers are yes then the users tend to lose out. They don't matter. If the answer is no, then find a competitor that does and move over to them, even if the current system is loved by your users.

Technical Solutions to People Problems

"If you think technology will solve your problems, you don't understand technology and you don't understand your problems"

~ attrib. Laurie Anderson

From a Toot by Jake Rayson

In a previous post, I wrote about how to ask why without sounding like a jerk. This is a slightly related concept (at least in my head).

Sometimes, as technical people, we are asked to solve problems. The more we dig into them, the more we discover that the problem that needs to be solved isn't a technical one but a people one. In many cases, it's just getting two groups to actually talk to one another.

This can be hard and awkward, so people may want to avoid it. Creating a report telling someone they're doing something wrong is way easier. No hurt feelings! However, I've found that the approach tends to create more problems than it solves.

The situation

The situation is a real one, and I'm obfuscating details to help 'protect the innocent'.

At the start of each year, large amounts of new data are needed to be added to a system. The additions are, by their nature, very manual1 and so the team responsible for them spends much of their time trying to get the data added.

Another team is highly dependent on this new data being added in order to process their widgets2. The widgets get loaded into the system and checked to see if the data from team A is complete. If it isn't, then the widget gets flagged. This flag directs the members of Team B to reach out to Team A to get clarification on the state of the data needed to process the widget.

Only, that's not how Team A understands it. While they are furiously trying to update data, there is some basic data that covers roughly 80% of the widget processing data needs that are already available. So, the vast majority of the time, there is no need for Team B to reach out to Team A because the information they need is available in the system to process the widget.

This understanding was either lost or never communicated effectively so Team B would just email Team A with questions about the widget data and then get their answer and move on. This is despite the fact that the information is available in the system for the members of Team B to review!

The leader of Team A asked me if I could 'update a report' to 'remove some of these widgets so Team A could better focus on the work of adding the data'.

I thought that seemed reasonable, so I asked Team B a few questions and then made a bit more discoveries and found out the actual problem, which was that the information needed by Team B was in the system. Team A just needed Team B to do a better job of looking for it and asking questions about the things that were needed instead of everything.

The Solution

I proposed that the leaders from Team A and Team B get together to talk about the issue.

At the meeting, the leader of Team B was horrified to hear what was happening. They had no idea that many emails were going to Team A about questions that the members of Team B should be able to answer on their own.

This is all well and good, but why did it take a tech person to spot this and get the team leadership together to figure it out?

I wish I knew the answer. I think part of the insight I had was the current pipeline of work, how long it was going to create a report, and the need to have the problem solved sooner rather than later didn't line up. At all.

I needed to look for a potential non-technical solution. The other thing that I think happened here is that I wasn't weighed down by any history of interactions between the Teams. I was just trying to gather information. In gathering information I was able to see what the real problem was and that the only solution that made sense was for the two teams to just talk to each other.

The Outcome

During the meeting, Team B committed to retraining staff and helping to make sure that they only reached out when there was an actual question about the data for the widget production. Team A was thrilled with this solution, and now they can focus on getting the data into the system more efficiently and with fewer interruptions. A win-win, all because a tech guy got some non-tech people to talk to one another.

  1. yes I would like to automate this, but one step at a time! ↩︎
  2. Not actually widgets ↩︎

How to Watch a Hockey Game - Reading the Standings

This is the fourth part of my How to Watch a Hockey Game Series. You can catch up on previous articles here

Game Outcomes

In many North American sports when reading the standings there are typically just Wins (W), and Losses (L).1

Hockey is a bit different. When you look at the standings for Hockey you'll see 4 headers:

  • W: Wins
  • L: Losses
  • OTL: Overtime Losses
  • SOL: Shootout Losses

As discussed earlier in this series, if a game is tied at the end of regulation, a five-minute overtime period is played. If either team scores during this Overtime period then the winning team gets a Win, while the losing team gets an Overtime Loss (OTL).

If they're still tied then a Shootout is played. Once a winner is declared in the Shootout they get the Win, while the losing team gets a Shootout Loss.

Because of this, values are assigned to each type of outcome:

Outcome Points
Win 2
Loss 0
OTL 1
SOL 1

This might best be shown with a concrete example.

A Concrete Example

Let's say that the Coachella Valley Firebirds have played 39 games so far. They have won 21 games and lost 13 games. They've also played in 5 games that went into overtime and lost. Their overtime losses are one (1) in the Overtime period and 4 in Shootouts. Their record would look like this:

Coachella Valley Firebirds: 21-13-1-4

Points Calculation:

  • Wins: 21 × 2 = 42 points
  • OTL: 1 × 1 = 1 point
  • SOL: 4 × 1 = 4 points

Total: 42 + 1 + 4 = 47 points

The Firebirds play in the Pacific Division of the Western Conference, and the standings might look like this:

Team GP W L OTL SOL PTS PCT
Calgary 41 27 13 1 0 55 0.671
Coachella Valley 39 21 13 1 4 47 0.603
Colorado 36 21 11 2 2 46 0.639
Ontario 37 22 13 1 1 46 0.622
San Jose 36 20 13 1 2 43 0.597
Abbotsford 37 20 15 1 1 42 0.568
Tucson 37 19 16 2 0 40 0.541
Bakersfield 35 16 14 4 1 37 0.529
San Diego 37 11 20 4 2 28 0.378
Henderson 39 12 25 2 0 26 0.333

Legend: - GP: Games Played - W: Wins - L: Losses - OTL: Overtime Losses - SOL: Shootout Losses - PTS: Points - PCT: Points Percentage

Winning Percent

There are 2 things to look at in the standings: (1) Total Points, and (2) Winning Percent.

The Total Points we've already spoken about so let's review winning percent.

The winning percent is calculated as the Total Points the team has divided by the total possible points that they could have gotten. The total possible points are calculated as the Games Played x 2 (that is, what are the total number of points that they would have if they won every game they played).

That is

    Winning Percent = Total Points ÷ (Games Played × 2)

For example in the table above, we see that the PCT column for the Firebirds is 0.603. This is calculated by the Points (47) divided by GP x 2 (39 x 2 = 78), that is 47 / 78 = 0.603.

The winning percent allows ranking intra-season when teams haven't played the same number of games. After all games have been played, the rankings are determined by the total number of points a team has.2

Conclusion

You should now be able to parse the standings in a Hockey League and be able to tell how well (or poorly) your team is doing.

This is the end of my series (for now). If there are any other burning questions you have about hockey, reach out to me on Mastodon.

  1. Football also has Ties (T) but they are exceedingly rare and are only ever displayed when the first Tie of the season occurs ↩︎
  2. Depending on the league there are tiebreakers, but that's outside the scope of this article ↩︎

How to Watch a Hockey Game - What to Watch

In a previous post of this series I laid out some basic rules of hockey. In this post I'll hopefully provide some tips on what to watch during your first few hockey games.

What should I 'watch' though?

This is a tough question and depends on if you're watching on TV or in person.

On TV

If you're watching on TV you're limited by whatever the camera and director are showing you. Hopefully they're pretty good at what they do and they'll help to show you what is interesting. You'll also have the benefit of replays. 1

Watching the action on TV will be your best bet. The commentators will do a reasonable job of explaining the play. For some of the best NHL broadcasts you'll want to watch a Canadian feed. This might not be an option depending on where you live, but in general, watching a Canadian feed of a Canadian team will be really helpful.

If, for whatever reason, you're watching an AHL game2 the best broadcasts to watch, in my opinion, are the Lehigh Valley Phantoms called by Bob Rotruck and Cleveland Monsters called by Tony Brown. Each of these is a single broadcaster doing both the color commentary and the play-by-play ... and they honestly get so excited it's hard to NOT get excited with them.

In Person

For your first in person game, just try and follow the puck as best you can. If for whatever reason you can't do that, pick a spot on the ice to concentrate on, preferably near one of the goalies. Which one? The goalie of the team you're not rooting for is a good choice! Then you can just kind of watch the action there.

Keeping in mind the rules start by focusing on just one rule - either icing or offside - for an entire period. Once you feel comfortable recognizing that rule during gameplay, switch your attention to watching for the other rule in the next period. For example, if you spent the first period watching for icing, spend the next period looking for offside plays.

Hopefully after a full game you're able to see them when icing or offside happen. If not, it just means you'll need to come back and try again 😁.

What not to worry about

Hockey is a fast paced game. No, like really fast. Don't worry too much about anything other than watching for the puck, if you can, and trying to pick up icing and offside. You'll see other stoppages in play when a penalty is called. The refs will make hand gestures to indicate the call on the ice and someone will be sent to the box.

Don't worry about whether or not a fight will break out. They don't always, and if they do, each player will be assessed a major penalty and will spend 5+ minutes in the penalty box.

Don't worry too much about learning the positions. The goalie is an obvious one (that's the person with all of the pads, the bigger stick, and the giant, well painted mask in front of the net), but trying to distinguish between a defender and a center ... like just don't worry about it!

Conclusion

Hockey is an amazing sport to watch, whether in person or on TV. It can take a little bit of time to get used to the fast pace, but hopefully this series has given you some tips to enjoy it and understand what's going on.

  1. and refreshments that are much less expensive! ↩︎
  2. home of my beloved Coachella Valley Firebirds ↩︎

Page 1 / 7