Over Engineered is all about those things that bug you but you never get a chance to "solve." Today's episode is about the dreaded "status" column.

This is another topic that most developers will hit over and over. You have a model. You need to track the status. You add a status column, and then later a status timestamp "accepted_at", and then later an "accepted_by" column—and each time you cringe and wish there was a better way.

Today we discuss a better way… maybe?

Season 1 continues with a discussion of how to deal with special database records that need to be referenced directly in code.

We've all been there before: you've got a specific vendor that you need to write a custom command for, or a certain category that needs special handling, so you either hard-code the ID or slug and shudder slightly before moving on with your life. In this episode, we imagine a better—perhaps the best, even—way!

In the second episode of the podcast we talk with Tim MacDonald about a few other approaches to how you might manage other operations that happen before/during/after a database migration (or really any deploy step). Tim pitches a lower-level approach that spawns a whole new line of thinking.

We also touch on some of the responses to episode one, including:

• Ed Grosvenor's "run once" command
• Lukas Heller's mention of the "path" option in artisan migrations
• Brendan White's blog post on Data Changes in Laravel

In the first episode of the podcast we explore the boundary between database migrations and other operations that need to happen when the database is being migrated. How do you seed or manipulate data after new tables or columns have been added? In migrations? In one-off commands that you have to run manually? Running seeders in production? In tinker, Nova, or TablesPlus? We spend a whole hour talking about a topic that most people decide on in a few minutes.

Items discussed on show:

• Chris' initial Twitter poll
• Actions by The Dragon Code
• Laravel Actions