It’s the busy time of year here at PASS. We just wrapped our first (but not last!) 24 Hours of PASS virtual conference, the nominating committee is working on the slate of candidates for the Board of Directors, the officer nomination committee is working on recommendations for the officer candidates for this year, and of course PASS Summit is only a few weeks away now. We’re also coming up on the annual election, always a busy and interesting time for PASS.

Changing topics, I’d like to challenge you to participate more in your local chapter. That doesn’t mean you have to go to every meeting, but at least go to enough that you recognize the regulars. Maybe earn some karma by volunteering to show up early to set up the room, or take on a bigger role by taking ownership of finding speakers or sponsors, but go.

Chapters aren’t just technology, they are people, and that’s usually what makes it fun and interesting. It’s also important to the health and success of a good chapter to have good attendance relative to the size of the area. For example, here in Florida, the Space Coast group averages 10-12 attendees. I consider that very good considering it’s a small town. In Tampa, they average 40-50 attendees, not bad at all for a much larger city.

You add value by just attending. Somewhere behind the scenes someone has sent the emails, set up the room, found the speaker, and paid for the pizza. And all they hope for is a good meeting with good attendance. You can go to learn something or to meet people, and just by being there, do something positive. Not sure I said that well, but hopefully it gets you thinking.

I recently had the opportunity to attend the Jacksonville Code Camp, a great event with 8 tracks and 460 attendees! As you can guess from the title the focus is developers, but developers do some data access and so there was one SQL track – the main reason I attended. As I sat through some of the SQL presentations (all well attended) what struck me is how much of a gap remains between developers and DBAs.

Some of that gap is the nature of the way we train developers and DBAs – on the job. That’s a practical strategy, but it also means that our early views of how the world should be are shaped incidentally. If the first job a developer has is for a company that doesn’t have a DBA and doesn’t do a lot of data access, it’s easy for them to see data access as something less than interesting. Or if the first job is with a company with a really tough DBA, they may see DBAs as an obstacle rather than a helpful team member.

Some of the gap is responsibility. DBAs feel the weight of down time, data loss, security breaches in a way that few developers do. It’s not that developers don’t care, but they have the insulation of QA, testing, and not having access to production.

Some of the gap is the way we’ve divided up the teams. Having DBAs and developers on different teams makes a lot of sense for many reasons; separation of duties for SOX, cross training with others will similar skills, etc. The separate teams aren’t innately bad, but in practice they present another hurdle to communication.
Over time all of those things and more have created a real divide. I don’t know that we can fix it in one editorial, but here are some ideas for you to think about:

Developers

Remember that data is the life blood of the business and DBAs are tasked with keeping it safe – understanding that point of view will help you bridge many gaps

Good design and data access does matter regardless of the number of planned users. Doing it well doesn’t take much more time than not

Treat your DBA as a valued consultant. You’ll get better results if you show them the problem than if you give them the solution

DBAs

We can’t afford to be road blocks for the sake of ideals. Time to market demands often force businesses to take short cuts. Help them make smart choices about where to short cut and where to invest a bit more effort

Don’t expect developers to be SQL experts! They should write their own procs and more, but don’t expect them to design a solid indexing strategy for you

Get in the game early. Start sitting in on the planning meetings with developers so that you can offer some sage advice when the cost of change is low. Remember the first point – sometimes corners will have be cut, be flexible and show them the pitfalls as you see them

I think there some things PASS can do to make the developer/DBA relationship work better, but ultimately it comes down to people – an analog solution to be sure. If you think about it, it’s really more than being a good DBA or good developer, it’s about being a good team player and a good employee. Try to worry less about your concerns and focus on helping other people get stuff done. Someone has to go first – why not you?