Blag

I've been building websites for twenty years.

In that time I've had the same conversation about cursor: pointer far too many times. It's my own fault really that I haven't taken the time to write up a good answer once-and-for-all. I did post some details a decade ago, but I never took the time to write things out in a shareable fashion.

The conversation usually comes up when I build some sort of interactive component and someone asks me a question along the lines of:

Why didn't you add cursor: pointer to that button/tab/checkbox/[insert other word for clickable thing here]?

The short answer is, "it's not necessary".

The long answer is…the rest of this post.

A colleague recently shared "GitHub's Historic Uptime", which is a visualization designed in a way that highlights the significant increase in instability with GitHub's services since Microsoft's acquisition in late 2018.

At first glance the contrast is glaring, but on closer inspection one might notice that the y-axis starts at 99.5%. Adjusting the graph to show the entire range from 0-100% would make the graph appear flat.

Does that mean that I think the Microsoft acquisition wasn't a significant impact on GitHub's services?

No.

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.