Blag

After nearly a decade of waiting, Temporal finally reached Stage 4 last week. Getting here was a monumentous task by many very smart people to fix difficult and complex issues with the web platform.

There are a lot of useful features that I'd like to take the time to write about at some point in the future.

Instead of doing that, I'm going to complain about some weirdness.

PlainYearMonth is weird.

Or maybe PlainYearMonth.prototype.toLocaleString is weird?

Or is it that DateTimeFormat handles PlainYearMonth in a werid way?

I'm not sure which. It's weird.

If you've ever needed to stack things in CSS, it's very likely that you've seen code that looks like:

.a {
  z-index: 9001;
}

Here you can see the z-index is set to an obscenely large integer value.

This strategy for managing stacking order is largely based on hoping that it will work, and luck.

Unfortunately, luck isn't a strategy, and items stacked in this way often result in a cascade of changes where developers progressively increase z-indexes until things seem to work.

.b {
-  z-index: 8000;
+  z-index: 9002;
}

.c {
-  z-index: 8500;
+  z-index: 9003;
}

When building apps with large complex datasets, a common problem while testing is that a component may interact with many parts of the application state.

When this happens, it's inconvenient to have to stub out the full application state in every test.

There are a variety of approaches to this problem, each with its own set of tradeoffs.

Using deep partial data with mock functions is one of my preferred ways to make testing easier.

As with any large system built by a many contributors over many years, the Web Platform has many small mistakes, inconsistencies, irritating behaviors, and missing features. In smaller scale systems these bits of technical debt accumulate over time and some are occasionally even fixed.

Unfortunately due to the requirement of backwards compatibility, many of the things that bother me about building on the web can never be fixed or changed.

This post is a place for me to vent list the changes I might make if I could.

The way to determine if you value something is by determining how much you're actually willing to pay for it.

In September of this year I had the unfortunately common experience of being laid off from my job.

Soon after I began the process of applying for new positions, which resulted in receiving many rejections from the companies I'd been applying to.

I'm used to the format of rejection emails, but being told you're "not quite the right fit" or that "other candidates are a stronger match" is never pleasant.

That is, until I received a rejection from Zapier. It was the kindest, most thoughtful rejection I've ever received in 17 years of being a software engineer. Even though it's still a templated response, it shows empathy that is lacking from most businesses these days.

Over many years of reading other people's code I've developed a system for how I conduct code reviews.

Many people have praised me on my code reviewing skills, I'd like to share my approach so that others may benefit from my experience.

That's not to say that my approach is perfect. While I've been using this approach for over a decade, I still make occasional changes when I find room for improvement.

Responsive horizontal navigation solutions can be challenging when different amounts of content might exceed the available horizontal space. Six to ten links might fit fine on a large screen device, but then overflow significantly on small screen devices.

This post covers one approach to solving the problem, where links that would overflow are automatically moved to a dropdown list.