In the new Pro SQL Server 2012 Practices, chapter 1 is all about the impossible. It is entitled 'Be Your Developer's Best Friend'. I tease. This is one of those soft skills that we all struggle with from time to time, regardless of which side you stand on this tale. I started my career as a developer, and moved into the database space over time. I now sit on one side of this task, as I have sat on the other side not too many years ago. It is not an easy thing to do, but a necessary one. Jesper Johansen, the author of this chapter, takes on a journey through the why, how and when of accomplishing this task. He details the different focus of thought that occurs when you are a developer as opposed to a DBA and why these focuses are an important makeup of the title and job each hold. As his history within the IT world unfolds, you can see how he implemented the skills he will later share with you as the reader, helped him within his career.
One of the tasks described within this chapter is something that I have often known, thought about doing, but simply never seem to take the time to do. I was inpsired when I read this task to share this with my team of IT folks, and hope that we can start implementing this in our project planning. Its not rocket science. Its creating a map of your existing environment and map of what you want it to be. We all too often will talk about these changes, discuss them in meetings, actually create individual tasks to perform various aspects of this transformation. But rarely do we actually just map it all out. All of it. The entire system. I believe that doing this would greatly help. As I read this I am pompted to really try to map out one of our projects, as it has floundered over time, never really getting traction towords completion.
He details stories of his own experience where dialog had bridged the gap of understanding between teams. Including multi faceted teams comprised of different focuses, with a single goal. Putting people together, explaining your point of view and focus, allowing them to do the same, working together towords a single goal, will drastically help out any organization and project. Instead of allowing the old stereotypes to perpetuate, take a stand, make the change yourself, start with you and create the tools necessary to start the dialogs and discussions. These points are well received by myself as I read his suggestions. I have seen it work myself. But I need to remember to continue with these seemingly simple tasks. Its not a one time task, but continual. Just like all relationships, they take constant nurishment and work.
I love that he goes into detail of how to create the documentation necessary to assist in this task. Documentation is a bane, is difficult, it awful to produce and keep up to date. But that same documentation will save you. It is so important and necessary to produce, keep up to date, and use. It took me several years to realize this, but once I got the vision of the importance of documentation, I became a true believer. I would say though that it can become a chore and degrade your work if not done properly. Just like the old saying goes about seeing everything as a nail, if your only tool is a hammer. Remember that documentation is a tool and needs to be used properly. Don't over-do it, or under-do it. It is nice that Jesper not only tells you as a reader to create this documentation, but provides some assistance with how to create it as well.
He also points out some interesting techniques where you as a DBA can provide tools to developers to perform the tasks that the DEVELOPERS need to perform. I once had a DEV that needed to be able to insert records into a table. The table was production. I told him he could not. He got frustrated. I devised a tool that allowed him controlled access to perform that task, trained him on how to utilize this tool, and set him loose. He and I became good friends at work through this interaction. I was not the evil DBA that simply wanted to curtail his access. I simply was protecting our systems. His system, my system. Protecting it from harm. Once he understood this, and accepted his limited access, which would protect him and the system, we moved forward. Jesper details several tools and techniques that have helped him perform similar protections, while allowing protected access to systems.
As he concludes his chapter, it is mentioned that these are large tasks with small sub tasks. Its like eating the elephant; doing so one bite at a time, it can be accomplished. The same holds true with this goal. It will take time. Pick the right individuals to team up with. Take it slow. Make progress, measure the progress, share the progress, and get better with each iteration. It can be done. With the tools provided within this chapter, you should at least be able to be inspired to set out on this journey yourself, while at most, be given the tools to implement as is from the writings of this author.
I enjoyed reading this chapter, as it rang true with many of my experiences. Through reading this, I have been inspired to add to my toolbelt from those suggested tools the author shares. I have thought of scenarios where I can better improve my interactions with others. I have thought about ways to implement some new tasks in my team as well. I hope that through reading this chapter, I can be a better IT professional, a better DBA. I hope that it helps you as well.
http://www.amazon.com/Server-2012-Practices-Professional-Apress/dp/1430247703
No comments:
Post a Comment