> At work we recently did a timed programming problem solving competition. Thankfully, real world software development is not done under arbitrary time constra

> At work we recently did a timed programming problem solving competition. Thankfully, real world software development is not done under arbitrary time constraints with teams competing on who can be first to complete a prototype. High quality software is very difficult to produce, and taking the time to adopt sane development practices that reduce cognitive load and detect bugs early on in the process often leads to maintainable codebases far beyond their prototype phase. > In any case, this article was a fun one to read: > https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b https://medium.com/javascript-scene/the-typescript-tax-132ff... It might be fun, but it reads like a movie review where the author gives arbitrary scores and somehow determines TypeScript's ROI based on that(?). The rest of the article mostly appeals to authority, as the author pushes his books, expertise and vast experience as proof, something you seem to be doing as well. I feel like the mentioned "To Type or Not to Type" paper[1] is a more realistic study of the benefits of static typing, despite TS detecting "only" 15% of possible bugs. That's still 15% of bugs detected _during development_ that the programmer doesn't have to think about, and doesn't have to write thousands of very trivial tests to _maybe_ catch them locally or worse yet, in CI. This in practice never actually happens, let alone in code reviews! Yes, static typing is not a panacea. But it's a tool that has high chances of producing higher quality software, something that is sorely needed in JS land. [1]: http://earlbarr.com/publications/typestudy.pdf http://earlbarr.com/publications/typestudy.pdf