I’ve seen many codebases, products, component libraries, and pitch decks over the years, and I’ve noticed that everyone wants to be unique.
Everyone wants to figure out how their product can stand out and be better or smarter than the competition. They want to find a way of being different that will make their user or developer experience top-notch.
Folks tend to go for the same approach: ‘Hey everyone, look at our super-creative way of doing something you’ve totally seen before’.
And that’s fine, even clever sometimes.
This approach has pros, like the chance you might establish yourself as a brand maker, thought leader, or mind changer. Perhaps you’ll be the next React, influencing how websites are built on a grand scale. Or perhaps you’ll get the recognition of Uber or Lyft, changing how people trust and interact with technology.
But, the cons of this approach are also significant. The irony is that if you try too hard to make your product novel and new, it might not be memorable. If people have to constantly remember what your special version of something is, then… is it worth it?
I’m going to share a couple of examples of successful products that prioritize familiarity over uniqueness, and explain why you should be having this conversation with your engineering teams regularly.
Being instantly understandable is an advantage
The familiarity advantage isn’t an entirely foreign concept for technical organizations. A great example is the Astro web framework. In its earliest versions, it had a Collections API and very solid docs on how it worked. It provided a way of defining page routes for a website and populating those routes with data. This is a concept that exists in nearly all similar site-builder frameworks.
But, in later versions, they ended up renaming a lot of that Collections API to getStaticPaths. The new function name is not special, nor is its functionality. It’s exactly what Next.js does. It’s not branded. But, as a developer, because I’m coming from Next.js, I know exactly what this function is for; it is self-explanatory for me as a user.
Having something that feels self-documenting is great because you don’t have to educate your users as much as you would with a brand new system of ideas for accomplishing the same thing. It might not be unique to the framework, but it’s almost instantly understandable.
Think about how startups pitch themselves as ’Uber for Dogs’. The startup Supabase dubs themselves ’the open source Firebase alternative.’ People know exactly what they are and what they do, which is a huge advantage in our competitive field.
It might be worth considering these trade-offs of being unique versus being familiar when building a new product/library/project/etc. If your actual feature is totally and completely new, that’s a great time to coin a new term and educate others on what it means. But, if it’s reflective of something that already exists, it might save you some time and energy to mirror what else is out there.
Source: XKCD Standards
Reflections
In A Philosophy of Software Design, John Ousterhout teaches a key principle: make your code intuitive overall. When you’re making developer-facing products, you want to make your documentation, APIs, and concepts intuitive as well. If you can do that with completely unique names or components or packages, great, but take some time to think through how your users will respond to that first, and run with it.
