In 1989, when I was eight, I started learning Logo and Basic programming on my Coleco Adam. I was absolutely fascinated to realize those video games like Buck Rogers were made with the same programming tools I was learning! I wanted to learn how to make computers do things like that.

In 1998, when I was seventeen, I had my first job at a movie theatre. On my break, I would fantasize about starting a web design company. I wondered if I could charge $10 per page. Maybe that was too much to ask?

In 2001, when I was twenty, I got my first real programming summer job while attending the University of Waterloo. I learned ColdFusion and web development. I got to design and build an entire Content Management System. I even spoke at a couple conferences and was published in ColdFusion Developers Journal. I loved this world and knew that this was exactly where I wanted to be.

The first pivot

As much as I loved coding, I saw my bosses spend their time in meetings and writing emails, and I felt like they were superior to me somehow. In 2005, at twenty-four, I moved to Berlin, started this blog, and bought Consulting for Dummies. I wondered if maybe consulting work would be a step up the success ladder. I started freelancing, and everyone only wanted to pay me for coding. Since that's what I loved to do most, I didn't complain. I unpivoted, and thought I'd revisit the consulting idea another time.

The second pivot

My freelancing business grew, and I had to say "no" to a lot of people. Then I read "The E-Myth" and Peter Drucker, and decided my company needed to grow. At some point I had a dozen developers working for me, and even hired a Project Manager or two. I was able to say "yes" to everyone. I had pivoted to growing an agency, moving closer to this idea of success I kept reading about.

Then it stopped being fun. I would start off chatting with a new client, but turn it over to a PM when it started to get interesting. I was juggling so many projects in my mind, I barely had time or energy to do any coding. It felt like driving a car from the backseat.

One time, I had a developer stop answering emails, and had to jump in to save the project. I read through weeks of emails back and forth between the frustrated client, the project manager and the overwhelmed developer. The project became clear in my mind and I quickly built exactly what the client wanted in a weekend. I was back in the driver's seat, working directly with my client to build a web app.

I decided to unpivot. I stopped hiring. I sent my developers off to work with some of my clients directly. I wound it all down until it was just me building for a few good clients. I was back on the path again.

The third pivot

I'd always wanted to be a teacher. I was thrilled when my friend invited me to teach a programming course at Georgian College. I poured myself into teaching and loved everything about it. Even though I was teaching part time, all the prep work and marking really cut into my freelance work, and my income. At the end of the term, I asked my wife to remind me that I should probably say "no" next time.

Of course, I didn't say "no", because I was thrilled all over again the next time I was asked. And the next time. And the next time. I taught a half dozen classes over the next years, and absolutely loved helping students. I loved thinking about how to explain programming concepts to my students.

But I was spending so much time creating assignments and tests, and marking the students just to give them an arbitrary grade. I loved teaching, but I was never passionate about the college system. I decided it wasn't worth it anymore and unpivoted again.

The fourth pivot

The teaching itch never left me, so I decided to start teaching online. That way I could help students directly without all the tests and marking. I started making YouTube videos, streaming on Twitch, and even developed and launched a video course, The Joy of Svelte. I started a newsletter and imagined this as the start of a series of courses.

Making a course took a lot more time and energy than I expected. It was also missing something from teaching students directly in the classroom. I was procrastinating my course development and spending all my time coding for clients. I felt bad about this, like I was stuck in a rut. Eventually, I realized I wasn't stuck at all. I was doing the thing I loved the most, helping people directly.

I stopped feeling bad about it, and let go of pressuring myself to be a course creator. I had unpivoted back to focusing on the thing I love the most, working directly with clients to build web apps.

The fifth pivot

I was watching YouTube videos and listening to podcasts about business. They talked about "hands-on" work as being undesirable. These motivational speakers made me feel bad for wasting my limited time coding when I could be helping more people with my knowledge and experience. They convinced me the only way forward would be to pivot away from coding and to focus on being a coach & consultant.

I put on a blazer, had business cards made, and attended a tech conference. I told everyone I was like a "personal trainer for developers". I had this vision of using my experience and teaching skills to help development teams.

Every time I worked with a team to coach them on how to build or fix things, I ended up just building prototypes for them. I found it way easier, and frankly more fun, to build things instead of just telling people how to do it themselves.

I realized the best way to help people was the way I always had, by building things for them directly.

Learning by experimenting

I learned that I crave challenge and novelty. With each pivot, I followed my curiosity, or my insecurities, and tried out something new. Even when it didn't work, I learned something new about myself.

Each time, I'm glad I only experimented by dipping a toe in the water and never dove in completely. I'm grateful for those clients that stuck with me from the beginning, some of whom I'm still working with to this day.

Having gone through this cycle so many times, it's now comically clear that I've always done exactly what I should be doing. I'm a Web Developer, I build web apps for my clients, and I've been doing it non-stop since 2001.

I've stopped looking for greener pastures, and can now see how wonderful things are right now. I don't need anything different. I get to do even more of what I love, what I've always loved.

At least until the next pivot comes along.

The great thing about the web is that web pages from thirty years ago still work fine. So you can imagine how surprised I was when a new version of Chrome broke my client's web app in production.

Business as usual

The web app is a data visualization tool with a colourful d3 SVG map. Hovering over a country brings up a tooltip, and clicking a country brings up a larger panel with data. Although the application was originally developed in 2013, I took it over in 2022.

I was working on some changes to the web app a couple of weeks ago. I run Linux (Arch btw) so I always have the latest version of everything, including Chrome. I spun up the development site one day and suddenly the map tooltips and clicking stopped working.

Did I install something new that broke the interactions? Maybe one of my Chrome extensions was messing with something? I tried rebooting, as one does when they're out of ideas. Still didn't work.

I loaded up Firefox. Everything worked fine. I grabbed my mac and tested it out in Chrome. Everything worked fine there too. I sent off my changes for the day for my client to review, and they didn't say anything about it being broken.

I could have left it at that, but it didn't sit right with me. That evening I started digging into it more.

Classically debugging a hard bug

First thing I did was add console.log statements to the d3 event handlers.

I could see that the mouseenter and mouseleave events were working, but the mousemove and click handlers never fired. I tried remove the mouseenter and mouseleave handlers, and suddenly the mousemove and click started working again.

I put back the mouseenter and mouseleave and looked for something that could have been responsible. Then I found this suspicious line:

// bring it to the front and maintain full stroke
path.parentNode.appendChild(path);

I removed it and it started working again! But that line was written six years ago, before I ever worked on the app. Why would that be to blame? What changed?

It Is Never a Compiler Bug

There's a trope in programming that "it's never a compiler bug". As a web developer, we would say "it's never a browser bug". Well could it be this time?

I was running Chrome v144 so I found the release notes. It came out on January 13th, so the timing made sense.

I scrolled and skimmed and finally found something that sounded like it might be relevant:

Interoperable pointer and mouse boundary events after DOM changes

After an event target is removed from the DOM, the logical target of the pointer, as implied by the Pointer and Mouse boundary events (that is, over, out, enter, and leave events), should be the nearest ancestor still attached to the DOM.

This led me to find a bug filed for Chromium v144, Regression in Chrome 144: Moving event target in "mouseenter" handler breaks click+mouseleave events. It was a Chrome bug! The example code even matched mine almost exactly:

redSquare.parentNode.appendChild(redSquare);

It seems like this is a permanent change due to a refinement of the spec. It's apparently a feature-not-a-bug, called BoundaryEventDispatchTracksNodeRemoval, so it's probably never going to be fixed.

There's fortunately a suggestion in a comment of how to fix this on my end though:

if (elem.parentNode.lastChild !== elem) {
    elem.parentNode.appendChild(elem);
}

Makes total sense! I made the change, and everything was working just as it had been a couple of weeks earlier!

Always trust your gut

I'm going to resist blaming the browser next time I have a bug, but it's very interesting to be reminded that it can and does happen.

The important takeaway is that when I see something wrong on a client project, I'm not going to be able to rest until I figure out exactly why. I needed to be sure it was limited to my computer, because if it wasn't, the last thing I'd want is for my client to find out from one of their users.

I of course pushed the change that night and let my client know what had happened, and that the production site was already being affected. Fortunately, v144 hadn't been fully rolled out. Even as I write this, less than 4% of users are running v144. This also underscores the importance of developers testing using the newest versions.

As a developer, I always want to fix bugs before my client notices, and definitely before their users notice.