[andrewallbright]

I think the author is good with naming symptoms and I think they miss the true culprit. It's not typescript that is causing this pain, no it's the pain of getting correct abstractions laid down in code. It's truly the pain of code design activity. Typescript and library programming is just forcing that pain to the surface instead of hiding it away.

I know this because I struggle against these "pain during code design" & "get abstractions right" forces when I program.

Declaring types is really declaring what domain objects your program cares about and function signatures are really just describing interactions that can happen. So what 'domain objects' should meaningfully exist in my program and how do they interact? A bad abstraction can burn up a lot of time, so make sure you check your abstraction. I typically check mine describing stories to my friends (or rubber duck) and ensuring I'm using plain English and the other person doesn't get lost. YMMV

When you're doing web client programming you're typically using a library to accomplish work, and much of that work is reacting to user input and rendering data. I would argue that because so much of the linguistic heavy lifting has been done for web client programming, practicing the abstraction exercise is done less than in other programming domains. Doesn't mean it couldn't, just trying to highlight a difference in programmer domains. This is why the pain is more apparent in library programming than web client programming.

I imagine that advanced individuals in code design understand more of the connection between math and programming and are capable of describing systems of interesting work in few simple statements. I hope to reach those heights someday.