You're good enough, you're smart enough, and doggone it, people like you.

Altering the schema of a production database is not a step to be taken lightly. But when requirements dictate, it must be done.

Data migrations are high risk operations. You can't prepare for every pitfall, but a good plan will maximize your chances of success.

Good programmers know how to code. Great programmers know why. The best programmers question why.

"What actually makes code, advice, and tutorials obsolete?" Let's explore the answers as they relate to the Go programming language and MS Access.

Whatever modicum of credibility I may have had with "real programmers" I am about to douse in gasoline and light on fire with this article.

Everything must go!!! Dead code, obsolete reports, and bunches of binary backups! No offer too big or too small!

The fastest and most reliable way to run a migration is to repeat it many times. I call this the "Repetition Paradox."

Burning cardboard is a lot like a large data migration. You can do it all at once or slowly over time.

Lightweight forms make your code harder to read and debug, but if your users have monitors with high enough refresh rates, they'll appreciate the effort.

Thirteen years ago, I chose to maintain a folder of text files rather than a single Access database library. I've never once regretted that decision.