Once upon a time, during a PR review, a colleague and I had a long discussion about fixing a seemingly tiny bug before merging.
“But this code causes double rendering!”
“Well, yeah… so what?”
The bug had no visible effect on users. We could release as often as we wanted. Code is cheap to change - unlike APIs or data models - so why bother? Merge it, release it, fix it later. Refactor. Repeat. But they were adamant.
That conversation made me think: where the idea of a “precious” main branch comes from? When does it actually make sense to strive for perfection in code? When does code stop being merely a liability we tolerate in order to deliver value, and start being an asset, the product itself?
In this talk, we’ll explore how understanding the product vs library distinction can shape engineering practices, code quality expectations, and development processes, and how asking one simple question can make day-to-day engineering decisions easier: is your code an asset, or a liability?
“But this code causes double rendering!”
“Well, yeah… so what?”
The bug had no visible effect on users. We could release as often as we wanted. Code is cheap to change - unlike APIs or data models - so why bother? Merge it, release it, fix it later. Refactor. Repeat. But they were adamant.
That conversation made me think: where the idea of a “precious” main branch comes from? When does it actually make sense to strive for perfection in code? When does code stop being merely a liability we tolerate in order to deliver value, and start being an asset, the product itself?
In this talk, we’ll explore how understanding the product vs library distinction can shape engineering practices, code quality expectations, and development processes, and how asking one simple question can make day-to-day engineering decisions easier: is your code an asset, or a liability?