Welcome to my PinkLetter. A short, weekly, technology-agnostic, and pink newsletter where we cultivate timeless skills about web development.
What do you think is the most important skill to manage legacy code?
I think it’s courage.
Sure, you still need the skills—legacy code is a different beast than working on a clean slate. But it’s not enough.
Legacy code is not a ticket that you can move to done in one sitting. It’s more like a project that will take you several months if not years.
Legacy code is a team effort. You will never outwork the rest of the team, so you need everybody to be onboard.
Legacy code is risky. You probably don’t want to blow up production for just a dependency update, do you?
Legacy code is unpredictable. You cannot scope in advance all the tasks (and obstacles) that need to be handled.
Legacy code is thankless. You may find it hard to explain why. Why the hell you want to go through all of that pain.
Sometimes legacy code is better left alone. But, should the need arise, read Working Effectively With Legacy Code and muster all of your courage. You will need it.
If you read through the article and maybe even try an example or two, you should have no problem writing Awk scripts by the end of it.
Elm’s Opaque Types are a powerful tool for narrowing the surface area where you check a constraint. TypeScript’s Branded Types give similar functionality but without closing outside use, so you can’t be sure the constraints are enforced everywhere.
My experiences over the last 20 years have shaped how I view software, and have led me to some beliefs which I’ve tried to whittle down to a manageable list that I hope you find valuable.