{"id":44,"date":"2026-10-25T09:00:00","date_gmt":"2026-10-25T13:00:00","guid":{"rendered":"https:\/\/quentinpidcock.com\/content\/?p=44"},"modified":"2026-10-30T02:36:19","modified_gmt":"2026-10-30T06:36:19","slug":"typescript-turned-my-refactors-from-scary-to-boring","status":"publish","type":"post","link":"https:\/\/quentinpidcock.com\/content\/typescript-turned-my-refactors-from-scary-to-boring\/","title":{"rendered":"TypeScript Turned My Refactors from Scary to Boring"},"content":{"rendered":"<p class=\"wp-block-paragraph\">I used to dread refactoring JavaScript. Renaming a property, changing a function signature, or moving a piece of data from one shape to another felt like pulling a thread and hoping the whole project did not unravel. TypeScript did not make refactoring exciting. It made it boring, and boring is exactly what I wanted.<\/p>\n\n<p class=\"wp-block-paragraph\">The change starts with types as living documentation. A type tells me, in the code itself, what a function expects and what it returns. I do not have to guess from a variable name, or remember what a colleague meant six months ago, or run the program to find out that a value is sometimes missing. The shape of the data is written down where I can see it.<\/p>\n\n<p class=\"wp-block-paragraph\">That written shape catches errors at write time instead of runtime. If I rename a field in one place and forget another, the editor tells me right away. If I pass the wrong kind of value to a function, I find out while I am still thinking about that function, not later, when a user hits a broken page and I have to work backwards from a vague error.<\/p>\n\n<p class=\"wp-block-paragraph\">Refactors changed because the feedback loop changed. Before, I would make a change, run the app, click around, and hope I had covered the paths that mattered. Now, I make the change, follow the type errors like a checklist, and fix each one in turn. When the errors are gone, I have much more confidence that I have found the places that depended on the old shape.<\/p>\n\n<p class=\"wp-block-paragraph\">That confidence matters most in larger code. A small script is easy to hold in your head. A real project is not, especially when you return to it after time away. Types act as a memory aid for future me. They remind me what I intended, what is required, and what is optional, without me having to reconstruct the whole design from scratch.<\/p>\n\n<p class=\"wp-block-paragraph\">TypeScript is not free, and I will not pretend otherwise. Writing types takes time, and some types are awkward to express. There are moments when I fight the checker over something I know will work at runtime. But those moments are usually worth it, because the checker is also catching the moments when I am wrong and do not yet know it.<\/p>\n\n<p class=\"wp-block-paragraph\">I also learned not to use types as a way to be clever. A simple, readable type that another developer can understand is better than a precise but cryptic one. The goal is not to prove how much of the type system I know. The goal is to make the next change safer and easier to understand.<\/p>\n\n<p class=\"wp-block-paragraph\">The practical takeaway is this: if refactors scare you, do not look for a braver way to refactor. Look for a system that makes the scary parts visible early. For me, that system is TypeScript. It turns a refactor from a leap of faith into a list of small, checkable steps, and that is why I now reach for it when a project is going to live longer than a weekend.<\/p>\n\n<p class=\"wp-block-paragraph\">When I start a refactor now, I begin by tightening the types around the area I am about to change, rather than jumping straight to the code. That small preparation step often reveals assumptions I had not written down yet, and it makes the actual change feel more like editing a well-labelled diagram than guessing in the dark.<\/p>","protected":false},"excerpt":{"rendered":"<p>I used to dread refactoring JavaScript. Renaming a property, changing a function signature, or moving a piece of data from one shape to another felt like pulling a thread and hoping the whole project did not unravel. TypeScript did not make refactoring exciting. It made it boring, and boring is exactly what I wanted. The [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-44","post","type-post","status-publish","format-standard","hentry","category-technical-commentary"],"_links":{"self":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/44","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/comments?post=44"}],"version-history":[{"count":1,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/44\/revisions"}],"predecessor-version":[{"id":45,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/posts\/44\/revisions\/45"}],"wp:attachment":[{"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/media?parent=44"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/categories?post=44"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/quentinpidcock.com\/content\/wp-json\/wp\/v2\/tags?post=44"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}