programming posts

In a previous article, I discussed Surfaces as an abstraction on APIs and how we could measure complexity as the size of that surfaces' perimeter – the "visible" part of the API to consumers. I shared this article with a colleague who I was actively working closely with on a new implementation of a design system. They has some interesting feedback on different ways of reducing complexity of certain APIs that I felt compelled to revisit this topic.

I've discussed full and partial objects before on this blog, and in this article I'm going to investigate a common factory pattern in Typescript that can lead to type-holes. When writing tests or complex components, I'll often create prop factory utilities.

We all know that naming things is right up there in the top three most difficult things about programming, right next to concurrency and caching.

Maintaining growing software is challenging. Poorly architected APIs and incorrect abstractions can significantly impact the ability for engineering teams to deliver new features in a timely manner. If we consider an API's complexity as being a significant contributor to its overhead, maintainability, and ease of use, then it becomes a question of how do we best measure this complexity so that we can make informed decisions about how to refactor and improve our APIs.