Ash Furrow's Blog

The Imperial Units Strike Back

Thu, 05 Feb 2026 00:00:00 GMT

I lived in the United States for six years, during which time I refused to learn Fahrenheit. I was forced to give in to using inches because, unlike every tape measure I owned in Canada that had both inches and centimetres, every measuring tape I could find at my local hardware store was inches only. For this and other reasons, it wasn't practical to resist.

But I prided myself in my ignorance of Fahrenheit. It's odd to be proud of ignorance, but using Celsius exclusively helped me hang on to my Canadian identity while living in a foreign country. Sometimes, people would ask me what the forecast was, and you just know that I made it a whole thing.

But when the pandemic hit, I started calling home to my family a lot more often. My grandparents – snowbirds who lived in Florida half the year – didn't know Celsius. That made conversations difficult ("how is the weather?") and I wasn't going to let a my pride get in the way of connecting to my family. So after years, I eventually did learn Fahrenheit. And then I promptly moved home to Canada.

This is all to say, I have some complicated feelings about Fahrenheit.

Because the thing is, during my six years in the United States, I kept hearing the same thing from Americans. Smart people – coworkers, friends! – would all tell me something along the lines of:

Yeah, sure, the Metric System is better for everything... except ambient air temperature! That is the one thing that Fahrenheit is better for. You guys just don't get it.

This. In. Furiated me.

And so, when I heard Casey on the latest ATP episode say something to this effect, I paused the recording to write this post. (Sending feedback before finishing the episode is poor form, I know.) I was compelled to write this because I think he and I get our dander up about this topic in the same way, from opposite sides. And I actually think I have a way for us to square the circle on this. And this has been bothering me for years.

I want to see eye-to-eye with my American friends, and podcast hosts. So this blog post is an olive branch of sorts.

The Case For Fahrenheit

I'm going to do the thing that Metric System advocates never do: I'm going to admit that is neat that Fahrenheit stretches from zero to a hundred, as a range from "really cold" to "really hot." It is! A hundred is a nice round number. It's very neat. I don't think a reasonable person could deny this, even though I did for years, which maybe reflects on me a bit. I'm sorry.

It is also convenient that the Fahrenheit degrees are small enough that thermostats can be adjusted by whole degrees. I don't mind that my car adjusts air temperature in half-degrees Celsius, but I must admit that it would look cleaner if they were whole numbers. And I once owned a space heater that adjusted its digital thermostat by whole degrees Celsius. I wanted more control so I switched it to Fahrenheit. I enjoy the finesse that comes with smaller degrees, and I appreciate the simplicity of design that follows from that.

There is no "but" coming. There is no other shoe that's about to drop, or backhanded compliment. The Europeans and the Australians and the other Canadians... they won't admit that you're right about the ambient air temperature thing. I will.

I hope that you're curious about why no one else will admit that you're right about this, because I think it's fascinating. There are two nuanced points in this debate that get lost in ~~conversion~~ translation.

Acknowledging the Arbitrary

When I hear Americans describe how intuitive the Fahrenheit system is, I feel like I'm going nuts. "This is so intuitive", they say, "because it goes from zero to a hundred." Or maybe they'll say "the sixties feel this way and the seventies feel that way, and it all makes sense!" Yeah! Of course it makes sense to you. You grew up with this system! But going from zero to a hundred did not help it make sense to me.

Any system used to measure something like air temperature, or any temperature, is going to be arbitrary. It's going to have tradeoffs about how it works, what it's optimized for. And although it is neat that Fahrenheit goes from zero to a hundred, that is arbitrary. Consider a temperature scale like Fahrenheit but that goes to 120 instead; we'd be able to reason about temperature like an analogue clock. Or, it could go to 60 like the Babylonians intended, so we could do fun fractions. Neither of these would inherently be more intuitive.

What is intuitive is the system you know.

And even though it is neat that Fahrenheit goes from zero to a hundred, that isn't how people reason about temperature. For example. If it's 35ºF outside, and you go inside where it's 70ºF, do you think about that as being "twice as warm"? Probably not. Zero to a hundred suggests percentages, so do you think about inside being "35% warmer" than outside either?

Maybe I'm wrong here, but I think people feel temperature differences in absolute terms in degrees, not in terms of multipliers or percentages.

Going from zero to a hundred is neat. I like how it makes degrees act like a percentage, truly. But I don't think that going from zero to a hundred helps people reason about temperature in a way that Celsius does not. I have the same intuitive understanding for Celsius that you have for Fahrenheit. I don't think either is inherently better. The one that feels like it "makes sense" is the system you know – please believe me on this.

Yeah? Are we still friends? Okay I'm glad.

Putting the "System" in "Metric System"

I mentioned tradeoffs earlier: there are benefits and drawbacks to any temperature scale. I don't think many Americans understand the value in Celsius because I don't think many of them actually know the Metric System. The systemic nature of Celsius makes up for the annoyingly large degrees, among its other drawbacks, in my opinion.

When I took high school physics, it was revelatory. Suddenly, many different things about the world were interconnected. They always had been. I loved it. Learning about how the speed of sound is affected by air temperature, and the Doppler effect, and total internal refraction... It was so fun to learn how the real world could be modelled. And one part of this awakening was the realization that all these units were connected, just like the world was.

The Metric System is arbitrary, like Customary Units and like every other measuring scale. But by making very intentional decisions, the Metric System connects together the different aspects of our physical reality into one elegant, beautiful system. Let me explain.

Using one cubic centimetre of water as a baseline, we have the definition for one gram of mass and for one millilitre of volume. Distance, mass, and volume are connected, boom. Next: raising that water's temperature by one degree Celsius would require one calorie of energy. We could continue, to describe the connection to Joules, and Watts, and so on... but my point is that these are all connected by the definition of the units themselves. And that is also pretty neat.

By learning a system of measurements that makes it easy to reason within, I think people are able to more easily develop an intuition about that reality. Celsius fits within that system, even if it has tradeoffs.

My American friends: most of you don't know the Metric System and so most of you can't appreciate the value that the system affords. And I know that the idea of change is hard – it sucks for my family members who grew up before Metrification in Canada. And I appreciate the fact that most people don't need to intuitively relate mass and energy, or whatever. But I relish in it. I love being able to reason about the size of my espresso machine boiler and its power draw and volume, and kilowatt hours, and all that. I just think it's neat.

This doesn't make Celsius a better system than Fahrenheit – it's just different tradeoffs.

While (I think) I do understand the value in going from zero to a hundred, I don't think Americans understand the value of the Metric System. This isn't a flaw or a shortcoming, in any way. It's just something that I don't think you all are aware of. An "unknown unknown." And if you care about measuring ambient air temperature as much as I do, I thought you might be interested to learn.

The tl;dr here is:

Fahrenheit is convenient for ambient air temperature, but going from zero to one hundred didn't make it easier for me to learn.
Celsius becomes more valuable when it's used within the entire Metric System, leading most Americans to be unaware of that value. This is why no one will admit that you're right about the first point.

I still prefer the tradeoffs that Celsius makes over the ones Fahrenheit does. But I see you. We can agree to disagree.

Time to go listen to the rest of that podcast episode.

Upcoming Conference Talk

Sun, 21 Dec 2025 00:00:00 GMT

I'm very excited to announce that I'll be speaking at the Swift Rockies conference for iOS developers next July in Calgary. This will be my first conference presentation in over five years!

My talk is titled My Slow Return to a Swift Career. I'm pecking away at it (I have a half year to prepare) but it will be part "career retrospective" and part "technical deep dive comparing React Native to native iOS development." My native iOS development experience stretches back to iPhoneOS 3.1. I still know UIKit like the back of my hand. But I have a lot of experience with React Native, too: I helped migrate Artsy's native iOS app to become hybrid native/React Native, I built an entire SDK on top of React Native at Shopify, and I led the team that build Float's mobile app from scratch.

I recently started a job at Wealthsimple where my focus is on mobile user experiences. I'm using native iOS technologies again a lot and I'm really enjoying it!

As a whole, it's fair to say that the iOS developer community dislikes React Native. But the complaints I hear about React Native tend to either over-generalize or exaggerate its problems. I bring a nuanced perspective with more... interesting complaints.

I'm really looking forward to it, and I hope to see you in Calgary!

Peer Lab Community Shut Down

Sun, 14 Dec 2025 00:00:00 GMT

When I lived in Amsterdam, a friend ran a weekly meetup for programmers. He held it on Saturday mornings, to discourage people who only had ideas for apps. The idea was to spend time in a café working on projects around other coders who were working on their projects, to exchange ideas and make connections. I enjoyed the Peer Lab so much that I started my own when I moved to New York and ran it for five years. It was only stopped by the novel coronavirus pandemic.

I made a lot of friends and acquaintances at these meetups. Lots of great memories, lots of fun coding.

Eventually, I created a website called Peer Lab Community and hosted it at peerlab.community. It had a list of dozens of worldwide Peer Labs and instructions to start one of your own. I've maintained that site and domain until recently; I've decided to shut it down and let the domain expire next month. This is more of a formality than an actual change, since the list is woefully outdated. All of the events predate the pandemic and the only pull requests I've received in five years have be to remove events. I don't live in a big city (or travel frequently) like I used to, so I can't spread the idea around like I once did.

The GitHub repo is archived and the site content is still served at ashfurrow.github.io/peerlab.community/. The old URL will 301 redirect to the new archive, but only over HTTP.

It's sad to see it go, but I didn't want it to slip away unremarked upon.

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.