I started my DBA career before Google became a verb and before Stack Overflow existed. If you hit a problem, you read the manual, called Microsoft support, or figured it out yourself. That kind of environment shapes how you think about problems, and I think it still matters today.
Twenty-five years is a long time to work with databases. Here’s what that time actually taught me.
The first thing you learn — if you’re paying attention — is that the database is never just the database. Early in my career I thought the job was SQL Server. Queries, indexes, backups, jobs. It took a while to understand that the database sits at the centre of almost every problem in the business. Whatever the problem is, it ends up at your door eventually. DBAs who stay siloed get bypassed. The ones who understand the whole system are the ones people call when something really goes wrong.
Performance tuning taught me patience. Junior DBAs want to add indexes — I understand it, it feels productive. But the best tuning work I’ve done started with sitting with execution plans, wait stats, and Query Store data for a long time before touching anything. Most of the outages I’ve caused were times I moved too fast. An old carpenter I knew used to say measure twice, cut once. It applies here more than most places.
Documentation is the one nobody wants to hear about. I’ve been saved more times than I can count by a comment in a stored procedure or a note in a runbook I wrote on a quiet Friday afternoon. I’ve also spent miserable hours reverse-engineering something I built myself and completely forgot about. Write it down. Even rough notes. Future you will be grateful.
After enough years you develop a feel for it. You walk into an incident and something seems off — the wait stats don’t match the complaint, the query plan looks wrong for the data volume. That instinct is real and worth paying attention to. But verify it with data before you act. The most dangerous DBA is the one who’s experienced enough to be confident but not careful enough to check. I’ve been that DBA.
The thing that probably made the biggest difference to my career was building decent working relationships outside the DBA team. Developers, sysadmins, business analysts. Not because it made the job more pleasant — though it did — but because it gave me early warning on everything. New projects before they hit production, architecture decisions before they were locked in, and a proper understanding of what the business actually needed rather than what the ticket said. If you only talk to other DBAs, you’re missing a lot.
Twenty-five years goes fast. SQL Server 7.0 was new when I started and the technology has changed beyond what I thought was possible back then. The fundamentals haven’t.
Seriously.