Tuesday, January 22, 2013

Pro SQL Server 2012 Practices 'Be Your Developer's Best Friend' Chapter Review

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.


Friday, January 04, 2013

My tips on getting organized

I like to think that I am an organized person. But, sometimes, I must admit that I am not. Even though I have several tricks that help me get organized on some aspects of my life, I often fail to use those same tactics in other areas of my life.

Recently, a friend posted something online about getting organized. I agreed with her on her status, but did little to help the effort. I then realized that I should write more, and actually help, instead of simply agree, like I was the world's bese organizer and had it all going on. So I added a little bit more. She mentioned that the advice I gave was really helpful and that she was going to try it out. I felt good. I patted myself on the back. I was done.

Then a couple days later, I was at work, staring at my computer desktop, which has been a mess since, well, about a week after I started this job. Its one of those tasks I simply 'will get too soon'. And have never done so. Simple. Clean up your desktop. Make it useful again.

So, I sat back, having just received kudos on a job well done on organization prowess, and realize I should apply the same techniques described to my own life. Minutes later, I had put away items that had lived on my desktop for over a year. I removed duplicate items. I stored items where they should properly go. I regained control over something simple in my life that had become a burden. In mere minutes. Simple. But I hadnt applied those techniques in this area, and I hang my head in shame.

Now I share with you those simple steps I applied.

Do a small are at a time.
Take a box with you, large enough to hold everything in the offending area.
Put everything into the box. Everything.
Take the box elsewhere. sit down and go thru it.
  Do this while on the floor watching tv so you arent paying close attention to what you are sorting.
The things that are worth keeping will be put into a pile.
Most likely you will have a pile of things that need to be relocated to other areas. This is ok.
And you should have a pile for the trash. Put all the trash into the trash. Do not sort it again.
Do not sort any of the piles again.
  Keep, Relocate, Trash.
Then put things back where they have been sorted to go.
If items still wont fit, repeat.
If you pause while stuff is still unsorted, thats ok. Wait until you have time. But keep it in the unsorted box until you have time to properly sort it.
Do not redeposit it back where you got it.
Then move onto another area. Maybe on another day.