22 Dec 25

Fascination Street #16

Writing for the week of December 16, 2025

So, pull on your hair, pull on your pout

Cut the conversation, just open your mouth

Pull on your face, pull on your feet

And let’s hit opening time down on Fascination Street

Pulling on my head and getting back to some writing. It’s been a while since I’ve written a post. I’ve had some ideas, but they have all been more long-form writing that I am currently working on. Or won’t ever write.

This is going to be more like a pizza with a crazy list of toppings. Some of which might sound tasty together. Others are so disparate that they really need to be separated per slice. Either way, let’s bake this thing.

First, my wife and I went to see Shows Of A Lost World on Sunday. For those unfamiliar, The Cure played their new album in its entirety a year or so ago in London. They filmed it and this past weekend it showed in theaters around the United States. I’ve been watching Cure concert footage since the release of Trilogy. I’ve purchased it. It sits in Apple TV, and I watch it pretty regularly. Especially around the holidays, when things have slowed down, and I have more time. My wife and I went to the theater when we lived in Portland to see the 40th Anniversary film. It’s not the same experience as being at the show, but these films show a different side of the band that you don’t always catch staring at a stage, singing along. I loved it. I can’t wait to purchase a copy so I can watch it over and over.

Next up, I’ve started writing out a Software Development Lifecycle process using the analogy of throwing a party and serving a cake. I’ll post it as a long-form piece when it is “good enough”. I’m not writing it as a book. It’ll be a longer post that teams can share and digest. I’ve been on too many teams that have a hard time understanding the flow, who fits in where, and getting to a shared understanding of what happens when. And finally, having a recipe to bake the cake before a single line of code is written. The goal is to make things clear for software devs, product folks, marketing, etc….

I’ve started another art project. I’m really getting back into graphite on paper. Photo realism has always been my art project of choice. It feels very “offline” and I’m enjoying it.

Non-art related. On the Rust Language front, it looks like Yew isn’t dead after all. I’ve used Yew in the past and liked it; granted, some of the newer Rust web frameworks seem to have more traction.

Speaking of traction, I’m reading Indistractable by Nir Eyal. It’s not just about social media stealing our time and attention. It’s more about internal triggers and how we can escape the pull of distraction by putting things that attract us to our goals in place. He calls it traction, which is right, but I am having a hard time not reading it as attraction.

On the Rails front, it’s awesome to see the documentation getting some fresh writing. I’m planning on going through these and helping. I remember reading these often when I was starting out with Rails.

Another Rust project that has my interest besides Iggy is Fory. I remember working with a number of serialization formats with Flash a long time ago. It had a binary format we used to make async calls, if I remember correctly. It’s been a long time, and obviously, the same ideas have transferred to the web, especially with JavaScript. Will Fory be more widely adopted than BSON?

On the AI front, I had a fun time trying to get Gemini to fix an issue I was having on an existing codebase. I had a spec that was failing. It involved a file attachment. Gemini went down this rabbit hole, assuming something was causing the file attachment to fail. It was looking at environment settings, trying to comment out authentication, etc…. It was missing that the Factory was only building, not creating. If you understand what that means and how simple it is, it’s an example of an AI not being all that helpful. I’m not anti-AI; I was using Gemini and Claude after all, but it demonstrates you still need an engineer most of the time. And I 100% agree with Simon on his post related to using AI as a software developer.

Lastly, and really what prompted me to write another post was Will Larson’s post about getting back into coding at work. I’ve always tried to be a hands-on manager. I didn’t want to atrophy my skills. Some positions and teams made that harder than others. At Nike, it was difficult. Especially when I had more than 20 direct reports. I stayed more involved in architecture than actually coding. But in every other position, I’ve managed to do coding. I like to build things. Writing code interests me. I always find that being a little more intimately involved with the codebase helps me be a good representative of the team. A manager is a representative of the team, right? I digress. Will mentions this point as well and has the realization that it is usually only at a superficial level if you are just looking at PRs and not actually contributing. I agree and relate to this.

I liked a lot of Will’s points, especially a sentence about what managers do in place of coding: “Similarly, if I spent time improving our plans, that would have a higher impact than me writing a piece of software.” I relate to this a lot. On many of these teams I have managed, running down details, coordinating with other teams, and spelling out the details kept the team organized so they could write the code. I’m a big believer in managers being in place to enable their teams to ship. Whether that is hiring another team member, or just sharing credentials in a 1Password vault. Small details that have a high impact.

Will makes a really interesting point: “Each hour I spent writing software was bad for the business overall, and a sign of questionable judgment.” I think this depends on the situation and team. If the team is small and everyone else’s plate is full, figuring out and fixing a bug in the CI/CD pipeline is not bad for the business; it unblocks the team. But I’m not nitpicking, I understand his point and have felt the same in the past.

I relate and agree with his entire post. I’ve been a hands-on manager who contributes code, and I’ve been a manager of managers where it didn’t make sense to write any code. I highlighted the following sentence in his post that I think sums it all up: “Whether manager coding is valuable comes down to whether you believe making large decisions more quickly with fewer interrupts for context pulling–and the ability to make numerous small decisions that are otherwise too expensive to make effectively–builds into meaningfully more impactful management.”

If you’re a manager, I highly suggest reading the post and thinking about what you relate to and what you do not.

▧ ▧ ▧

Links

▧ ▧ ▧

Music

▧ ▧ ▧

A couple of promotions each week. First, use my invite link to try Warp as your terminal. It’s fast and has some great features. I’m not affiliated with them at all, just really like it. Also, check out my project–Schemabook, especially if you work in an organization that wants to get organized around defining data through contracts and collaboration. Lastly, I’m writing a book about learning Rust if you are familiar with Ruby. Stay tuned. As always, you can connect with me more at https://mikekrisher.com.