Data Protector trump the Mentor?

I started in the database world using MS Access about 15 years ago. I was young and inexperienced and made lots of mistakes with even the simplest stuff. But I was fortunate that in our department there was a developer that saw something promising in me. I was willing to try things myself first, research a lot, and then ask questions of others. He was both patient and wise and dispensed knowledge in a mentoring fashion, sharing bits and pieces of knowledge pointing in directions to pursue. Rarely did he offer an outright solution, but steered me toward the right path.

My second encounter was similar to the first, with guidance and direction, someone challenging me to think through the entire process and then implement a proposed solution. My third encounter was with a certified MCDBA. He was actually younger than me, but like my other friends saw some potential in my ability as a SQL Programmer. He took me under his wing and together we challenged each other to develop new processes and methods for the agency where we worked.

I suppose I can relate my first experiences to being in high school, then college and then to becoming a teachers’ assistant. Mentored by all of my teachers and professors, and being challenged to learn. I was taught to educate my fellow programmers and support the database community as a whole.

Since my days as a “TA” I’ve run into issues with almost all my subsequent DBA’s. They were, in my opinion, brought up in the military fashion with a “Lock it down and Secure it, No one may Pass” attitude. I’ve found this to be extremely frustrating and have left jobs as a result of this type of attitude.

Now don’t get me wrong, I was taught about the importance of security and implementing best practices. I swear by it, and as a developer am scared when I find production databases that are accessible to my coworkers.

But what I don’t understand is the DBA that locks down the Dev box so tightly that only they can play in the sandbox. Part of my job as a programmer, I believe, is to write the best code I can, to help my other programmers write better code and to help improve the performance of the database. I can’t do that unless I can at least use ShowPlan and create indexes. I document my performance tests, my changes, and the improvements. I make recommendations to improve performance and try to assist my DBA.

Editorial – from Matt Simmons

To learn, one has to try something new. To try something new means risking failure. If you’re not making a few mistakes, you’re not trying to learn. In my opinion, one of the best ways to help someone onward is to give them just a little more responsibility than they can handle.

Now, mistakes cannot realistically be tolerated in a production environment, hence the need for the dev, test, pre-prod and sandpit environments. However, what’s the use in creating somewhere for developers to develop (together with the bugs they’ll encounter along the way) and then locking it down so tight as to all but stifle the development?

I believe security is only in part a technical issue, the greater part being the human dimension. If the DBAs and developers in a team work at their relationship rather than relying on technical safeguards and barriers, the understanding that grows between them can be reflected in wider (monitored) freedom within the volatile development environments. And, because this scenario involves DBA and developer working together, any code that has to be promoted to live has already become familiar to everyone involved.

Yes, I believe there’s a happy medium, but I don’t believe it to be a compromise. Rather, I believe it to be the best of both worlds.

~ by UTS on August 19, 2009.