Ash Furrow's Blog

My Slow Return to a Swift Career

Sun, 01 Nov 2026 00:00:00 GMT

I recently gave this talk at the SwiftRockies conference in Calgary. This blog post expands on a few points that I didn’t have time for in the presentation, as well as some updates since then. The talk is here.

Because I’ll be discussing my work with React Native for an audience of iOS developers, I feel the need to establish my bona fides up front. I started building my first iOS app in 2009, and grew into a career in native app development. I literally wrote a book on Objective-C (well, I co-authored one). I was in the room at WWDC when Swift was announced. I know my stuff.

I found my way to Artsy as an iOS developer. I really liked Artsy. I still like Artsy. The company and product mean a lot to me.

And in 2016, after two or three years there, they said we’re going to move to React Native. And I said “no thanks.” But I liked the company more than I disliked JavaScript, so I stayed. I kept working on the native parts of our mobile app. Eventually I started working on some web apps in React, and that’s when I realized that React is nice! And, maybe, React Native wouldn’t be so bad.

So I started investing in React Native experience. My skills became valuable, and some momentum built up, and without me really realizing it, my Swift skills started getting left behind as the language and community advanced. I still used my native skills within React Native, they just weren’t my focus. So I kept my React Native momentum up.

But something was missing.

Fast forward to 2025, and I found an opportunity with Wealthsimple to leverage my background as a native iOS developer to help the company elevate its mobile app experience. I jumped at the chance.

Today I want to talk about the reasons why teams choose React Native, why they often overlook the technical costs of doing so, and what happens when they do earnestly try to make an actually great app with React Native.

Is It React? Is It Native?

So first, and I’m sorry but, we do need to talk about React Native under the hood. Is it React? Is it native? I’m going to make each case.

So if you consider what I started my career building as a “native” application (Objective-C runtime, UIKit view hierarchy) that is a native app, right? This is not a controversial statement. And like the ship of Theseus, I could make small tweaks to it, and I can move some things over into a different thread, maybe it’s a different programming language, and eventually we could get to something that looks like React Native. And at every step along the way, it was still a “native” app. It could call UI events synchronously from UIKit over into JavaScript, and JavaScript could manage the UI hierarchy.

So technically React Native is native.

Technically.

On the other hand, there is something missing. There are a couple things missing.

So the first thing I just want to highlight: apps are more than just a view hierarchy. There is a lot to mobile apps that elevate them above software, and that’s why I enjoy building mobile apps so much. My web developer peers are rolling their eyes right now, and I’m okay with that. Integrating with the underlying operating system is necessary to really delight users.

React Native was really written for the web, so it’s optimized for writing web software. And as a consequence, you’re way more limited than you’d want to be if you (like me) want to build a great app. Unless you’re comfortable writing native code. Unfortunately, most React Native developers aren’t. And that’s fine: there is still lots that can be done without writing native code. You’ll just tend to fall short of a “great” app.

There are two examples I’m going to talk about. One I’m going to mostly skip over, but it’s huge: threading. Dispatch queues, Swift’s Task, threads… all very basic concepts in native development. Complicated to use effectively at scale, sure, but the building blocks are quite simple. These are all totally out of the conversation with React Native. (There are new worklets but generally JavaScript is not great at multithreading.)

So, the other example: fonts. At Wealthsimple, we care a lot about the design and the polish and the user experience of our application, and we had our own font made. Simple Sans. It supports an OpenType font feature called case-sensitive layouts. Most fonts render parentheses so they vertically centre with lowercase letters by default. Case-sensitive layouts are a way to raise the parentheses and other punctuation so they align with uppercase letters instead.

Default is on the left, case sensitive on the right. See the difference?

Why would you want that? Most letters are lowercase, so you generally want parentheses and other punctuation lower to match those letters. But as a financial services app, Wealthsimple renders a lot of numbers. So we made sure our font supported this OpenType feature in order to align the parentheses with the uppercase letters, and therefore with the numbers.

It’s a very small distinction but the parentheses feel too low for numbers otherwise.

iOS supports this natively, no problem. Android supports it, too. React Native does not. But that’s okay, because I know React Native, and I can just go in and patch it, add boom. Case-sensitive forms in our app, no problem

It’s kind of an indictment of React Native that I’ve had to add different OpenType features so often that I could reasonably list this as a skill on my resume.

This is not an uncommon need: to reach into React Native and extend it, bending it to my will. That is not “native.” In my opinion, developers should be able to do things like this easily when it’s supported by both iOS and Android.

But they can’t. Because React Native is not native.

I eventually started doing React Native at Artsy after I started doing React web at Artsy, and React is… I think it’s pretty cool, actually! React basically keeps an in-memory store of what your user interface is supposed to look like and then reconciles that to the actual browser DOM on-demand. And if you squint, you can kind of say: okay, React Native has a JavaScript runtime, it’s a virtual DOM, it’s a UIKit view hierarchy.

React Native is React, right? Well, kind of.

In one sense, React Native is React… to a fault. On the web, there are sometimes good reasons to “punch through” the React abstraction to get to the underlying DOM elements, so you can dangerouslySetInnerHTML, or use a ref, or use an imperative handle, because React has to work on the web with decades of HTML forms and other quirks. On native, there really aren’t the same escape hatches because React wasn’t built for native.

There are valid reasons that I might want to “punch through” and do things directly to the UIView instances. But it’s very difficult because if it doesn’t fit within the web paradigm, then making it easy is not a priority for React. To be fair, that has advantages too: fewer native-specific escape hatches mean that React Native is easier for React web developers to use.

So React Native is React. For better and worse.

I’ve saved the most controversial take for last. The argument I just made was a lie! The JavaScript runtimes are totally different. In a browser, JavaScript is run by just-in-time compilation to be very fast. But in React Native apps, we precompile the JavaScript into bytecode and execute it on a very specific, mobile-optimized JavaScript execution engine called Hermes. Hermes is great, but it’s not a web browser, and you have to know about some of its quirks because it’s so specific.

React is an active project that comes out with new features, but those features rarely launch on React Native alongside the web. When React hooks were released, I remember waiting excitedly for React Native support. Years later, when Suspense launched, I didn’t even bother getting excited because I knew I’d be waiting such a long time.

So if you’re a React web developer thinking you can just use your React skills with React Native: not exactly. You’re going to bump into differences eventually, and you have to know about these differences to make a great app. I don’t even want to get into the distinction between shadow trees and virtual DOMs.

React Native is not actually React.

The Illusion of Simplicity

So with all this complexity, you might be surprised to hear that the reason teams sometimes pick React Native is for the sake of simplicity. Unfortunately, that simplicity is an illusion.

The most compelling reason teams pick React Native (or at least, the one I understand the most) is simplicity. React Native promises to simplify mobile development. But the problem is that there is irreducible complexity to mobile software.

Mobile apps get shipped to users’ devices, and updated over time (hopefully). Mobile apps are closer to shrink-wrapped software or on-prem software than modern web apps. Web apps have become the “default” kind of software, so it’s appealing for React Native to flatten the differences between web apps and mobile apps.

There are many, many differences between web apps and mobile apps. (To name one: application state is not something you have to deal with on the web.) So React Native can’t really simplify that. React Native can only move the complexity around, and as a result, the application becomes much more complex on the whole.

To make this concrete: if you’re in North America building software, you likely want an iOS app, an Android app, and probably a web app, probably in React. You’ve got three different teams just on the frontend trying to build the same product. If you want to release a new feature, you’ve got to keep each of these teams in sync with each other. That’s a lot of overhead, and it slows you down.

The promise of React Native is: what if we replace all of this complexity with just React?

React is easier to hire for. The people making the decision – the directors and the VPs – they often know React already so it’s something they feel familiar with. React Native smooths over the organizational complexity in exchange for adding a ton of technical complexity under the hood.

I have a hard time vilifying this trade-off, but I do think teams sometimes overlook the costs because they’re dispersed throughout the organization and hard to measure.

As your product gets more complex and you add more features, your organizational complexity with a React Native team grows roughly linearly – assuming you’re architecting your app correctly. But if you have multiple native platforms, you have to coordinate between those teams, and the complexity scales higher.

From a code perspective, though, the opposite is true: assuming proper architecture, as you scale more products and features on the native side, you can do that without ballooning the complexity of your code. With React Native, you’re forced to. Because if you try to build outside of what it’s optimized for, you’re in for a bad time – and you don’t have to go far outside of the norm to feel the pain. High-performance needs like streaming live data, complex animations, deep platform integrations on iOS or Android… all introduce extreme complexity.

And even average apps will need to spend time managing the React Native platform. It is not free.

Businesses tend to “measure what matters.”

But not everything that matters is easy to measure.

The prevailing wisdom in business is to measure what matters. You pick something that matters, you measure it, set some goals – OKRs, KPIs, whatever – and use those to make sure what matters moves “up and to the right.”

But not everything that matters can be easily measured.

Things like user experience quality are very intangible: they show up across App Store reviews, net promoter scores, or just the feeling users have towards your app. And it’s hard to attribute any of that back to “native versus React Native.” Because these intangible qualities are hard to measure, I think that product teams sometimes underweight the importance of them. And that’s really where React Native suffers.

But it’s not all bad. Product teams do like React Native. You get one codebase, one programming language, one-ish deploy process. It is simpler.

Testing JavaScript-only changes is really nice too, because you can open up a pull request and have a computer in the cloud generate a JavaScript bundle, post a QR code to the pull request, you scan it with your app, it downloads the bundle, and that’s it. My coworker can test my changes on their phone directly. No provisioning profiles, no signing, nothing. It’s incredible.

Over-the-air updates are very common with React Native applications, and they’re incredible. I cannot stress enough how amazing it is to fix a production issue with it. I have resolved production incidents by pushing a CodePush bundle with fresh JavaScript that gets downloaded to all users, and it works. Everybody does it (or so I hear) and if you could do it on native mobile apps, I guarantee that you would too.

Startups and scale-ups need to prioritize speed above all else and that’s okay. They can prioritize speed by using React Native, as long as they know that someday, if the company survives and is successful enough, their needs will likely outgrow React Native. And that’s okay too.

The real issue I have is that by smoothing out the differences between platforms – between Android and iOS, between web and mobile – it encourages product teams to think about apps as mere software. And apps can be more than just software.

The Costs

React Native has a huge cost. The dependency upgrade churn is intense. It often comes in lockstep: if you need to upgrade Expo, you’ll need to upgrade React Native, and you’ll also need to upgrade your TypeScript and your Babel and your Reanimated and all of these things. They all have to be done at once, and they’re all constantly moving. Huge risk. It’s a nightmare, and I dislike it more than any other part of building React Native.

You also get a massively more complex runtime. Every React Native app tolerates a background radiation of random crashes that no one can explain, that are intractable to solve because the stack traces cross the JavaScript-to-C++ boundary, and you have to just live with it.

It bothers me more and more every day.

The abstraction of React Native pushes you further away from the platform and the tools. If there’s a user interface idiom or native component that would be really great for your app, well, I hope you’re willing to write some Objective-C++ to reach for it! And if there’s a problem with your application, have fun with the React Native dev tools. The profiling tools have gotten better over time, but it’s hard to hold a candle to Xcode’s Instruments. I actually use Instruments to profile React Native apps because I can get better results from them. But I knew the tools already; teams really have to push harder to achieve the same quality.

It’s kind of like the speed of light – the closer you get, the harder you have to push to get even closer. That’s true of native and Swift too, but it gets so much harder, so much earlier, with React Native.

And unfortunately, React Native has been trying to shrink the size of its core for several years, so some very basic things that you shouldn’t have to use an external library for, you now do. The priority has been to make the core of React Native “more cross-platform” to support Windows, for example. I don’t care about Windows at all. This results in outcomes like React Native not even having an API to access the device’s pasteboard anymore – you have to use a third-party library for that. WTF.

Personal Costs

So what about the personal cost to me? It’s complicated.

Being great at iOS helped me be great at React Native, but I don’t know if that’s because of my technical background or just because I cared. There is no substitute for caring.

Unfortunately, React Native pulled me away from iOS: the technical side and the community side. More than I expected. Way more than I expected.

But, I’ve gotten chances to solve really interesting technical problems at a scale I probably wouldn’t have been able to without React Native. I also really love TypeScript – it’s a fantastic programming language, and honestly, the way it models types as sets, I really like it.

However, it’s been difficult to feel like part of the iOS developer community. It’s sometimes been difficult for me to listen to iOS developer podcasts, or read developer blog posts, from peers whom I admire because of how they talk down about React Native and developers like me who use it.

And the need for me to constantly push React Native harder to reach a great app? It’s left me exhausted. I’m so tired of it.

So those are the effects React Native has had on me.

What It Does to Teams, What It Does to Apps

I hope I’ve built up enough trust here that I don’t need to describe all the details, but I have compared React Native and native extensively. They have similar-ish ceilings of performance and quality, but React Native has a much lower floor. What I mean is you can make an app in React Native as good as native if you consistently try hard, but you can also easily make a mistake. Then your React Native app can get a lot worse than it can on native. So that’s what tends to happen.

Specifically…

You also just have to accept that React Native is going to chew up at least 200 megabytes of RAM constantly. That’s the baseline before you even start rendering anything in your app. And you’ll only stay close to that baseline if you’re profiling often, to keep your app performant. Neither native mobile nor React Native developers tend to profile their apps enough, in my opinion. So, yeah.

In terms of CPU and graphics performance, you can get close. I’ve built similarly complex views in SwiftUI and React Native, with streaming data from the network and frequent updates, and tested scrolling performance. The React Native implementation can get within 5 to 10% of SwiftUI. (Even better if you use UIKit, actually, but I’m not here to pick another fight.) 5%, if you squint, is “close enough” to native to be a wash.

So if we visualize this: native and React Native have the same ceiling, but native’s floor is much higher. How bad your app can accidentally be is higher in React Native than in native.

If you think about an average team reaching an average of what they can accomplish – and I’m not trying to look down on being average, that’s just the way it is – if you look at the spread between the floor and ceilings of native and React Native, it’s possible to make a great app in React Native, but it’s a matter of organizational priorities.

Anyone can make a great app in React Native.

But they probably won’t.

Is the team using React Native literally always going to push for the extra effort it takes to make a great app, every time? Teams like that are exceptionally rare.

The fact is, anyone can make a great app in React Native, but they probably won’t. And that’s okay. I don’t actually think that every app needs to be exceptional. Some apps can be average. But I’ve only ever wanted to build exceptional software.

Back when I put up a big fuss about migrating to React Native, Artsy’s Director of Engineering took me aside and promised that we would never compromise the user experience for the sake of using React Native. That we’d always use native if that’s what it took to create a better product.

And they kept that promise.

And then they left the company.

So I was in charge. And so I kept the promise.

And then I left.

I have a ton of respect for Artsy. I care about this company and its products a lot. I helped hire and train a lot of the people who are still there working on this code.

Are they still prioritizing quality in the same way? I hope so. I don’t know – I can’t know, because I don’t work there anymore.

This experience really taught me that if you care about the products you’re building, like I care about Artsy, then you have to make decisions with the foreknowledge that you’re not always going to be the one making the decisions. You have to set your replacement up for success, but you also kind of want to box them in a little bit. And I think React Native is a failure to box in a successor.

So that was Artsy – my time there, my switch to React Native. What about my switch back?

Steering Towards Native

Well, I’m thrilled! I joined Wealthsimple last year to bring an unbiased perspective on React Native and native technologies. This is no easy task, to use either stack when it makes sense for the business.

One of the first projects I worked on was threading. Because JavaScript doesn’t have the capability to put things on a background thread easily, so we built our own. We moved our WebSocket subscriptions into the native layer, with Swift and Kotlin on Android. We have a lot of this type of view in our application – data being updated from WebSockets in real time, and how fast we update the data to the user interface matters to our clients. When we rolled this change out, we saw slow frames (missing the 16-millisecond deadline) drop in half.

This wasn’t a very complex project. In some senses it was, because we had to be familiar with all these different native programming languages, but on the other hand, it’s just threading. Not “just” threading – there was a Swift concurrency talk the day before mine, and I know concurrency is more complex than I’m describing here.

But honestly, just moving some data processing to the background thread was a huge step up for our React Native app.

I’ve got a couple more examples of ways I’ve integrated native underlying UI components into React Native. A straightforward context menu from a UIButton, and a long-press UIContextMenuInteraction.

The wild thing is that the button is a React Native button, rendered in JavaScript, but it turns into a native context menu. And it all scrolls at 60 or 120Hz, whatever the device supports. It’s performant now, and it supports long press interactions too. (I even worked with an Android developer so it works on both platforms from one JavaScript interface!)

So we have those nice little touches that make the application feel like it belongs on iOS. Because it does belong on iOS.

I was hired at Wealthsimple to care about our app like a native iOS developer would, and it’s been a thrill. But it’s been hard, too. I would bet that I’ve struggled more with context menus than any native iOS developer. If you disagree, I want to hear about it.

Personally and professionally, I’m having a blast.

Unfortunately, I’ve also never been more angry at React Native.

After I patched our version to support case-sensitive layouts, I did the responsible thing as an open source contributor and opened a pull request to React Native. I tested it, got an Android phone, found a font with case-sensitive layout on the default system fonts… I did the hard work. And six months later, I haven’t heard a thing.

Seven years after releasing UIScene in 2019, Apple finally required developers to migrate to it for iOS 27. Apps that link with Xcode 27 without a scene delegate will crash on launch. React Native had an RFC to do this migration, and when I gave my talk over the summer, there had been no updates all year.

React Native only released a version that supported UIScene in mid-October 2026, a full month after iOS 27 was released. That means that for that month when iOS 27 was shipping, any brand new React Native application created would not be UIScene-based, which means it would not be resizable at all. And React Native still only supports a single scene. That just – it hurts.

What are the chances React Native apps are going to support the iPhone Duo early after launch? What are the chances React Native apps out there are going to integrate with the new Siri AI features? It’s a joke.

React Native simply does not care about integrating with its underlying platforms. A friend of mine sent React Native a pull request to add UIScene support in 2019, and it never got merged in. The project simply does not care.

I don’t blame any individuals at React Native – these are the same incentives that push companies to operate this way. I understand it. But it’s not for me anymore.

Wrapping Up

We talked about a lot here. I hope you have a greater understanding of how frustrated I am with React Native. Native iOS developers dislike React Native, but I dislike it more.

Today we talked about simplicity and the complexity, and how the most complex thing is how I feel about React Native. We talked about how React Native apps will tend towards average, because that’s what React Native is best at. That’s okay, but I’m not okay with that anymore.

Similar to app quality, I think that my career – in terms of professional satisfaction – has a similar ceiling but a much lower floor. And I’ve felt more satisfied since I decided to be more picky. I’m now only working with teams like Wealthsimple who want my help reaching that ceiling. To create the best app they can.

As I’ve worked at Wealthsimple I’ve used my skills to create a great app. Often that’s meant building with React Native. But more and more, it means I’m working with Swift.

That’s it. This is my slow return to a Swift career.

LLMs Are Tools

Fri, 16 Oct 2026 00:00:00 GMT

I have an enormous respect for Rich Hickey; I think he’s one of the best thinkers among software developers. When I read his post ‘AI’ is Not a Tool (gist), I initially agreed. It felt like a compelling argument. But the more I thought about it, the more I disagreed.

It still feels right, but it doesn’t hold up to scrutiny as an argument. Which is really interesting to me, someone with conflicted feelings about LLMs but who uses them every day, and who wants to get better at using them.

This has been eating at me. So I need to get some thoughts out.

The post tries to define tools, and seems to try (but ultimately fail) to avoid the trap of definition-based arguments: definitions are impossible to agree on. It’s an epistemological distinction, and ultimately not really a valid argument. For any definition of a tool, I could come up with a counter-example: something that is obviously a tool but doesn’t fit the definition, or something that obviously isn’t a tool but does fit the definition.

I’m not really going to argue with the post’s definitions of tools, which are vague (good) but somewhat circular (bad). Instead, I’m going to say that I see LLMs being used as tools every day, and I use them as tools every day. I see them wielded (sometimes surgically and sometimes horrifically). Some developers are good at using LLMs and some are not; I have improved with how I use them to solve problems. Certainly, by some definition, they could be tools?

Or maybe LLMs are merely “automations” instead, not “real” tools. But here’s the counterexample: if hand saw is a tool, what about a table saw? Table saws are more dangerous and less predictable, and could be similarly described as “automations” rather than tools. But I don’t think anyone would argue they are not tools in some respect.

The post tries to make a distinction without a difference, and ends with this somewhat ominous paragraph:

LLMs are not tools. I know many people use the phrase “just tools” simply to indicate “they are what you make of them”. Except that’s not true. Automation has intrinsic properties and differences from tools that you ignore at your peril.

Based on this post, Rich Hickey clearly doesn’t think highly of LLMs. But the post doesn’t present an actual logical argument. It’s a kind of argument from disgust. And it was disappointing to read from someone whom I respect a great deal.

Among software developers with (strong) opinions on AI coding agents, I see two groups emerging:

The first group asks, in horror, “how could you trust code that’s generated by an LLM??”
The second group asks, with curiosity, “how could you trust code that’s generated by an LLM?”

I’m in the second camp, and increasingly so.

(I would have had an easier time getting onboard if AI boosters would stop being so unhinged. But I digress.)

As I’ve written about before, I have a hard time relating to software developers who don’t express curiosity towards LLM-based coding agents. I absolutely relate to having conflicted feelings about them, but I do see an increasing rift here as software developers talk past each other. And I’m not sure what to do about it.

One Year at Wealthsimple

Wed, 14 Oct 2026 00:00:00 GMT

One year ago, after reflecting on what I really wanted from my career (and what I didn’t want), I joined Wealthsimple. Time has absolutely flown by! And you know me, I can’t help but blog about it.

I joined Wealthsimple with the role of caring about the mobile app as if it were a native iOS app, even though it’s implemented in React Native. After all, it is a native iOS app, it just happens to use JavaScript to render its UI.

I cared a lot. And that drove me to accomplish a lot. The first project I helped with cut the stalled frame rate of the app in half. I felt more accomplished in just the first few months than I had in a few years.

This summer saw me installing the iOS beta on my main phone and developing new features against the beta SDK. It had been… a while. I felt the joy and pain of a beta OS. Fun! Fun? Fun.

I navigated a product organization that wasn’t used to concepts like “apps linked against older SDKs will run in compatibility mode on newer iOS versions”, which was challenging. This is the air that iOS developers breathe so it can be tough to work in a a different environment. But I managed to ship so much. I bridged the gap between the underlying native technology and the JS layer that the organization was familiar with, in a way that empowered my peers. Just doing the thing myself would have been a failure; instead, I helped others learn and grow. And I learned and grew myself.

When I joined Wealthsimple, I’d been building with React Native for eight years – fully half my career as an iOS developer – and I was excited to push the bounds of app quality with React Native. I didn’t expect to hit those bounds so easily, so soon. Here’s an example.

Do you see this context menu? I built it! Looks simple, right? Wrong! This is a native menu invoked from a UIButton, which contains a view sub-hierarchy that gets defined in JavaScript and managed by arcane Objective-C++ wizardry. I’m so proud of it, yet I feel appalled.

My thinking a year ago was that organizational priorities were the main challenge to making a truly great app with React Native, that if a team were just to hire someone like me then it could be done. To my surprise, when I was given the resources and was empowered to make a React Native app truly great, I hit some fairly intractable technical hurdles, fairly quickly.

That’s part of what spurred me to give my conference talk.

Oh yeah, I gave a talk!

Years ago, “back when I was Ash Furrow” (as I sometimes joke to my wife, to her chagrin), I gave conference talks. A lot of conference talks. I hadn’t given a talk since covid, since I moved home to Canada. But this summer, I gave a talk at Swift Rockies. My Slow Return to a Swift Career was part career retrospective and part technical exploration of what React Native can and can’t do. I shared a lot of what I’d learned at Wealthsimple.

iOS developers… tend not to hold React Native in high esteem, let’s say. When I first showed up at the conference, I felt like I was wandering into a lion’s den (not only because the conference was held at the Calgary Zoo). But almost immediately, I felt more like I was returning to an old favourite hangout, with familiar and friendly faces.

“Welcome back”, one of my peers told me after my talk. I fought back tears.

I’d already been using AI coding tools throughout 2025, but my use of them really accelerated after joining Wealthsimple. I didn’t join specifically because of their approach to AI tools, so this has been an unexpected, welcome highlight of my time here so far. Wealthsimple’s approach to AI code tools has been pragmatic, responsible, and ambitious. My proficiency at using LLMs to ship products is leaps and bounds ahead of where it was a year ago. I’ve learned so much, and I feel closer to the cutting edge of how product development is evolving.

I’d been worried when I joined that my Swift skills would be too outdated to be a “proper” iOS developer, that I’d somehow tricked Wealthsimple into hiring me. But there’s actually never been a better time to be “rusty” at a technical skill. I wasn’t hired just for what I can do; I was hired for my opinions, for what I can inspire others to do, and for how I care about my work. There is no substitute for caring and that’s never been as true as it is with the proliferation of AI coding tools.

So that’s year one! I’ve built a lot and I’ve had a big impact: millions of Canadians benefit from my contributions so far! I’ve made interesting mistakes, the best kind. My sense of professional pride and accomplishment is as high as it’s been since Artsy, “back when I was Ash Furrow.” And I’m thrilled for what I’m working next. Stay tuned!

Radiating Intent

Sun, 20 Sep 2026 00:00:00 GMT

I had a new member of my team join recently and, when I met with them one-on-one for the first time, they complimented me on my standup updates. My team works remotely so standups are an important touchpoint. My colleague and I talked a bit more about what made my updates helpful and I realized that I’ve never actually written a public blog post about this.

This is that post.

The idea is called radiating intent and it’s guided how I show up and communicating professionally for nearly a decade. (I don’t remember where I heard this from initially.)

Here’s how it works: I keep the people I work appropriately aware of what I’m about to do. If they have feedback, concerns, or suggestions, I make sure they know that I do want to hear from them. But I’m not waiting to hear from them; I’m going to take action by default.

Radiating my intent has a few key benefits for me and my team:

It speeds me up because I’m not waiting for approval.
It makes it easier to work with me, since coworkers only need to reach out if they have something to say.
It invites my team to give me feedback (if they have any) which helps reinforce healthy team dynamics. Especially when working remotely.

It’s not a complex idea. “Keep those around you appropriately aware of your next move.” But the word “appropriately” is key: too much detail and I become a distraction, too little detail and I become a lose cannon. And it really is my immediate next steps, not something I’m planning way in the future.

I try to think about who I’m talking with and what they need to know to give me valuable feedback.

It’s also a cue for me to figure out what I think I should be doing, rather than relying on others to tell me. Now, you might say “that’s all well and good for a staff developer who gets a lot of autonomy, but it won’t work for junior developers.” And I disagree: I think that having a sense for what you should be doing next at any given time is a valuable skill at any career level. Radiating intent helps you hone that skill. And it shows initiative, which is especially distinguishing for junior developers.

Here are some counterexamples and what I would do instead:

“What ticket should I work on next?” -> “I plan to work on this ticket next. Let me know if anyone has something else they need.”

Even at the ticket level, when you find your own next work item on your own it shows initiative. Maybe you get it wrong, but then you get to learn from that. Most managers would rather correct you on this than try to find you a ticket. The extra bit at the end (“let me know if…”) is a hedge in case you made the wrong call. As your experience and responsibility grows, you can use these kinds of hedges less and less.

“Do you think we should find help with this project? We’re at risk of missing the deadline.” -> “We’re at risk of missing our deadline so I’ll be asking Andre this afternoon if he has spare time to help.”

Not only are you making a call here, but you’re being specific with your solution. It’s a bit more senior-level of a call, but this kind of thing happens all the time when building software.

“Next week has a holiday, should we get on-call coverage?” -> “Next week has a holiday and I think we need on-call coverage. I’ll let the exec team know that we plan to cover it, and I’ll make sure whoever volunteers knows our lieu-time policy.”

People-based decisions like this can be tricky. Maybe this wasn’t the right move! Maybe no one needs to be on-call during a holiday! You team can tell you. Or, the exec team will since you’ll be radiating intent to them, too.

Radiating intent works well in small startups and large companies. I know because I’ve used it in both settings.

I’ve heard the expression that “it’s better to beg forgiveness than ask permission” too often in my career. And I get it. No one wants to get stuck waiting on someone else’s approval, we’d rather move quickly based on our own convictions. But if we keep secrets then we risk misaligning our work with the rest of the company. We risk duplicating work that someone else is already doing, closing ourselves off from feedback that could improve our work, or wasting time on low-priority tasks when something more urgent needs to be done.

Begging forgiveness sucks. So does asking for permission. I ask for nothing, but I always remain open to suggestions.

May You Live Forth and Prosper

Mon, 04 May 2026 00:00:00 GMT

Three years ago today, I was laid off from Shopify. Ever since, Star Wars Day has been an annual reminder of that difficult experience.

Legally speaking, I have no opinions about my former employer. But… getting laid off was a truly awful experience, and its timing in my life could barely have been worse. I can’t avoid the company, either: Shopify is a huge part of Canadian tech, I use a lot of Shopify open source software, and Shopify advertises on many of my favourite podcasts.

So it’s hard for me to have no opinion about Shopify. It’s a daily practice.

I’m not one of those people who has gratitude for the bad things that have happened to them. There’s still a piece of me that wishes it hadn’t happened. However, I am grateful for where I am now. And I wouldn’t be where I am (or who I am) without my experiences. Even the bad ones. Maybe even especially the bad ones. I’ve accepted what happened, and lately, my daily practice of not having opinions about Shopify has felt a little lighter.

AI Coding Tools

Sun, 19 Apr 2026 00:00:00 GMT

I started writing this blog post as an attempt to collect and distill all my various thoughts and feelings about AI and AI coding tools. But the longer I took to write it, the more things kept changing, and the harder it became to fulfill that scope. So I’m just going to give a history of my own use of AI coding tools. This video tries to describe why Claude Code specifically has taken off in popularity, but I don’t think the creator was specific enough. I’ll cut to the chase: Claude Code was the first AI coding tool to meet me where I was at.

I have a lot of problems with, and feelings about, generative AI. I’m conflicted about using these tools because I’m aware of both the benefits that AI coding tools can have and the harms that LLMs do at scale. My own copyrighted books were stolen and included in LLM training data. My open source contributions and this blog are almost certainly in LLM training data. If you’re looking for a cohesive moral stance on AI, I don’t have one.

I have always been curious about new tools and technology, that’s why I chose this career. But I’m confused by the staunch rejection of AI coding tools by some coders. I see a kind of pride taken in their incuriosity, that I have a hard time relating to.

My approach to writing this blog has been to share things as I learn them: Since I still remember what it was like to not understand something, my explanations are helpful to others. Since it’s so new in my understanding, it helps me solidify my own understanding. So, keep that in mind here.

I was working at Shopify when GitHub Co-Pilot was first announced in 2021. I was given access to the tool in VS Code, so I tried it out. I hated it immediately, viscerally. It was only impressive in a technical sense, that it was able to predict what I might type next. But as I wrote code, it would interrupt my train of thought with its suggestion if I paused typing too long. My brain would get distracted by that suggestion, flipping from thinking-to-reading modes. GitHub Co-Pilot slowed me down and kept me out of flow state. I turned it off.

When I joined Float, a few years later, GitHub Co-Pilot was enabled on my new laptop. It had improved since, but only in terms of how quickly it generated its distracting suggestions. The only time I ever had luck with it was when I wrote a multiline comment describing a custom groupBy that I was too lazy to write, started writing a function definition, and waited.

/*
TODO: Write a function that groups items by such-and-such a blah blah blah
*/
function groupBy( // This is where I paused

It filled in the implementation, mostly correctly. Cool! But I still turned it off again. Because that was the only positive interaction I had with it.

But you know how it is these days. Companies want to make sure they take full advantage of all the new AI tools. No one wants to get left behind, including me. I love to learn, and I love getting paid to learn. So when my coworkers started talking about Cursor, and Float offered me a licence, I tried it out.

Cursor is a fork of VS Code with a ChatGPT-like interface where you can tell it what you want. It will walk through the implementation with you change-by-change, or you can just let it rip. I liked the chat interface – it was like my comment workaround with GitHub Co-Pilot. I didn’t like that I had to use an entirely new editor, especially since Cursor stole the ⌘K keyboard shortcut. Excuse you.

Like Co-Pilot, I didn’t like Cursor either, but I kept at it anyway because tools do take time to learn. I wouldn’t expect to feel productive with a brand new IDE, AI or not. I committed to using Cursor as a first resort for tasks and accepted that it would slow me down at first. I was getting better at it, but I still didn’t like it. It felt like the worst of both worlds: I had to pay attention to every code change but I didn’t get to make any changes myself.

Each week, I would discuss what I had learned about using Cursor to Float Engineering’s weekly knowledge share. I got feedback from others about my workflow, I applied it, and then came back the next week. Other shared what they had learnt too. I was always honest about what was working and what was not. It was actually fun to learn, even if it was still frustrating.

Then, Claude Code was released. I tried it while it was in preview and I immediately cancelled my Cursor subscription. I’ve been using Claude Code daily ever since.

Claude Code was the first tool that met me where I was at. It wasn’t a new IDE, it was in my terminal. I could hold its hand, or I could let it work on its own; unlike Cursor, it was actually decently okay at making changes unsupervised. I review its output at the end, in a chunk, like a pull request. Claude Code’s VS Code plugin came out with just the right amount of IDE integration.

Unlike other tools until then, Claude Code was functional, effective, and… it was cute. I think this last part is important: everyone at work loved the cute messaging Claude Code would give while it was running inference. It would give statuses like “Coding”, or “Spelunking”, or “Manifesting”, and I actually think this cuteness is important because it highlights that it’s not just a tool, but a product.

GitHub Co-Pilot is a tech demo. Claude Code is a product.

When I started really getting into using Claude Code at Float, a coworker told me it was like watching Invasion of the Body Snatchers. I had been so critical of these tools because they hadn’t been working for me, that when I started enjoying them it felt like I had changed. But I hadn’t changed – the tools just finally got good enough.

I credit Nilay Patel of The Verge for being the first person to articulate this idea in a way that resonated with me: AI technical innovation is impressive only if it can be used to build something impressive. And generally, it can’t. But for coding specifically, it can.

On the technical side, the real innovation with AI coding tools has been to loop them back on themselves, to give them the ability to verify their own work. That’s it, that’s the whole innovation. It sounds dumb and it is, but it works remarkably well. In fact, I don’t think LLM model development is a bottleneck on AI coding tool quality. There are many languages and development environments that aren’t yet set up with this loop back, and there is still a lot of experimentation happening in this product area.

If an AI coding tool has a unit test suite with a broken test, it can fix the implementation if given the right prompt, with strict compiler settings, and opinionated linters… and access to run tools. Sloppy codebases lead to sloppy AI tool output, and smart teams are currently investing in infrastructure to make it easier to evaluate code correctness: CI, linters, unit tests, automated regression tests, static analyzers, and so on. Smart teams are prioritizing investments in these.

(But then again, smart teams were already investing these.)

I never know if I’m ahead of the curve or behind the curve with these tools, but I do think that there are a lot of developers out there who could get value from these tools but aren’t. The tools aren’t working for them and I blame the tools. GitHub Co-Pilot is so bad that it has irreparably damaged the reputation of AI generally. AI coding tools are products; they need to meet developers where they are at, provide onramps, and show their value quickly.

Using Claude Code, like any tool, is a skill. It has taken me time to learn and I’m still learning. My CLAUDE.md file gets updated all the time. I’ve learned to manage the context window like any kind of finite resource. The longer a conversation goes, the more likely Claude is to mess up. You have to know when to compact a conversation, when to use a subagent, and when to start over. AI coding agents makes other parts of coding harder, like code review: you have to be the first reviewer of any pull request that you author with Claude Code.

I have to confess that my resistance to AI tools hasn’t only been because they sucked until Claude Code. I resisted them because emotionally, I was conflicted. I’m still conflicted. But I’m glad I pushed myself to try them. I don’t want to go back.

While it’s sad to see the craft of programming change like this, become mechanized like this, I do not mourn it in the way that some do. After spending years as a technical lead who never feels he has enough time to code, I am loving this. I can get so much done. And sure, part of that shift is my new job at Wealthsimple that brought me back to coding. But part of it is that I’m not fighting with compiler errors all the time. Claude Code is fixing them for me.

It’s fun. I wish I had stopped resisting sooner.

Here’s my practical advice.

First, you aren’t going to get left behind if you haven’t used these tools yet. I mostly skipped Cursor and that turned out to be great for me: a lot of developers are currently un learning their Cursor workflows in order to use Claude Code more effectively. So you won’t get left behind, but also, these tools are becoming more widely used. An entire generation of programmers is starting their careers never not having access to AI tools. You’re allowed to feel however you want about that.

If you have access to AI coding tools as part of your job then try them. If you feel self-conscious about how slow you are when learning how to use the tool, just tell your boss that you’re investing in AI tooling and they’ll probably love it. Your workplace wouldn’t be paying for your subscription if they didn’t want you to use it. Share what you learn with your team. Figuring out what the tools can’t do is just as important to learn as what they can do.

To learn what they’re good at, try using the tools as a first resort. Look for upcoming projects at work that are well-suited to these tools, like prototypes or timeboxed explorations. Use an AI coding tool as a first draft of your next task. Point your tool towards a gnarly bit of tech debt that you’ve never had the time to pay off, and ask it for a plan. Use the tools for what you want to do in your codebase.

It’s okay to mourn your craft. It’s okay to have complicated feelings about all this. And it’s okay to be excited, too.

The Over-Engineering Method

Sun, 15 Mar 2026 00:00:00 GMT

In Canada, “Engineer” is a protected term. I am a software developer, not a Software Engineer. There are valid reasons – historical reasons – to restrict who is a capital-E Engineer, but these reasons are at odds with how the term is commonly used today. Nevertheless, my job title was “Software Engineer” for seven years while I worked in the US, and I personally think that software development is best approached as an engineering problem.

Bill Hammack (aka The Engineering Guy) has an excellent playlist on “the engineering method”, which he defines as:

Solving problems using rules of thumb that cause the best change in a poorly understood situation using available resources.

Hammack’s videos describe the history of engineering, how it’s inaccurate to only think of engineering as applied understanding. How engineering is something done at, and just beyond, the edge of scientific understanding that advances that understanding.

I had some time off recently and wanted to reconnect to this engineering mentality, absent from code specifically. My 3D printer arrived recently, so I decided to apply some engineering method to my home office desk setup. My work-from-home setup is important to me – it’s where I spend a lot of my time. Maybe I’m also still traumatized from working in a one-bedroom apartment with my wife and two cats for ten months of 2020, maybe. Regardless, I’ve lived here for four years and I’m pretty proud of my setup.

I keep iterating. I recently tried multiple monitors, but it’s not a setup I work well with. I’ve settled on a laptop in clamshell mode on the desk, so it’s easy to access. I use an Apple Studio Display but I route a USB hub from the monitor for everything to connect to. The laptop just goes to the monitor. Unfortunately, I’ve run out of USB ports.

Also, it’s a bit messy. I’ve tried to make it tidier over the years, but I can still see the mess of wires under the desk. Especially at standing height. I don’t mind cables but I do mind mess.

I chose openGrid with UnderWare as a means to organize the cables under my desk. This is actually an area of active development in the 3D printer world, and there are more popular systems than openGrid. But I like the idea of an grid system built with desk organizing in mind. And it’s open source. I bought a new powered USB hub that someone had already designed an openGrid mount for. (The hub is powered so I can attach further hubs, if needed.) I removed a few things from the desk that I didn’t need, like a light strip and a network switch.

Instead of planning everything up front, I tried to make individual changes to move in the right direction. I started printing single pieces that I needed to cover the desk in a grid, and proceeded from there.

I learned some TinkerCAD and Autodesk Fusion. I learned that 3D printing “slicer” software is a whole different skill. I already had a working understanding of computer graphics and strong graphic design skills (for a programmer) so I wasn’t starting from scratch. I would guess that a lot of people getting into 3D printing don’t know what “world coordinates” are, for example.

I started by printing other people’s models, but soon started modifying them to suit my needs. I wanted to mount a light under my desk to use as a bias light (I didn’t like it behind my monitor) so I modified an openGrid part to hold some random camera part I had lying around, which has a 1/4" tripod mount.

The printer itself slowed down my iteration loop, which made it easier to be more intentional.

I confess that I went overboard a bit, and that’s okay. It felt great reconnecting to that problem-solving feeling on an intrinsic level, outside the context of coding.

My 3D printer is this amazing new tool that can solve a lot of problems. An overwhelming amount, actually. I’m now kind of surveying the different areas of 3D printing, letting my interests guide me.

There are still some cables you can see, but I’ve reduced this mess to its minimum. The remaining visible cables are the Thunderbolt cable for my laptop, and a Lightning and USB-C cable for connecting test devices.

Back at Artsy, I kept a pretty tidy desk. My approach remains to minimize distractions without being overzealous about eliminating distractions. For instance, my monitor arm has less wobble when it’s extended less, so the monitor is offset from the centre of the desk. I dislike that it’s off-centre, but I’ve done everything else I can to remove the wobble. And this does create a handy drop zone on the right, where I can set things as they come and go from the rest of the house (mostly coffee mugs).

The other night, I was walking up the stairs, and I found my office looking extra cozy. No cables, with softer light. This is exactly what I wanted.

Well, maybe not exactly what I wanted 😅 I’m thinking of 3D printing a cable chain to hide the mess of the power and ethernet cables going up to my desk. This project never ends.

Designing a home office is a fun hobby, and I’m grateful to have the means to pursue it. I’m headed back to work tomorrow, and I’m feeling ready to code.

Disintegrate, Reintegrate, Extrude

Sun, 22 Feb 2026 00:00:00 GMT

I wrote last week how my wife and I had to say goodbye to Clementine. Without going into detail, caring for our sick cat took a lot out of us. Since last summer, Clem needed some kind of daily medical care: ear drops, pills, special food, eye lube. Yes, eye lube. We wanted to help her get better. We only learned in November that she had cancer and only learned in January that there was nothing we could do.

A few years ago, a member of my family was diagnosed with terminal cancer. My wife was one of the primary caregivers, and I supported where I could. Taking care of Clementine brought up a lot of those memories.

The thing about taking care of a loved one while they die is that you still have to live your life. You have to go to work, and pay your bills, and clean your toilet, and everything else. And it sucks, because you want to spend all your time with your loved one. But spending time with them can also be difficult. It’s a lot. Clem liked to spend her days with me in my home office while I was working. Near the end and now afterward, my work days carry an extra burden. It’s been a tough year. (“Captain, it’s February!”)

At the end of my day, after taking care of my responsibilities, I was left with time but no energy. I know what depression feels like and I now notice when it starts creeping in. And I have skills to forestall it.

So. Last month. After playing Hades II for so long that my thumbs hurt as much as my heart, I was doomscrolling. I came across some discussion about 3D printing. Something in my brain shifted. I felt it, like it was some physical mechanism. “Huh. 3D printing. Hmm.”

I had been thinking of getting a 3D printer, off and on, since we bought our house. Usually, I’d let it go. I had other responsibilities and other interests that were taking up my time. But not lately. Lately, I’ve had time but not any interest. So when I felt that spark, I encouraged myself to follow it.

Sometimes it’s okay to impulse buy something to make yourself feel better. When the excitement of diving into a new hobby is the only joy you can remember feeling. When you’re actually glad that the thing is backordered because it means you’ll have something (anything) to look forward to for a bit longer. When you do want to keep looking forward, even as you also want time to slow down.

My wife and I have spent the last few weeks learning about 3D printers together, sharing models we want to print, and preparing a workspace for the printer. We’ve lived in the house for over four years now, which is longer than we’ve ever lived in a space. Preparing for the printer led to spring cleaning our basement, something we’ve been meaning to do. So we’ve built up some momentum, doing things, taking care of ourselves and our space and each other.

The printer should arrive this week. I’m excited. It feels good, to be excited. I’m cautious, too: I’ve learned the hard way how unwise it can be to hitch my mental wellbeing to the acquisition of things. But I’ve also learned how and when to work with my inclinations.

Goodbye Clementine

Tue, 17 Feb 2026 00:00:00 GMT

My wife and I said goodbye to our cat Clementine today. We had her for just four years – our time was cut short by cancer. Things have been up and down for months, but at the start of the year we changed priorities to keep her comfortable.

Clementine and her kittens were rescued from an abusive home by a local animal shelter. For the next nine months, her kittens were slowly adopted. But no one wanted to take Clem home until we found her.

I’ve had pets all my life and I’m very good with cats, but had never cared for an abused animal before. We took things slow. It wasn’t long at all until Clem came out of her shell. She never entirely shook off her experiences before the shelter, but she also came into her own here. She found her voice. She even made friends with our grumpy elder cat Bandita. She adored being pet and she had so much love to give.

I’m taking this pretty hard. It feels so unfair. We had so many plans.

But I’m also so grateful to have had the time we did have together. Clem came into our life right before a lot of things went very sideways. I’m still recovering from some of those experiences; Clem showed me what it can look like to grow past and grow with your trauma. My wife picked Clementine because she believed that I could take good care of her, and she was right. But Clem took care of me, too.

Clementine. Ms. Clem. We love you and miss you. We’ll never forget you. Thank you.

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.