Ash Furrow's Blog

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 managed 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.

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.