TypeScript & Relevance

In our wide world of building for the web, we have every opportunity to talk about tools. We lunge to fill every gap we find in our projects with a definitive technological approach. Some of us are given “a seat at the table” feasting on even the most minuscule of technological debates. This marketplace of opinion is founded upon a desire to arrive, at least for the moment, at an optimum. We postulate about tooling so that we might achieve efficiency, extend our exploratory reach, or pave the quickest path to viability.

If you have read anything on this website, you are likely more than aware of the notion of Imposter Syndrome—the debilitating reflection that you do not deserve to be in the position you hold or know what you think you should know. Those of us that have learned to deal with Imposter Syndrome are at risk of slipping into (what I recognize in myself as) Relevance Syndrome—a mid-career complication of Imposter Syndrome. It is what happens when you spend years repeating the mantra, “I deserve to be here,” but have never truly accepted its premise. It happens when you attempt to counteract the softening of your hard skills and end up hardening your soft ones. Maintaining relevance sure is a great reason to opine about tooling.

---

With that, I will casually lean against this brick wall, slide my shades to the tip of my oh-so-relevant nose, and dismissively mention that yes, I too, have learned TypeScript. One year into the experience, and I can say that I have grown quite fond of it.

I’d like to use TypeScript’s purpose to make a separate point, so if you will, please bear with me through this quick example.

TypeScript, among other things, enforces the types of things you send around. Take this JavaScript function that multiplies two numbers:

const product = (x, y) => x * y;

Imagine you broke your rules by calling this function without numeric arguments like, product('A', 'B'). There are many ways you could validate this function to catch this scenario, but your validation would only occur at the time of execution—while the script is running, often in a browser. You can’t really debug this until those events occur. What TypeScript can do is tell you that you are breaking the rules before execution — as you are writing your code. To do this, you state which types of things you are using.

const product = (x: number, y: number) => x * y;

Here, we specify types for the two arguments, saying that variable x and y are both a number. Now, if you were to use this function with the wrong types of arguments, your application script would loudly fail to build. Because your script must work before it can be built, you never need to worry about these sorts of errors ever occurring in the wild. It takes a lot of effort to achieve this, however. You must define your types, everywhere.

I’d like to think there is as much capacity for value in a well-organized bookshelf as there is for ingenuity in an independent spirit, and there is so much to learn from both.

---

Let’s end with considering relevance again.

You may feel pressure to know what you are doing before you do it—to type yourself before your code executes. You may feel pressure to account for all your failures and learnings before you give it a go in public. That, my friends, is an immense effort you have taken on to maintain your type. It is a pressure and rigidity that, at times, is great to put upon our software, but is unfair to apply to yourself or others.

We all have our "1" + "1" = "11" moments. They are relevant and entirely human, if not a form of genius. Embrace them. To strictly prevent them is unscalable.

I feel in this moment that I may have learned how to learn TypeScript this year, and hope to hold on loosely to whatever type that makes me.