Blog

For years, I've grappled with the intricacies of code review, unwittingly slowing my team's development velocity and occasionally causing a ripple or two of discontent. From my experience, I realize that getting code review wrong not only wastes time but also harms relationships with colleagues and compromises software quality. Every healthy software engineering team will have a code review process in place, so the sooner we understand what a healthy and productive code review looks like, the better off we are in our careers as software engineers.

Since TypeScript does not have immutability by default, I tend to use the `as const` operator liberally. Put another way, I default to using `as const` until it conflicts with my intentions for whatever program I am writing. I also benefit from TypeScript having more information to provide developer experience niceties like editor hinting and auto-complete. However, `as const` only provides type narrowing. It does not provide type-safety on its own. We can restore type-safety by embracing intermediate variables at the cost of noise and loss of developer ergonomics. With the release of the `satisfies` operator, we no longer have to make this tradeoff.