A couple days ago, I talked about the decision to refactor some awkward code to avoid further papering over a less-than-ideal earlier technical decision. The lesson was "try not to make things worse".
Today, I want to share a corollary principle: "Take time to make things better". This might sound like saying the same thing with different words, but there's a subtle difference. Continuing my profile refactor example, I avoided making it worse, but I also noticed some additional opportunities to make things tangibly better.
For example, there were some fields in each profile type that weren't even being used anymore, and there were no plans to bring those features back. In addition, there were a couple legacy fields that had old generic names, like question1 but in the application we labeled them something more specific and useful.
Here was the opportunity to make things a little bit better. And since I was already writing a migration, why not add a few more schema changes to bundle in with it.
As with all things, there is a need to balance these improvements with your overall workload. And you don't want to unilaterally start changing things without getting some team buy-in. But look for little opportunities to pay down some technical debt, and over time these small changes add up to a much lower balance of technical debt.
Here to help,
Joel
P.S. Laravel is pretty secure by default, but Aaron published a course to go even deeper on Laravel security.