Ash Furrow's Blog

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.

Work At Your Spikes

Mon, 06 Oct 2025 00:00:00 GMT

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

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

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

Spikiness

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

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

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

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

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

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

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

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

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

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

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

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

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

So what happened?

Early Stage Companies

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

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

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

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

AI and the Push Towards Average

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

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

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

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

Mid-Career Slump

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

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

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

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

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

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