It’s also a deeply frustrating game to play. It’s a team sport, but one where abject individual failure is almost guaranteed, particularly as a batter. The first scenario is you won’t actually be required to bat, because the batters ahead of you were good enough not to get out within the allotted number of overs. This is frustrating when you’ve spent the week practising or thinking about how you are going to play differently to the last game. The most common option is you get out to the middle, then get out, and have to trudge with a number of runs that you’re either content, or almost always, disappointed with. And in some very rare cases, you may still be in at the end of the innings, where you’ll likely be rue-ing not taking more risks and scoring more runs.

And yet, thousands of individuals put themselves through this pain each summery Saturday afternoon because there’s something addictive about bettering your score. It’s a sport that’s instinctively gamified, chock full of stats & averages.

Before Jacob was born, I was roped into playing for the local team. I was pretty terrible, but lucked one or two okay scores in the first season. The team weren’t too fussed as I was, and I quote, “another body on the pitch”. Despite a winter of practising and weekly summer net sessions, the second season was not any better.

After three years of absence, I was roped into another game on Saturday. I spent the week fretting, then preparing, then looking forward to it. I visualised exactly how I’d defend those first 10 or so balls to make sure I got my head back into the game. I went to the local nets with my wife and was very pleased with how solid my forward defense was, and even managed to showcase a few attacking shots with confidence and low risk.

And then the moment came where I strode out to bat. Expectations low, but with a real hunger to get off the mark and contribute something to the team. In came the first ball; a nice straight one. “Forward to it”, I thought; “head over the ball”. The bat came down to prod it back gently to the bowler, and all I heard was the rattle of the wooden bails behind me. To say I felt dejected would be an understatement. It wasn’t the game situation, nor the fact that family and friends were watching. It was the crushing realisation that cricket is not the game for me. A game I love to watch and dig into the nerdy details, and a game I so want to be good at. But it’s not happening.

I walked off and looked at my little family sitting on the boundary rope. My wife and I shrugged at each other and I headed back to get changed. I spent the rest of the innings in the park with Jacob, playing hide and seek and helping him up the climbing frame. It was wonderful.

I’m a much better Dad than I am cricketer, and that’s okay. I don’t need to spend my (and my family’s) Saturday afternoons getting mentally crushed by a game. Hobbies are good, particularly active ones, and I need to find a replacement. But I’ve got to the point of acceptance. Cricket’s not for me.

Through lunchtime chats, off-hand comments and a growing number of DM’s, it’s becoming clear that, although the AI propaganda is loud, it’s not landing with a great deal of engineers on the ground. Many I’ve spoken to appreciate its use within a niche set of circumstances, but I could count the number who’ve actually drunk the koolaid on one hand.

And yet, within a tech company, it’s taboo to voice any form of healthy scepticism.

If you are an engineer and your boss asks you:

Hey, you’re getting 10x the productivity thanks to AI, just like all the other engineers, right?

You are strongly incentivized to say yes. And when every other engineer also says yes for the same reason, that CEO isn’t lying, they are just relaying what they heard.

No, AI is not Making Engineers 10x as Productive, Colton Voege

But when the rhetoric is “your very livelihood is on the line if you don’t subscribe to this brave new world”, we really should be able to discuss this in the open.

Regardless of whether you believe AI is coming for your job or not, navigating any existential threat alone is exhausting. It’s time to re-read You Deserve a Tech Union and plan a forum for these discussions…

@media (min-width: 60em) {
  /* above and including 60em */
}

@media (max-width: 59.9375em) {
  /* below 60em, but not including 60em exactly */
}

If you want to tidy that up, and continue to support <= Safari 16.3, you can use a query like this:

@media (max-width: 60em) and (not (width: 60em)) {
  /* below 60em, but not including 60em exactly */
}

However, if you’re bought into range queries, it all becomes much, much simpler:

@media (width < 60em) {}

I spent a couple of hours working through my notes and writing up a review before sending it to my manager, awaiting their equivalent review for me.

However, the review I received back was, quite simply, quintessential AI slop. All the tell-tail signs were there—words like “pioneered” & “spearheaded” peppered throughout, no personal detail, and most of all, a complete regurgitation of what I originally wrote in my review. You see, managers ask to see your review before you submit so “we can submit a unified message to the business”, and you can quite quickly join the dots on what happened next (hint: it involved a bot called Claude & some cmd-c and cmd-v).

Without any context of me as a person, AI decided the best way to set personalised goals for me, was to fire back what I’d written but on steroids. When I wrote about “component migrations ahead of a React 19 upgrade”, AI wrote: “Trys should spearhead the React 19 upgrade project”, missing the fact that the project already has a feature lead. When I wrote about having an interest in improving our frontend stack, AI wrote “Trys should write a frontend strategy document for the company” - not exactly a task for a lone engineer, eh? There was no insightful feedback or contextual suggestions, just an A4 page of vagueries.

This is not a pop at the individual manager. I get it, if you have 15 reviews to deliver in a week and there’s a tool that takes all that pain away, that tool’s going to look pretty seductive. And I know it’s not just the managers. When the review deadline looms and you’ve not had a minute to reflect, let alone write, I’d wager a hefty sum that a good proportion of employees are submitting their reviews from bullet points via an OpenAI server.

But when you get to the point where both parties are using AI, you might as well pull the facade and send bullet points to one another. I’d rather read that than a wall of slop. I’d rather read the prompt. And I’d take a single ounce of humanity over a full time AI manager, any day of the week.

As enshittification increases, and slop becomes the norm, my feelings towards so-called AI are not ones of fear, but of pity and disappointment. These models claim to be able to create, or to increase our creativity. They can spin up a wonky clone of a song, picture or site in a matter of seconds, which without basic scrutiny might appear initially impressive. Heck, you might even be able to vibe-code an app in a weekend (although best of luck maintaining that), but in doing so, you’re missing the entire point. The joy is not in the product or the end result, but in the craft.

It’s in the prefers-reduced-motion query, or the elegant custom property that removes a bulk of nesting. It’s in knowing that all users will get the best experience for their device & environment, because you put the time in to make it so. It’s in winning the fight for server-side over client-side AB testing, because you know it makes a difference. The joy is in the well-planned & anticlimactic go live, the microinteractions you snuck in, the encapsulated & deletable component, and the extensible grid system you know will be a joy to work with well in the future. It’s in the craft. The meaning is in the making.

No prompt or koolaid-infused-workflow will bring that joy.

Sure, it’s quicker to e-bike a parkrun, and if you’re as unfit as I am, will be a darn-side easier. You’ll finish 10 minutes ahead of the pack. You might even feel the most fleeting sense of unearned achievement. But you won’t feel that same satisfaction as the person who put in the hours, pushed themselves to their limit and crossed the line under their own steam.

That’s what makes me want to create. It’s what makes me want to build & share, to learn & teach. It’s the web that I fell in love with, that captivated me as junior developer, and what keeps me fired up to this day.

Spreadsheets are a passion of ours, so of course, we began tracking our visits, most importantly capturing how much it would have cost if we paid for each visit. Last week, after only 39 months, we broke even.

Breaking even is a little tenuous, as it’s pretty unlikely we’d have visited all these properties if we didn’t have membership, and even if we did, we’d have bought annual memberships (which takes about 12 years to pay off). But it’s a bit of fun to see how much we’ve saved.

A couple of months ago, I spotted a used one for a very reasonable cost and I just couldn’t resist. It arrived, and it was immediately clear why professionals used this—it’s an absolute tank of a unit. It’s 8KG and made of thick aluminium. The processor is removable and rackmountable. And it looks like a Christmas tree. I love it.

What’s super interesting is how it has clearly inspired the design of modern processors. Sure, there’s no touch screen and the LCD strip is dated, but there are also no buttons or switches to get broken on the road. You navigate the menu by twisting the footswitches themselves, which was way ahead of it’s time.

It doesn’t have any amp/cab modelling or drive effects, so amazingly, the sounds haven’t dated at all. Chorus hasn’t really changed since the 80’s, so they still sound great on a unit from the 00’s. It merrily fires out relay switches to change channels on my amp, has four powered effect loops for drive pedals, and is effortlessly controllable via MIDI, which I used in a gig at Christmas.

I’ve ended up selling my Strymon & Walrus Audio gear and have fully committed to this now historic (and in my opinion, timeless) piece of kit.

In doing so, I now realise that I’m very much getting old and nostalgic, not for things I had in my youth, but for things I couldn’t afford at the time. Next thing you know, I’ll be driving a Renault Avantime…

The filled box

The ‘simpler’ use-case is the filled box. Bennett Feely’s Clippy continues to be the best tool for the job of generating clip-path shapes, and even has ‘left/right point’ options. Clip-path gives us a pointy edge, but doesn’t give us rounded edges, or a particularly responsive solution out of the box - wider screens will have a more pronounced point than smaller screens when using percentages:

.box {
  clip-path: polygon(0% 0%, 75% 0%, 100% 50%, 75% 100%, 0% 100%);
}

To improve the point, you can use calc with clip-path to determine where the point starts/ends. border-radius gets us some roundedness, but only on the flat edge, not on the pointy edge:

.box {
  --point-inset: calc(100% - 2rem);
  clip-path: polygon(0% 0%, var(--point-inset) 0%, 100% 50%, var(--point-inset) 100%, 0% 100%);
  border-radius: 1rem;
}

To properly round this out, we need to employ a lesser-used bit of SVG: <feGaussianBlur>. There’s a wonderful article by Temani Afif that explains the technique. This snippet can be popped at the bottom of your page, and sits there as an invisible SVG.

<svg height="0" style="position:absolute; visibility:hidden" version="1.1" width="0" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <filter id="rounding-filter">
      <feGaussianBlur in="SourceGraphic" result="blur" stdDeviation="5"></feGaussianBlur>
      <feColorMatrix in="blur" mode="matrix" result="goo" values="1 0 0 0 0  0 1 0 0 0  0 0 1 0 0  0 0 0 25 -9"></feColorMatrix>
      <feComposite in="SourceGraphic" in2="goo" operator="atop"></feComposite>
    </filter>
  </defs>
</svg>

We can then apply this filter to our box and it will round the corners of child elements. Change stdDeviation to increase/decrease the amount of rounding.

.box {
  filter: url(#rounding-filter);
}

.box > * {
  --point-inset: calc(100% - 2rem);
  clip-path: polygon(0% 0%, var(--point-inset) 0%, 100% 50%, var(--point-inset) 100%, 0% 100%);
}

The outlined box

Outlined boxes are a bit more tricky. You’d think it would just be a case of swapping background for a border, but alas not. Again, because this filter works by blurring the edges of the component, all borders effectively disappear. To compound the problem, box-shadow: inset, filter: drop-shadow() also get blurred, and clip-path and border do not play nicely (subtle background added for effect):

The best solution I found was to employ an additional SVG element an append it to the right-side of the box (as demonstrated by the orange flashing line).

<div class="box-wrapper">
  <div class="box"></div>
  <svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="none" fill="none" viewBox="0 0 127 478">
    <path stroke="var(--theme)" stroke-width="1" d="M0 477h11.33a15.5 15.5 0 0 0 14.17-9.22l98.67-222.51a15.5 15.5 0 0 0 0-12.56L25.51 10.22A15.5 15.5 0 0 0 11.34 1H0" vector-effect="non-scaling-stroke"/>
  </svg>
</div>

.box-wrapper {
  --theme: rebeccapurple;
  display: grid;
  grid-template-columns: auto 3rem;
}

.box {
  border: 1px solid var(--theme);
  border-inline-end: none;
  border-radius: 0.5rem 0 0 0.5rem;
}

Closing note

You may be asking yourself, why not just set an SVG background image and have done with it? Well, if you want control over the corner rounding, triangle size, and most importantly, stay responsive to differing viewports and quantities of content, then this is probably the way to go. If the requirement is for a simple empty box, then an SVG directly in the DOM is a simpler bet.

On March 17th, we successfully and smoothly launched the refresh to 16 web and native applications. I wanted to share some lessons learned along the way.

The importance of a design system

Unsurprisingly, the biggest asset in this project was our solid design system: The Highway Code. Since 2022, a small team of dedicated designers & engineers have cultivated this system, ensuring it does just enough, but not too much. This atomic and foundational system allowed us to fundamentally refresh our wider visual language and update our components.

I cannot stress how impossible and painful a task this would have been without this design system. Speaking of…

The pain of frontend tech debt

Design systems can only be the panacean “single source of truth” if they are the only source of truth. Our reality is three design systems: The Highway Code, and two legacy component libraries that have never properly been deprecated. Totally removing these libraries wasn’t feasible in the time we had, so compromises had to be made.

Firstly, all legacy colours & typographic references within consuming applications were removed and replaced with references from The Highway Code. We could release this change long before go-live day safe in the knowledge that when the design system was updated, all colours & typography would also be updated. We also updated as many legacy components to use The Highway Code as time allowed, again, reducing the risk of functional changes on go-live day.

In a bid to reduce the number of application launches needing to be synced up, I opted to use CSS custom properties & fallbacks to control the legacy library components from The Highway Code. For example, a legacy multi-select component needed a border-radius update, so I wrapped the existing value in a custom property:

.multiselect {
   border-radius: var(--thc-input-border-radius, 4px);
}

This meant I could safely pre-release the (admittedly quite flaky) legacy systems, safe in the knowledge that no visual changes would occur until The Highway Code updated that custom property. It’s not perfect to form this tie, but as a stopgap until the legacy systems are deprecated, it worked pretty well in reducing launch risk. Along the way, we also removed 20% of the legacy components, which was a nice bonus.

The challenge of ambition

The “easy” option in a brand refresh is to just update colours & typography, slap on a new logo, and call it a day. But that didn’t sit right with us. Brand refreshes are pretty unique opportunities to focus on UI over user flows & product features. Although we didn’t want to touch fundamental UX patterns, we did want to use this opportunity to improve accessibility, performance and usability through good UI practices.

We improved colour contrast, typographical hierarchy and legibility, reduced page weights, and simplified a good amount of visual clutter. We sweated the details on animations, iconography and micro-interactions, and even made some fundamental and scary changes to our space & typographical design token naming conventions, knowing that the opportunity to touch every CSS file doesn’t come around often.

Naturally, I also used it as a trojan horse for some fluid CSS.

The benefits of prioritisation

The design team was given a divergent brief to apply this brand refresh, which led to a huge quantity of design ideas that gradually converged to a consistent but ambitious design language update. In a product as large as Motorway, we had to be ruthless in the rollout prioritisation.

Estimating on an evolving design across 16 applications is a tricky task. Understandably, executives like to know what would be shipping on the 17th March. We knew we couldn’t build everything, but, as mentioned before, also had the ambition to go well beyond just colours and typography.

Using a ‘MoSCoW’-esque exercise (Must do, Should do, Could do, Won’t do), we set about categorising the biggest design changes into P1’s, P2’s & P3’s. We committed to completing all P1’s by the 17th, building from there if time allowed.

Foundational design system updates were all P1’s, as was the application of the updated system to all consuming services. It was important to me that no system got left behind, including internal ones. For consumer-facing services, we committed to updating home, account and vehicle profiling flows, and for dealer-facing services we updated all logged out pages, and the key bidding screen. I’ve seen enough brand refreshes in my time to know that patchy or half-baked design rollouts are glaring and abrasive.

We felt quietly confident that we could complete the P1’s and make good headway through the P2’s before go-live. Under-promising and over-delivering always pays off in these scenarios.

However, the challenge with a list of categorised line-items, is its still pretty hard for executives to see what will actually be going live…

The power of a good demo & release candidates

With the design team creating the “visual north star”, we didn’t want to spend precious design hours mocking up interim views, especially if we felt we could get through the P1’s and onto P2’s & P3’s. Thanks to the design system & our CI setup, we were able to produce release candidate versions of the system on every commit, and apply that to our key consuming applications. So rather than Figma-ise a make-believe middle step, we could render exactly what the product would look like if we did nothing more to the product, other than apply the design system update.

We could then side-by-side the “north star” and the “worst case scenario” and present it to the executive team, explaining that all P1’s would be at the north star level, and P2/3’s would look at least as good as the release candidate application, and almost certainly better. This calmed all nerves and got us the green light to proceed without wasting any design effort.

These release candidates then served as consistent staging applications that could be shared widely with the team so there were no surprises come go-live day.

The guard against conversion

We were naturally very cautious about the potential for conversion impact in this project. With the best design intent, user research and data in the world, there’s still no guarantee that a design refresh won’t have a negative impact on conversion. To mitigate this, we ran a number of A/B tests ahead of the launch, testing any functional changes before the ‘big day’ so we could be sure the new designs were at least at parity with the old ones.

The importance of a solid release process

As we approached go-live, we’d completed all P1’s, all P2’s and a good number of P3’s. Our release candidates were in a great place, and we’d reduced risk as much as possible. The final step was to create a solid release plan.

No-one likes big-bang releases, but for a project like this (one that used so much SCSS & CSS), it was impossible to use feature flags. We spent time with product managers to understand what features were being rolled out as we were building to ensure they were all visually compatible, and we merged main into the 16 release branches daily to reduce conflicts. Through All Hands, and regular Slack messages, we communicated the go-live plan with the whole company, informing when code freezes would come into place, when the release would happen, where they should report bugs/incidents, and when code thaws would take place.

Each application had a bespoke go-live checklist, with links to the pull request, release candidate and relevant product dashboards, and a visual ticklist of each step that would need to take place on the day.

On the big day, we methodically worked through each checklist, and got through all 16 applications in a matter of hours. There were no hiccups, challenges or downtime—it was all incredibly calm and smooth. We watched the numbers like hawks over the coming days and saw no negative conversion impact whatsoever. A week on from the launch and we all breathed a sigh of relief and celebrated a job well done 🍾

The ideal job for a design engineer

This project was perfect for me (and would be for any other design engineer). There was a huge degree of design ambiguity, as well as a lot of plates to spin. Touching every CSS file and changing every page is no small beast, and potentially one that a “software engineer” would shy away from, or wish to break into smaller chunks.

But for a design engineer, it was an absolute dream. Designers and I were able to rapidly iterate in the browser, using design & engineering sensibilities to quickly make decisions and avoid wasted Figma time. I absolutely love being the glue between design & engineering, and this project was a perfect example of how that can work in practice.

This post is getting long so I might follow up with another going into some of the design details and fun engineering challenges we faced along the way.