Ash Furrow's Blog

Five Years in New Brunswick

Fri, 31 Oct 2025 00:00:00 GMT

Today marks five years since my wife and I moved away from New York and back to New Brunswick. When I wrote about this last time, I seemed unhappy. I guess things hadn't worked out the way that I had envisioned them when we moved home – even if I didn't have a really clear vision for how things would go. I have a more optimistic view now.

About a year ago, I started taking photos again. It started on my phone, but then I got out my old film cameras which still had film in them from New York. I finished the rolls and sent them off to be developed. When they came back, I found this:

This is a double exposuree, with half the frame being taken in New York and the other half being taken here in Fredericton. Five years apart! From what I can piece together, what happened is:

I took a photo in New York.
Five years pass.
At some point, the "double exposure" lever on my camera was activated.
I advanced only halfway to the next frame.
I took another photo in Fredericton.

That's what I've pieced together, because this was not what I intended when I took either photo. One of the last photos I took in New York, and one of the first photos I took in Fredericton. This was not what I envisioned. (I also have no idea why one of the photos was taken upside down! What!?)

Something I love about film photography – and digital, too – is the unexpected. In photography, you see a scene and you pre-visualize the shot, and then you try to realize your photographic vision. But unexpected things happen. And I think good photographers are open to that spontaneity. You can't always faithfully execute on your vision, but you can choose to work with whatever happens.

In this case, I've edited the photo to look good. Without those edits, the original was kind of bleh:

This is not what I envisioned, but I love what I made of it. This is probably my favourite photo that I've ever taken ever, and it was an accident.

Things haven't gone the way I intended when I moved home, but that's okay. Part of being human is accepting the spontaneity of life and making something beautiful with it.

Joining Wealthsimple

Tue, 14 Oct 2025 00:00:00 GMT

I'm excited to announce that today is my first day working at Wealthsimple! I'll be working as a staff developer on their mobile app. In a previous blog post, I teased that this role was a perfect fit for me. Today, I'm excited to share some details.

But first we need some context and a little background on React Native.

I started working with React Native at Artsy. Orta and Eloy were keen on adopting it in 2016, but I was very skeptical. So skeptical, in fact, that I found myself working on non-mobile Artsy projects. That's when I learned React on the web, and that's when I came around to React Native. I got on board with the vision that the two of them had started building. I started contributing to that vision and eventually I worked up to leading the team that owned the whole app.

One of the foundational principles that Orta and Eloy had established was that Artsy wouldn't use React Native where it led to a worse user experience; we'd use React Native only where it made sense, and use native iOS tech where it made sense. Our goal was to create a great app, and React Native couldn't do that on its own. As a concrete example, the navigation stack itself was still in Objective-C (while the view controllers were slowly migrated to React Native).

That was (gosh) nearly a decade ago. React Native itself has gotten much better, especially as tools like Expo have taken off. It's now easy for developers to access underlying native SDKs from JavaScript (like photo pickers, Spotlight integration, even augmented reality). But! There still remains a "last mile" in React Native, where native technologies must be used directly in order to build the best user experience. In 2016, maybe you could get 70% to a great UX in React Native alone. By 2020, maybe that had reached 90%. Today, maybe it's around 95%, or so? But I don't believe it will ever reach 100% for two reasons.

First is the platform vendors themselves. Apple and Google develop their own SDKs for building apps and would prefer you to use them. Now, React Native uses those SDKs under the hood, but React Native itself doesn't fit in certain restrictive runtimes. Take widgets, for example. Or push notification extensions, or smartwatch apps, or any number of the small-but-deeply-integrated features that elevate an app from good to great. (Even where it's possible to fit a React Native runtime into these environments, you might not actually want to. I helped a team at Shopify build an App Clip in React Native; App Clips needed to archive down to under 10MB and fitting inside that constraint was a huge challenge. While the project was a technical success, the user experience wasn't great.)

Second is the irreducible complexity of a cross-platform development tool like React Native. This kind of tool needs to work across all kinds of platforms while not feeling like a "lowest common denominator." The React Native project itself has made a lot of improvements here over the years. In case you weren't aware, please let me blow your mind: there is now synchronous, two-way interoperability between React Native's JavaScript runtime and native code. JavaScript can now communicate directly with native code through object references 🤯 This has come a long way since React Native's original, asynchronous bridge where all communication was serialized over JSON. This advancement has led to huge performance gains that close the distance on that last mile – even if it can't close it entirely.

However. This fancy new architecture comes with added complexity. You don't get end-to-end type-safe memory access between TypeScript and native runtimes without at least a little bit of C++. Any app developer who's serious about delivering the highest-possible quality mobile user experience will need to dive under React Native's JavaScript exterior and work in the underlying native stack, in C++, Swift, Kotlin... whatever it takes.

That's where I come in.

It's very rare to find a developer who is comfortable in both React Native and the underlying native SDKs. Mobile native developers tend to avoid React Native. On the other side, React Native developers tend to want to stay in JavaScript, avoiding native tech. There are exceptionally few developers out there with deep enough experience with native iOS that they could still write manual-retain-release Objective-C and who have extensive experience building React Native applications in JavaScript. And who enjoy working in both.

What I have to offer is an unbiased perspective. (Or at least, a less biased one.) Someone to help make the right decision for the product, whether it's native or React Native. Someone who is confident contributing at any level of the stack. And someone to help scale up a larger team with those same skills. I can't wait!

My new role will have a narrower focus with more day-to-day coding and I'm expecting a greater career satisfaction. I've learned that I can do anything, but if I try to do everything, then my work suffers. I suffer. It's time to specialize in mobile UX again.

I'm also really excited to be working in native technologies more often. I've followed every WWDC since I attended my first in 2010, but if I'm being completely honest, it's been hard to feel as immersed as I used to in Apple technology without working in native iOS day-to-day. My Swift skills are a little rusty and my SwiftUI skills... well, let's just say that I'm looking forward to sparring with Xcode again. In some ways, this will be a return to native iOS for me. But I'm not "going back", I'm using my experience to go forward.

I'm really looking forward to ramping up with Wealthsimple. They have a great product for an underserved Canadian market. Their stated culture describes the exact kind of environment where I can do my best work. Also, I've opened personal bank accounts in three countries so I also get to bring my experience banking in the US and Europe. When I moved home to Canada, I was surprised to see how little the big banks had changed in the seven years I lived away. Wealthsimple is pushing Canada forward here. They've built a quality app and have already done a lot to cover that last mile of React Native user experience – I can't wait to pitch in!

Eleventy Launch

Wed, 08 Oct 2025 00:00:00 GMT

As I discussed previously, I've been rewriting this blog in a new tool called 11ty (aka Eleventy - the project's devs aren't consistent so I won't be either). This is the first blog post written in the new blog engine, and the migration is complete!

I already mentioned my reasons for migrating off of Gatsby, but it's worth repeating how much less complex an 11ty implementation is. Gatsby's complexity led to long build times, which started exceeding Netlify's (free tier) deploy timeout. On my M2 MacBook Air, you can see a 16x speedup on fresh builds:

# Gatsby
yarn build  329.83s user 28.18s system 257% cpu 2:19.14 total

# Eleventy
yarn build  57.01s user 4.42s system 387% cpu 15.863 total

I had let the project sit on the back burner for a while but recent events have led me to have spare time to finish it. One of my first priorities was to get Netlify deploy previews working again, which was a great call. This helped me test end-to-end and verify that I would get back continuous (one of the goals of this project). To fully deploy the site from Netlify takes about a minute.

Side note: I don't want to beat up on Gatsby but it's also clear that it hasn't been a good fit. Gatsby is great for complex sites with dynamic content, but this site is a static blog with hundreds of posts. My precious posts! When testing the build times, I saw the following warning:

Your GraphQL query in createPages took 28.522 seconds which is an unexpectedly long time. See https://gatsby.dev/create-pages-performance for tips on how to improve this.

Huh! Okay maybe the performance problems are on my side of the keyboard after all! Maybe I'm holding Gatsby wrong. I examined the query in question, and laughed out loud.

{
  allMdx(sort: { order: DESC, fields: [frontmatter___date, frontmatter___title] }) {
    edges {
      node {
        excerpt(pruneLength: 250)
        body
        id
        frontmatter {
          date
          title
        }
      }
    }
  }
  siteSearchIndex {
    index
  }
}

All it's doing is querying blog posts, which are just text. Even the search index is just processing text. It's all just text! So I'm putting the blame here on Gatsby. I'm left wondering who this tool is for? Gatsby can't scale to under a thousand text files so it's not a good fit for a simple static site. Do you need something more complex? Then you probably want more than a static site, anyway.

Counting lines of code isn't a perfect way to measure complexity, but in this case I think it's helpful for comparing the two implementations. Remember that Gatsby is a React site generated from Markdown using GraphQL with lots of other bells and whistles; more complex but more expressive. The 11ty implementation uses plain HTML, CSS, and JavaScript; simpler but more verbose.

# Gatsby
cloc --exclude-dir=node_modules,public,.netlify,blog,.cache,
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
TypeScript                      50            259             52           3143
Markdown                         6            112              0            616
JavaScript                       2              9             19            207
JSON                             3              0              0            155
CSS                              1             19             10            111
SVG                              6              0              3             93
Text                             2             13              0             61
diff                             1              2             28             24
TOML                             1              0              0              4
-------------------------------------------------------------------------------
SUM:                            72            414            112           4414
-------------------------------------------------------------------------------

# 11ty
cloc --exclude-dir=node_modules,public,.netlify,.husky --not-match-d="blog|fontawesome" .
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
CSS                              7             86             54           1589
Nunjucks                        17             76             17           1239
JavaScript                      10             96            124            619
Markdown                         5             86              0            179
Text                             2             13              0             61
SVG                              3              0              3             48
JSON                             3              0              0             47
TOML                             1              0              0              4
-------------------------------------------------------------------------------
SUM:                            48            357            198           3786
-------------------------------------------------------------------------------

Despite being less expressive, 11ty is still the "smaller" implementation. Which makes sense, since you don't need GraphQL to render markdown into HTML. In any case, I remain impressed at how much can be accomplished using only what we was once called "Dynamic HTML." Gatsby's implementation used 24 dependencies (which get shipped to users reading the blog) and just as many build-time Gatsby plugins. 11ty used only three user dependencies and four build-time plugins. package.json has gone from 118 lines down to just 39.

You might be asking about using plain JavaScript instead of TypeScript. I'm generally in favour of TypeScript, but you don't need to have a full build pipeline to benefit from it. In this project, TypeScript only helps with local development, it doesn't really prevent user-facing bugs. I don't think the tradeoff is worth it, so instead I used JSDoc comments to add types where I though they would help. Everything is a tradeoff, and I wanted the biggest benefit for the smallest complexity. That's why I wrote my own groupBy instead of using lodash.

Overall, implementing the new site went smoothly with one exception. The thing that furstrated me the most was 11ty's Image plugin. This is the most (only?) opinionated part of 11ty's stack. The project clearly wants developers to use new HTML features (like image source sets) to provide multiple resolutions of an image so browsers can choose the best one to display. That makes sense, and Gatsby actually does something similar (albeit using JavaScript). But I just couldn't really wrap my head around the plugin, it kept getting in my way. And due to ~~me being a stubborn ass~~ some hard constraints of my directory structure, I couldn't not use it.

Eventually, I figured it out. Actually it was quite easy, once I started actually using my brain. I had been fighting the Image plugin by proxy, with Claude Code. This is probably a good time to talk about AI.

I mentiond in the last post that Claude Code had accelerated this project. I think it's fair to say I would not have gotten this done if Claude Code hadn't automated some of the most tedious work. But Claude Code was awful at the start of the project; only when I completed the initial project setup myself was it helpful. Maybe I just needed the context to prompt it, but I didn't have that context without building the foundation. Near the end of the project, Claude Code became similarly frustrating, especially as I fought with the Image plugin. Once I ~~lost access to my former employer's Claude Code account~~ decided to valiantly complete the project on my own terms, it became a lot easier. I had to fully read the docs to understand what the Image plugin was trying to accomplish. Half an hour of using my brain was more rewarding and succesful than fighting with Claude Code.

In summary, AI tools seem most useful in the middle of a project. I needed to give them a solid foundation to start from. Simiarly, at the end of the project, they could not polish work to my satisfaction. I think it's also helpful to be able to maintain this project without using AI tools; call me old fashioned, but I want to understand the code. I want to be able to maintain this project even if ~~the AI bubble bursts~~ my internet connection goes down.

You can review the pull request here for insights into my process (ignore the lines-of-code count, as prettier formatted thes blog posts once they were migrated from MDX to markdown).

I've taken pains to make sure the RSS feeds still work as expected, but I always worry about changes that might affect my favourite readers, the RSS nerds. If you see any problems, anywhere on the site, please open an issue.

Work At Your Spikes

Mon, 06 Oct 2025 00:00:00 GMT

I want to discuss my career trajectory and a chronic issue I've identified with my job satisfaction since becoming a staff developer. It's been subtle and I didn't notice it for years. Maybe this will resonate with you.

After a lot of reflection, I've identified a trend in my career direction that started when I first led Artsy's new Mobile Experience team in 2019. It was the perfect role for me, and I crushed it. But it also set me on a path where I would feel unfulfilled with my work. This trend that I've identified has followed me from Artsy to Shopify to Float. But now that I've identified it, I've got a better understanding of where I want my career to go next.

The trend is not working at my "spikes", doing more and more work that is only "okay." Basically, the amount of my day-to-day time that's spent on tasks that aren't a distinguishing strength of mine.

Spikiness

"Spiky" people (also sometimes called "T-Shaped" people) refers to people who have specific areas of professional skill and experience. I'm spiky in mobile UX implementation, for example. Spikes are deep and narrow. Spiky people tend to have gaps, though. These are areas where they have neither the need or interest to improve. One of my gaps is low-level database optimization; it just doesn't interest me and I've never needed to learn it.

You can think of a spiky person as a contrast to a well-rounded person. These two ideas are at either ends of a gamut – no one is "only spiky" or "only well-rounded." But it's a helpful metaphor for professional growth. Spiky people have gaps that well-rounded people don't have, but spiky people can have an outsized impact in their areas of expertise. So it's a tradeoff.

I like being spiky. My spikes have helped me stand out and get opportunities that a more well-rounded version of myself wouldn't get. I prefer to manage my gaps rather than fill them in because filling them in would smooth down my spikes. After all, there is only so much time in a day and you have to choose where to spend your time and energy.

Everything has an opportunity cost. Filling in my gaps would mean less time spent getting even better at my spikes. My spikes are also where my interests lie, so doing work in my gaps is already less interesting. Which would help me more? Spending time getting better at mobile UX implementation, or spending time getting better at low-level database optimization?

There are tradeoffs to being spiky, of course. For example, I need a team to do my best work. Working solo, I can do a good job; working in a team where I can rely on and support others, I can do a great job. I like to work with other spiky people because we help mitigate each other's gaps. A team with a lot of spiky people can accomplish more than a team of generalists, in my experience.

The thing is, though, I haven't been working at my spikes. For a while, I've been generalizing. I've written about how it's good and fun to branch out, and it is! This is not a post against generalizing. But it's about the consequences and tradeoffs. (Spoilers: I've also written about stretching myself out too thin.) I've caught myself accepting that I was a generalist now. I accepted that I wouldn't get to do as much deep work at my spikes – mobile UX implementation – because there were so many other things that my job demanded needed me to do instead.

Side note: a lot of staff/principal developers struggle with letting go of coding as their primary responsibility. At a certain level of seniority, your time is better spent helping your whole team be productive than it is spent on your own productivity. I (and many peers) do struggle with decoupling a sense of accomplishment from a number of pull requests or features built. But this is something different. Because I (and many peers) do find ways to be fulfilled by technical leadership work.

The root of my issue is that I've allowed the needs of my employers to guide my career growth too much. I've become whatever the business needs me to be at the time. To be clear, this has been a successful career! From the business' perspective, it's really handy to have a staff-level mobile developer who can design UI themselves, who can manage their own projects, who can deploy their own microservices, who can even build their own dashboards! That kind of person can jump into any environment and be effective. Businesses love that.

Consider that the Shop Minis SDK that I built didn't have an actual product manager for the first year of its existence. It was just me, organizing the small team of engineers and whatever design capacity we could borrow. Without many resources, I got a lot accomplished. The project was a success even without a PM.

Those other skills, though – design, project management, backend, dashboards – they are not my spikes. I can do them, but... so, uh, the thing is my dashboards are not... exceptional, okay? They're fine, they're good. Dashboards are not a gap for me like database optimization, but they're not a spike either. They sit in-between.

I don't like making dashboards. I find the task tedious. And yet, I've spent more and more time on dashboards over the years. I've had to, to be an effective leader in my different roles. I now have enough "experience in dashboards" that I could credibly list it as a skill on my resume. Ugh.

Upon reflection, I've found myself working further and further away from my spikes in a lot of different ways (not just dashboards). I'm doing many types of work not because I excel in those areas, but because I can be effective working across many areas. And that has been what my employers have needed. When I do get to work at my spikes, my work has still been of high enough quality that I can still get a lot of job satisfaction. The tradeoff has worked for me. Also, it feels amazing to be "the fixer" who can parachute in and help any team do any thing.

But this trend has picked up and the balance has been broken. It led me to not really enjoy my work like I used to. This affected my motivation and the quality of my work.

So what happened?

Early Stage Companies

There are a lot of things I enjoy about working for early-stage startups and one of the my favourite aspects is how you get to own a broad domain. To "wear a lot of hats", so to speak. If you see a problem or opportunity, you get to own the solution. There actually aren't a lot of resources in early companies, so being able to handle a broad range of responsibilities is really important to being successful at a startup.

However, such a resource-constrained setting can make it challenging to advocate for resources you do need. I can understand the business' perspective here: why allocate scarce resources to a team who's already so effective without them? There is a great reason, actually. Artsy's CTO dB once explained to me how startups need more and more engineers year-over-year just to keep shipping at the same velocity. As you build the product, its surface area grows which increases complexity and risk, which require more engineer time to manage. Not every company understands this.

Over time (especially if you don't get more resources as your own surface area grows) you can easily become overstretched. You can get used to being overstretched, spending so little of your time working at your spikes that the time you do get to feels... almost like a chore? Work you once loved can feel like obstacle to doing the work your team needs... like building dashboards. You can lose your own sense of accomplishment and the sense of shared accomplishment that comes from enabling others.

As your motivation drops, the quality of your work drops too. If you a person who is motivated by doing great work, this can easily become a self-reinforcing cycle where lowered quality leads to less motivation and even worse quality. The whole time, you feel worse and worse.

AI and the Push Towards Average

The other factor that accelerated my mid-career malaise was AI. LLM tools have had an impact on baseline expectations for many, many roles in the past few years. They let you "do more with less." It's now pretty easy for anyone to make dashboards almost as good as mine! Despite my years of experience!

It's honestly really frustrating to me. Infuriating! I'm enraged! What is even the point?? If anyone can "vibe chart" then why the fuck am I doing it? AI tools have lifted up the "floor" of dashboard skills which has, in effect, brought me down closer to average. Average! Me! No way.

Now, you could push back here and suggest that maybe I need to use the AI tools to become better at dashboards. Either improve the quality of the dashboards, or build them faster, or whatever. And that would be a fair pushback except I already didn't want to be doing dashboards. It's one of many skills that I picked up because various employers needed me to. Using AI to get better at dashboards would just be filling in my gaps ✨ but with AI ✨ and still at the expense of my spikes.

(Besides, if I'm going to use AI tools to improve my skills, then why not use them at my spikes?)

Mid-Career Slump

I'm really glad that I specialized in mobile software so early in my career. It's been fun and rewarding. I'm also glad that I branched out a few years in. Being able to fit into whatever shape a business needs has been very lucrative. The problem is that I've spent the past six years fitting into other shapes that I've lost a connection to my own intrinsic shape.

It feels a little ironic to end up back where I started, specializing again. But I'm not really "back" here because I'm not the same person I was in 2019.

I'll offer some advice for software developers, advice I wish I had gotten sooner: specialize at first for a jump-start, then generalize quickly after that to accelerate your career. But re-specialize again as soon as possible. Once you become "general enough" to specialize again, do it. Do it before you feel ready.

One of my best skills is being able to discern the most important thing I need to do for a business at any given time, and I've always prioritized the business need. Putting the business first is a great way to get rewarded, but I'm not working just to collect a paycheque. I want to do great work! I'm lucky enough to get to pursue a fulfilling career, so it's time to prioritize my own satisfaction. It's time to find a role where the business' needs overlap with my own.

My hope is to use this reflection like a gravity assist, approaching a career as a generalist before spectacularly sling-shotting away towards a more specialized, more fulfilling career. Gravity assists are famously difficult courses to plot – you have to work backwards from the destination. My destination has been my mobile UX spike.

I've found my next role in a larger organization where I'll have a narrower focus. I'll have an announcement about where I'm going soon. In my new role, I'll get to leverage my expertise as a specialist again. Fewer dashboards, more mobile UI implementation. Less average, more spiky. And hopefully, a happier me.

Floating On

Fri, 26 Sep 2025 00:00:00 GMT

It's with mixed emotions that I'm announcing today is my last day working at Float. I've accomplished a lot here and I'm grateful for the opportunity to help shape such a young company and product team. I'm sad to say goodbye to my coworkers and I wish everyone the best.

Whatever job I'm in, I always learn something – that's just how I practice product development. But I was surprised by how much I learned about myself at Float. I've worked in early-stage startups before and so I thought I had an idea of what to expect. There were two curve balls I didn't anticipate.

The first is Float's distinct ferocity: everyone at the company cares deeply about Float's success. They work harder than anyone to earn customers' business, to fight for their market position. I care a lot about my work, so a company full of other people who care about their work was a perfect fit for me. The unexpected part was the intensity. Float is the most ferocious company I have ever worked for. While I'm proud of how I rose to that challenge, I also learned where some of my own limits are.

The other difference is me. I'm different. At other startups I've joined, my role was (at first) to build apps. I grew into leadership positions, but Float was my first time I joined an early company as a leader. That brought a whole new set of challenges. I worked more closely with company leadership, I learned more about the business than I had at other startups, and I exercised my autonomy appropriately. That's a lot of extra context to absorb and execute on.

I'm proud of my accomplishments here, as both a technical leader and as an organizational leader. Building an app from scratch is always a lot of fun, and the team I led launched the app only 99 days after our initial commit! Scaling a mobile app within a product organization is always an interesting challenge, and I led the Float mobile app to get contributors from every product team. Being part of a high-growth engineering team is always thrilling, and I've successfully modelled my practice of product development through curiosity and empathy. I joined Float to build a great app, and customers have said the app is their favourite part of Float's product. What a compliment! I'm proud of what I've done and how I've done it.

Failure has always been my greatest teacher. Float is a company where you cannot succeed without taking risks and making mistakes, and I've been successful enough here to have made some of my most interesting mistakes. I'm proud of those mistakes. I treasure them.

Deciding to leave a company is never easy for me, and particularly so with Float. It's a unique company and I'm sure it will continue to make waves. I wish Float and my coworkers well.

I keep a small box of what I call "captain's trinkets." Picard had his flute, Sisko had his baseball, and Freeman had her flag of the California Republic. In my office, I keep a small collection of objects that symbolize meaningful times of my career. Float's first product was in corporate credit cards so I feel it's appropriate to retire my own Float card to the captain's trinkets box.

I have an exciting new opportunity that I'm starting after some time off. When I've described the role to people who've worked with me, they've nodded and said something along the lines of "oh yeah, that sounds perfect for you." I'm excited to share more. Until then, take care!

Yet Another Blog Rewrite

Tue, 26 Aug 2025 00:00:00 GMT

In 2019, I rewrote this blog with Gatsby. I outlined my reasons in that post, but basically I wanted to use similar technology to build my blog as I used day-to-day at work. Middleman, Bootstrap, and jQuery seemed old and busted. Gatsby, React, and TypeScript seemed so much more fun.

When I launched the rewrite, someone on social media cautioned me "I hope you don't regret this." At the time, I resented it. But unfortunately I do regret the decision.

Gatsby is large, cumbersome, and slow. Its dependencies constantly change. It breaks under the weight of my many posts, to the point that Netlify is no longer able to build the site without a timeout.

It turns out, you don't need GraphQL to turn markdown into markup.

I looked into going back, to Middleman, but the dependencies are just so outdated and the code is pretty janky, that it made more sense to move forward, to something new.

I chose 11ty, which is a JavaScript-based static site generator with a focus on simplicity and API stability. I wrote the old blog in 2014 using Bootstrap and jQuery, with a CSS preprocessor; the progress of browser standards means I don't need any of that anymore. (CSS Grids are amazing!)

Now, 11ty doesn't really do as much as Gatsby. But I value the simplicity of maintainence over the Gatsby's promises of client-side performance. My blog just doesn't need the powerful features that Gatsby can provide.

All I have to do is port the existing GraphQL implementation. Or, should I port the Middleman implementation? Why not both!

So yeah. I'm using Claude Code for this project, and it's gone really well. It turns out AI coding assistants are really great at porting code between languages. I pointed Claude Code at the Gatsby and Middleman implementations, and have worked through an implementation plan piece by piece. This was actually a great project for me to really dive into the capabilities of agentic coding tools, since this is a project I've built twice before.

I am concerned about code quality, especially plain CSS. AI is great at spewing out a lot of hard-to-maintain-code, and that seems extra true with CSS. To mitigate this, I'm running an experiment. I threw a weekend or two at the project two months ago to get it about 90% complete. Then, I just let it sit there. I wanted to forget the code so I can revisit it later, to dispassionately evaluate it without the thrill of "getting so much done with AI" clouding my judgement.

But honestly, the main site is only 1000 lines of CSS. That's for a fully responsive design. And I'm not that great at CSS, so the bar that Claude has to clear is pretty low. I've actually learned quite a bit about web standards, scrutinizing the code that Claude had spit out.

Unlike previous rewrites, I'm blogging about this one ahead of time. The pull request is here, if you're interested. GitHub's UI shows this as a massive increase in lines of code, only because Prettier formatted seven hundred markdown posts for the first time. I'll have exact numbers once I've finished, but 11ty has a lot less configuration and coding to accomplish the same task. My entire site builds locally in about ten seconds, compared with minutes on Gatsby.

I still have a ways to go. The PR has an open task list, but it's mostly "feature complete." Next steps are things like making sure the RSS feeds' permalinks match, validating the HTML and CSS, and testing. I know that the last twenty percent of a project tends to be eighty percent of the effort, but again, I've done this a few times before so I have a pretty good idea of what I'm doing.

I just hope I don't regret this.

The Murderbot Blog

Tue, 12 Aug 2025 00:00:00 GMT

I've been a huge fan of The Murderbot Diaries series by Martha Wells for a few years now, and was very excited to see it adapted to television on Apple TV+. Every adaptation of a story to a new medium has to make creative choices and tradeoffs; it's fun to pick apart the work to identify what's been changed, think about why that might have been done, and examine the impact on the story.

As a fan of the books, I'm thrilled to see them adapted at all and I don't want anyone thinking that I dislike the show. It was a joy to see The Rise and Fall of Sanctuary Moon show-within-a-show come to life.

This is an ensemble show, based on a single-person narrative novella. That was always going to be hard to adapt, so it makes sense that the production uses an ensemble cast to tell a larger story. More points of view makes it easier to tell a more complete story, and gives the audience more characters to relate to. But too many characters can create confusion, too. The show combined a few characters together and rearranged some of the relationships, to keep the story focused.

So we have this ensemble cast telling a story from multiple perspectives, adapted from a very first-person limited-perspective book. The tradeoff here is that you get less time with the titular protagonist, who is admittedly a weirdo. It could be difficult for audiences to relate to SecUnit, especially in a visual format.

These changes from the source material seem motivated to me, and so I find it easy to accept them and have fun with the story. Even as I wish we could spent more time with the inner life of SecUnit, I understand how that would be very difficult to portray.

The story itself also had to be adapted to fit into ten episodes. This change was less effectively executed than the character changes, in my opinion. The pacing of the show would speed up and slow down so quickly that it felt kind of clumsy. Life-or-death action scenes would be punctuated by relationship drama. The seams of the adaptation were visible.

The television show also nerfed the characters. This was a bummer, honestly. The human characters and SecUnit all make poor decisions and get themselves into unnecessary trouble. And I kind of see why. It's hard to tell a compelling story when all the characters are hyper-competent (that's part of why Star Trek Voyager is the way it is). Having the characters make mistakes also allows for more a more dynamic story, making it easier to adapt to television. This was harder for me to roll with, but I see the utility in it from a production and storytelling perspective.

I've given these examples as a way to show that motivated changes can lead to a story that works better for a television audience, even as I (a fan) would have preferred something different. I'm not saying that the motivation is good or bad, or that the motivation makes the changes good or bad. I'm saying that I understand it, so I find it easy to roll with as a viewer.

But there was one story shift that I don't understand that's been bothering me.

In the books, sprawling corporations fight each other for power and control of a lot of human-occupied space called the Corporation Rim. It's a place ruled by contracts and force. The Corporation Rim is home to multigenerational indentured labour contracts, massive amounts of suffering, and wanton death – all for the sake of profit.

Our humans, in the Preservation Alliance, exist outside the Corporation Rim. But they do interact with it, and it disgusts them. This is a key thing I love about the books: Preservation Alliance is depicted as an actual, functioning utopia. The planetary alliance has built a society where everyone has access to food and shelter, where menial labour has been automated, and where violent crime does not exist.

By depicting Preservation Alliance this way, the books implicitly show that the cruelty and suffering of the Corporation Rim is a choice. It is optional. Something that our human characters avoid.

So it really bothered me when the television adaptation depicted Preservation Alliance as so hapless and resource-starved that they were considering joining the Corporation Rim. I don't understand the motivation behind it. Granted, it's a relatively minor change that doesn't necessarily contradict anything in the books. But it does contradicts the story in my head. This was one of the most important background details of the setting to me and it kind of hurt to see it thrown away.

Adaptations and creators don't owe anyone explanations about the story choices they make. But if I ever got the chance to ask the show runners a question, I know what I would ask.

Bias Towards Helpfulness

Mon, 23 Jun 2025 00:00:00 GMT

I've been using Cursor for coding tasks lately, trying to explore what kinds of work it performs well and poorly. It's pretty good at most simple tasks. It's good-to-okay at some complicated tasks. But then, some simple tasks can stump it – usually in very niche domains. Other tasks are so big that they need to be broken into smaller pieces first – a classic project management problem.

I ran into this last kind of problem recently, when I tried to prototype a large idea for this blog, my personal website. I told Cursor what we're doing and it started strong. It was making great progress when suddenly it got stuck, in a loop, on a very simple change to a config file.

My approach had been too much, too fast. To refine my approach, I tried using a conversational LLM instead of Cursor. I've generally not used conversational LLMs like ChatGPT until a few months ago, because I hadn't found them to be that useful and because it's rational to be skeptical of tech hype. But people are using them, for all kinds of things. Conversational LLMs are replacing search, in terms of user behaviour. I had heard of developers using them to help think through ideas and plans, so why not try?

I talked my idea through with the LLM and... it was actually pretty helpful! It was a bit like "rubber duck debugging" if the rubber duck could answer you. And lookup GitHub issues, and quote documentation, etc. I was pretty impressed. It validated my idea was a good idea and suggested some alternatives.

The next day, I was meeting another developer for a coffee and my idea came up in our conversation. I explained my idea, asked his opinion, and the first thing he said didn't answer my question at all. Instead, he responded with a question of his own. (A really good question, too. Incisive.) I gave him my answer, and he asked a very good followup question: how much time was I interested in spending on this idea? Only when he understood the full context and my motivation did he give me his perspective.

Conversational AI's have a bias towards helpfulness. That may sound absurd, but it's true: LLMs have been trained on helpful conversations from the internet (StackOverflow, for example). LLMs are given system prompts instructing them to answer user questions. They "want" to help us and it's important to be aware of that. This bias prevents LLMs from being able to distinguish prompts that are vague on purpose (users looking for general answers) and vague incidentally (users needing followup questions and/or pushback). LLMs are designed to help users by answering their prompts, not telling them when they're trying to do something really stupid.

It's as though LLMs are bound by a local maxima of helpfulness. Sure, they're helping users with their requests. But they can easily, silently fail to consider the bigger picture. People are messy and they have messy problems.

The developer I spoke to had the experience, expertise, and relationship with me to cut straight to the heart of my question. I hadn't meant this as an experiment, but it's interesting to think about: when asked the same question, the LLM responded with an answer but the developer responded with a question of his own. I think this is another case of learning what tasks an LLM can help with, or rather, learning the limitations of using an LLM for this kind of task.

I want to clarify my stance here because I don't want to be labelled as either a hater or a booster. (Or labelled at all, thanks.) LLMs do have limitations, they have improved, and I am open to the idea that an LLM could be built that is capable of this kind of intentional, selective unhelpfulness. To ask clarifying questions or push back on bad ideas. That an LLM product could even use previous interactions with me as context to tailor responses, similar to how a coworker or collaborator might. Indeed, a lot of companies are spending a lot of time and money trying to build AI assistants which develop a "relationship" with users. Maybe they will build something genuinely as helpful and incisive as another skilled human. But I would have to use it to believe it.

Incidentally, both the developer and the LLM ultimately arrived at the same answer. But, the developer was better company.

Foresight

Sun, 22 Jun 2025 00:00:00 GMT

Imagine you are a software developer. It's the early 1970's and you make a living writing Basic Assembly Language to build software for the System/360 mainframe. You are great at your job and you enjoy it.

You keep hearing about new "high level" programming languages that would allow you to write code in a way that could be "compiled" to run on different kinds of computers. In theory, this would be a huge benefit over writing assembly for just one kind of computer. But there's a catch: these compilers aren't reliable. The code they produce has bugs that wouldn't have existed if a human had written the equivalent application in assembly. The code is inefficient, it is a mess to debug, and you have to use a whole new tool, a compiler.

Compilers introduce a layer of abstraction. Another build step. Another cost. Another skill. Using a compiler would mediate the work of programming, alienating a programmer from both their craft and their labour. Compilers come with tradeoffs. You don't really like these tradeoffs, personally, and decide to stick with BAL.

But you keep an eye on new compilers.

Over time, compilers become more reliable, more stable, more performant. There are a lot of new languages and tools and it's hard for you to know which ones to invest time into learning. (We all remember what happened to PL/I, am I right?)

You decide to learn a new language named C in your spare time.

You have a long and prosperous career.

The End.

Imagine you are a software developer who considers themselves to be a moral person. It's the early 1970's and you make a living writing Basic Assembly Language to build software for the System/360 mainframe. You are great at your job and you enjoy it.

But there's a catch: these compilers are cursed.

Compilers are conjured by programmers wearing dark cloaks, chanting under the cover of a new moon. It's an eldritch ceremony. No one really understands how a compiler works, other than... the cost. Every time a programmer compiles a program, the cost is extracted. Every time a programmer compiles a program, someone – somewhere – suffers. Someone suffers just a little bit, and the programmer doesn't get to see it.

(Also compilers are slow, unreliable, hard to debug, etc. All the same tradeoffs readers are familiar with, they're just also cursed.)

Compilers come with tradeoffs. You don't really like these tradeoffs, personally, and decide to stick with BAL.

But you keep an eye on new compilers.

Over time, compilers become more reliable, more stable, more performant. The curse remains. You see the enormous value in using a compiler, you see how much more productive you could be if you used this tool.

You try using one compiler, and it doesn't work. You wait a while, and you try another. A new one. It does work. In fact, it exceeds your wildest expectations. You feel conflicted.

You consider yourself a moral person. You know about the curse. You see other programmers declining to make the switch, correctly pointing to the tradeoffs.

"Compilers aren't worth it," the other programmers assert. "The curse is an unacceptable tradeoff! We refuse to use a compiler!"

But here's the thing. Programmers aren't the ones who get to decide what is worth the cost.

You can see ahead. You see jobs writing assembly getting harder to come by. They don't entirely disappear, but... you see the industry moving on. You see an entire new generation of programmers entering the workforce who have never not used a compiler.

You have bills to pay, a career to think about, and you can see ahead. And, these compilers are actually pretty fun and useful. You find yourself excited about all the cool things you could build with them.

You still consider yourself a moral person. And you make a decision.

Camera Time

Sat, 31 May 2025 00:00:00 GMT

Recently, I published my first photo blog post since 2018. (Yes I have a separate photo blog, because of course I do.) So what's up with that? Nothing better than a blog post about another blog post.

I haven't really been doing a lot of photography since the pandemic, but I had been increasingly drawn to it over the past six months. Creativity is actually something I've found to be missing in my life – when I found a renewed interest in photography, I decided to follow it. I started taking more photos on my iPhone, then I got out my film cameras since that's what I had been mainly shooting. But film wasn't working for me, so I got out my digital camera, a FujiFilm X100S from 2014. And I loved it.

But, that camera has some limitations I was hitting. First, it's a fixed focal length and I felt myself wanting something with more reach. I've only used prime lenses since 2014 and I enjoyed their limitations. Prime lenses helped me improve my composition skills, but now I'm ready for a zoom. The X100S is also from 2014, which means it's from near the very beginning of the industry's transition to mirrorless. So, it's fiddly.

Don't get me wrong – I've taken some of my favourite shots with the X100S. I have a large canvas print of a long exposure of Tokyo taken from Roppongi Tower hanging in my office, and I took that with the X100S. Back when I used to travel a lot, The X100S was exactly what I needed. But as I rediscover photography in Atlantic Canada, I started to feel its limitations. I kept shooting with it anyway.

I started looking around and realized that you can buy really nice used DSLRs for not that much. I had a sick DSLR kit and I daydreamed about recreating that same setup. But it felt weird to invest in a DSLR kit when they are on their way out. And in the decade since I bought my last digital camera, the X100S, mirrorless cameras have gotten really good. They have some distinct advantages over DSLRs.

Mirrorless cameras are smaller and weigh less than DSLRs – and their lenses too. They often have a tilting LCD screen and I was interesting in using it as a waste-level viewfinder (like my TLR camera). And unlike DSLRs, mirrorless cameras can be adapted to work with my film lenses. My (only) tattoo is an optical diagram of my favourite lens, the Leica Summicron 50mm f/2. The idea of using my Summicron lens on digital really tickled me.

I was concerned about some of the downsides to mirrorless cameras, like shorter battery life and feeling more like a computer than a camera. But the thing I was most concerned about was having to use an electronic viewfinder. I'm used to being able to see, optically, the actual scene that I'm shooting. I was reluctant to give that up. So as an experiment, I started using my X100S with its electronic viewfinder. (In over ten years, I had barely used it.) The refresh rate was kind of laggy but I got used to it pretty quickly. I was actually enjoying the way the EVF gave me an exposure preview of the photo that the camera was actually going to record when I hit the shutter button – that's something that DSLRs just can't do. I figured that if the older X100S was usable, then a newer mirrorless camera would be great (spoilers I was right).

So then the question was: which camera system to get? Usually when a photographer picks a camera system, they're either just getting started or they're experienced and switching systems. I was in a distinct position to knowing what I wanted but also starting fresh. So let me outline my thinking.

Canon and Nikon had both initially missed the boat on mirrorless. Sony, FujiFilm, Olympus, and other manufacturers hadn't been caught in the same "innovator's dilemma" as the two market-leading DSLR makers, and so they had had a huge head start. Canon was also being weird about letting third party lens manufacturers not build on its new mirrorless lens mount, which gave me a bad vibe. And to be honest, Nikon digital cameras have always given me a bad vibe.

So I ruled out the giants. I considered Micro Four Thirds but decided against it. That narrowed it down to Sony or FujiFilm. I spent a lot of time researching opinions online and thinking about what I actually wanted in a camera.

Primarily, I wanted a camera that I would feel inspired by. When I was shooting on my walk to-and-from work in Manhattan every day, I didn't need much inspiration. Photography was automatic. Now, working from home in Fredericton, photography is a decision. It's something I go and do. I've been know to struggle with creative motivation so I was looking for a tool that would get me excited to use it.

I tried some cameras out in-person. By far, the FujiFilm cameras I tried were the clear winners. The Sony cameras reminded me that I'm using a computer, while the FujiFilm cameras felt like old film cameras. Many FujiFilm cameras have physical dials for shutter speed and ISO, and their lenses usually have aperture rings. It felt natural. After some more research, I made a decision on a model. Normally, I would buy a used camera and lens, but FujiFilm's used market is currently overinflated (due to a lot of factors). So I picked a current model.

But before I bought anything, I hit a wall. I became preoccupied with anxiety that all this excitement was just Gear Acquisition Syndrome. When I first got into photography, I compulsively and continuously upgraded my gear. Over the years, I have bought cameras that I didn't really need and that I quickly moved on from. Nerds call this GAS, and I've worked hard to get it under control. Now I found myself worried that my renewed interest in photography was somehow GAS in disguise, that I wasn't authentically interested in photography at all. I wanted to make a responsible decision, both financially and creatively.

Because gear doesn't matter. You can take great photos on bad cameras. And you can have a lot of fun doing it. Here is a photo I love, and the camera I used has an entire two shutter speeds – plus bulb mode!

It's the photographer that matters, not the camera. (Of course, it's easier to say "gear doesn't matter" when you have nice gear. And I do have a nice film kit.) I started questioning whether I should buy a new digital camera at all. Wasn't my X100S enough?

I sat with this for some time. I talked this over with a few people who know me. And I kept taking photos with the X100S. I started editing those photos in Apple Photos, then tried some more sophisticated tools like Photomator and ON1 Photo Raw, before (reluctantly) reactivating my Lightroom subscription. I had really been enjoying editing photos, in a way that I hadn't for a long time.

Not suddenly, but slowly, I realized that my anxiety over a possibly "inauthentic" interest in photography was unfounded. I wasn't trusting myself. It does make sense to sit on a big purchase decision like this, but I had. I had thought it over. And I knew I didn't need it; I wanted it. (Confusing these two is an symptom of GAS.) I talked it over one last time with Ashley and then I hit the purchase button.

That was a month ago. So which camera did I get?

"Gear doesn't matter."

I'll be publishing more photo blog posts over at my photo blog. I'm exploring some new editing styles and I plan to write about that process over there. I don't really know where people are sharing their photos online anymore, to get photo critique; let me know if you have suggestions. See you there!