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 self-reliance stuck. It meant you had to understand what you were doing rather than pattern-matching against someone else’s answer, and I think that’s shaped how I approach problems ever since.
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 and 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 built a custom alerting system at one point and wrote up the KBs and operational runbooks to go with it. It felt like extra work at the time. But those docs are what let someone else pick it up cleanly, and what let me step away from it without carrying it in my head. Write it down while you still know what you were thinking.
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.