Learning to love the type checker

The type checker isn’t your enemy at first. When you write hello world in your new typed language and you try to pull a fast one. You pass a number in where it’s expecting a string and just double check the checker. Is it really paying attention? Then a little later you legitimately make a silly mistake and it catches you still—good one you!

No, you hate the type checker when you’re trying to get work done and it just won’t damn shut up already! This is perfectly good code! Or maybe you’ve made a little typo. Do you really need 8 pages of compiler errors telling you how a module you haven’t touched in 4 days isn’t happy either? Really?

In most languages (a few lovely ones excepted) the errors are just awful, too. Sure, you can pick through them. Maybe 50% of the time figure out what they’re really whining about, but it’s a mess.

Is this really anything anyone recommends? Is something so miserable really worth the high praise?

Well, no. There’s a different way that experts use type systems.

Lean in to make types work for you

The secret to loving the type checker is to use it way more often. You should be running a check every one to three changes you make.

Why does that make sense? On the surface, it feels like a recipe for even more pain.

Running the checker often does a number of valuable things. It dramatically limits the places in your code where the error might be coming from. You usually won’t even have to read the error messages if you know that they relate to a small change. The type checker is just giving you a skeptical look—are you sure what you just wrote makes sense?

It reminds you just how cheap type checking is. If type checking weren’t cheap then it would not be worth it. Type validation is a fast, partial check on correctness. If you really lean in to that it becomes one of the fastest feedback loops at your disposal. Often your feedback loop is the bottleneck is good coding practice. So, a new, ultra fast feedback loop can be just the thing to dramatically improve your craft.

(As a side note, some languages are pretty slow at this anyway. Tools like IDEs and Language Servers can help to increase the speed of the type checking feedback loop. They are highly recommended if you find yourself tripping over the type checker feedback loop.)

Conversing with the type system

Finally, there’s a change in mindset that occurs when you practice working in fast feedback loops with the type checker. You stop treating it as a referee telling you when you’re wrong and instead treat it as a copilot. A common feeling people get is that they’re having a conversation with the type system. You can speculate a change and see what the type checker thinks. You can guess at a type and have it validate your guess—often even before you write most of the code.

These techniques all grow in significance as you become more familiar with thinking in types. In all cases, though, the first step is leaning in and just type checking a lot.

Try it next time you use a typed language: stop, save, and see what the type checker thinks as often as you can. Explore systems for automated checking loops or get more accustomed with your IDE or language server.