My biggest pet peeve is overreliance on documentation. I recall a project with a large team (30-ish FE devs) and I swear I could open any file in the code base

My biggest pet peeve is overreliance on documentation. I recall a project with a large team (30-ish FE devs) and I swear I could open any file in the code base and find at least one error, either from bad copy / paste or lack of maintenance. That simply isn't an option with Typescript- it wont compile if there are internal errors, so your only real concern is ensuring API responses and the like are what you expect them to be. Additionally, unless the tooling and spec has changed substantially since I last used it, JSDoc is awkward at best at expressing anything other than simple types. You can pretty drastically reduce the menial effort in some cases with advanced, mapped and generic types. For example, if you have some object of type Thing, and you need to represent an object with all of the same fields as being optional (say for a PATCH endpoint), it is simple as using the type `Partial<Thing>`. No worry that the two types will ever get out of sync with each other. Another example is that you get control flow analysis- more than simply detecting unreachable code from return blocks, there are a few ways the tooling knows that a type is refined. If you have an optional parameter to a function and an if statement that checks it is set, within the if statement TS knows that it exists, but outside will warn you that it might not.