Thursday, June 25, 2015

The Top 10 Things Your Developers Should Know

It’s not easy being a DBA, heck it’s not easy being a Developer. Too often DBA’s and Developers are put at odds, are we two different species, are they from Venus and we’re from Mars, Why wasn't the Green Lantern the movie more successful? There are a lot of questions and you want Answers! Come and find out the top 10 things you Developers should know about SQL Server and a friendly way you can present them.

So there we go, we start off with the statement, “It’s not easy being a DBA, heck it’s not easy being a developer.” We don’t want to alienate anybody you get just as many developers, managers, and other folks at a SQL Saturday as you do DBA’s. And then the Question ~~Why wasn't the Green Lantern Movie more successful~~ Why do we have such a hard time communicating? Then present the solution, and suggest a Take-Away-Item that people will get by attending your presentation. “There are a lot of questions and you want Answers! Come and find out the top 10 things you Developers should know about SQL Server and a friendly way you can present them.”

Notice I made a couple light hearted jokes in the abstract, you don’t have to do that. That's more my thing. So let’s do one more that is a little more serious.

Surrogate Keys vs. Natural Keys – The Great Debate

An essential part of Database Design is looking at the keys that you’ll have in your tables, You want to make sure that you’ve got a Primary key right? But do you want that key to be Natural or Surrogate? What is the difference between Natural and Surrogate Keys, What is the Sort order on a Page, and How can they affect performance? What do I want for an OLTP system vs. an OLAP system? Come find out as we take a step by step process that will build and compare each!

No jokes this time Dear Reader, kind of like an anti-mullet, no Party in the back and all business up front.

Once your abstract get's selected THEN you write the presentation. In order to do that you have to submit.

You do NOT need to be on Twitter, LinkedIn, or have a blog. Those are optional, but they do help with your personal branding. Long term you should consider those things. But you have time to do that!

Submit to SQL Saturday 442 Orlando by Clicking Here.

3. WHY WOULD I WANT TO BE A SPEAKER?

If you liked his presentation,
go buy Simon's book

It's important to start with Why. I cannot tell you your why. I can't. It is for you to decide. I can tell you my Why. That's mine not your's, and I would encourage you to listen to Simon Sinek's great presentation on that. It's only 18 minutes, and it has the potential to change your perspective and by proxy your life. Go ahead and watch. I'll wait.

Okay did you go listen? Seriously! After I said the whole change your life and perspective thing! Really!?! Go watch, click here.

Okay, if you still didn't do it I'm not going to turn into The Monster at The End Of This Book.

My Why. I love empowering myself and people with knowledge. I do this by trying to make complex concepts simple and relatable. I just happen to do this through presenting, writing, and consulting. Would you like to come to my presentation? If you watched the video, you see exactly what I did there.

If you don't know your Why, finding it is half the fun. Being a speaker can help you along that path as well.

Networking and opportunities are certainly a part of the package, but they are a result of What you do not Why you do it. Look at your Why and if it leads you here we'd love to have you!

You don't have to speak. You can be an attendee, a volunteer, or just come for the coffee, donuts, and conversations. After all this is all about community!

WRAP IT UP

What are you doing still reading this blog! Go submit, and if Orlando is not close to you head over to SQLSaturday.com and find a SQL Saturday near you, I'm sure they'd love to have you speak as well!

As always, Thanks for stopping by.

Thanks,

Brad

Thursday, January 22, 2015

Looking Out for Others Helps You Lead

I'm sitting on a plane. I'm in an exit row, still a big guy in a little seat. I go to sit down and notice the seat to my left has water on the seat. Not so deep that it is a puddle. 5 to 10 big drops. Enough that you wouldn't want to sit in it. The person who this seat will belong to hasn't made an appearance yet.

I sit down and try to politely wave and smile at a flight attendant to get her attention. I think she sees me, but she doesn't respond by acknowledging me. I want to fix this before the seat is filled.

It would be a rotten way to start a trip by finding tour seat with water on it. It's a modern conundrum. How do I attract attention on a plane when the line is boarding, while not becoming that guy who attracts the wrong kind of attention.

I wave again and try to smile as I think I am acknowledged. Still didn't work.

The call attendant light! That's the ticket. I hit my button, eyes locked on the flight attendant. BINGO! She sees me.

She mouth the words from across the plane, "Did you push the button?".

"Yes", I mouth back.

"Hit the button again", she says across the plane.

Okay I think, now I can simply point this out and get it taken care of. The water will be cleaned up. Everything will be right and in order before the seat gets filled. Wrong.

After I turn off the light the flight attendant goes back to talking with the people at the front of the plane. She must have assumed I did it on accident. Again I am discouraged. I mean it's not even my seat. If I just wait when the person arrives they can hold up the line and at that point it will have to be fixed.

I can't leave it like that.

It is something simple, but it is so much more than that. As a kid I loved Superman. I was always a fan. I probably slept in a cape more times than I didn't. I tried too, at least. My Mom was convinced that I would strangle myself in my sleep, if she caught me wearing one she would make me take it off. And I would. Until she left the room.

Link to original

The thing about Superman was he helped people. That was important, even as a child I knew this. I think at that age we all do. We are supposed to look out for other people. We should help them. As an adult we tend to get jaded about that.

We realize there is only so much that we can do. We can't help everyone. We cannot donate all of our time or all of our money to charity if we have a family or children at home. It wouldn't be wise, as a matter of fact that would be wrong. We have to take care of our families first. So we begin to make realizations over time. The innocence of our childhood fade away. We realize we cannot save everyone.

During my brief time as a football coach for my boys a couple years ago I had a phrase I fell in love with. You play how you practice, you practice how you play. Simple but true.

I still tell my kids that on a weekly if not daily basis. If you have a good strong work ethic at practice you carry that over to the game. If you quit at practice you will probably quit in the game. If you are sloppy at home or lazy about getting things done... you practice how you play.

If we cannot look out for others over simple things, how can be expected to look out for our coworkers, our customers, or our clients. It's simple, but it is more than that. We have a responsibility to make the world better.

Period. Not just better in business. Better. Period. End of sentence. It doesn't matter if the goal is to lead employees, a team, or any effort that we under take in life. We have the chance to effect change for the better in every action we take. We can act with others in mind, and by doing so we will make things better for them. You practice how you play.

This thought was fresh in my head because of work.

I lead a team of highly skilled highly talented consultants. We love fresh and new ideas. At Pragmatic Works, my job, we have had a very innovative approach to raises and reviews that allowed people to control their own destiny. Like many ideas it looked good on paper, but after several years we could see cracks in the system.

For the past four months we've been working to replace to old and determine the new. This isn't new to us. Every year we take the feedback from our teams and we look at how we can do things better, how we can make changes that benefit us personally and professionally. However, this year marked our largest set of changes we've introduced since I've been with the company.

The core thing that drove us was how we would grow, encourage, and support our team. How do we help them? Not just internally for the company, but how do we help them technically and professionally. If people are here for years or only a short while, the goal is to help them leave better than when they arrived. We need to help make you better. As leaders for our company it is our job to help our employees. Period.

We sat down with people and had a lot of 1 on 1 meetings discussing ideas and asking for feedback.

We took that feedback and kept some things and threw out others. We increased vacation, changed the review process, increased the benefits to help people be active in the SQL Community, and other technology communities. We are working on redoing our mentoring program and some other very cool things to help people grow.

After all if you are in the business of helping people, which we are; what good are you if you cannot help the people who work for you. You practice how you play.

"So Balls", you say. "There was this water in a seat...."

Thank you Dear Reader. So I stood up, waved to the flight attendant, and in my most polite southern accent I asked if I could get a napkin to clean up the water in the seat next to me.

She walk over to me with a puzzled look, as though I had spoken is some foreign tongue. As we both looked at the water she realized why I had been waving. She rushed off to get a couple napkins to clean it up. About 20 minutes later I began to laugh inside. The seat next to me was still empty.

What if it was all for nothing and no one sat down.

Before long an elderly woman boarded late and took the seat next to me. Her seat was nice and dry. I think my kids would be happy with me, after all you practice how you play.

As always Dear Reader Thank you for stopping by.

Thanks,

Brad

Wednesday, November 26, 2014

When the Problem is Not Them. It’s You.

Hello Dear Reader! I’ve been the Data Platform Management Lead at Pragmatic Works for almost two years now. It’s been an interesting journey that I’m enjoying. I’m the tier 3 support in a lot of cases, play the role of manager, mentor, and fellow fighter in the trenches when required. Today I wanted to write about something that deals with professional development.

In IT facts are facts, data is data, things perform well or they do not. All of this leads to trust. I do a lot of presentations on the Internals of SQL Server. It is a fun and topic I enjoy it. *cough* nerd alert *cough*. I do this not just for fun, but because knowledge is powerful. It gives me the ability to let my clients have confidence that I understand what I’m talking about. Very rare are any instances where I have been paid when I actually needed to flip hex to decimal and look through the binary that was produced. The ability to display that knowledge when needed is crucial to ensuring you’ve got a second shot when you need it.

Projects, jobs, and opportunities come and go. I’ve seen cases of spectacular success. As anyone who has experienced success well knows, the path is littered with those who have failed before you. Some projects are easy, some are hard. All can be successful, but you have to have the right mindset. When projects do fail it can be for a variety of reasons, typically it comes down to poor communication.

I could be the typical marketing magazine and now list out ways projects fail, how communication is important, but Dear Reader you deserve better. What you really want to know is how you fix it.

IS IT TOO LATE FOR A RETRY

Unless all trust is gone it’s not too late. When you are walking out the door, or being asked to walk out the door it is too late. As long as you are still on the team, you should take that as validation to be part of the process. In business everyone wants to be successful. Everyone wants to win. If you can help with that, then it is never too late.

The Upgrade Part 1

I was with a billion dollar company and we were upgrading their SQL Server boxes for their main application that the entire business ran off of from SQL Server 2000 to 2008 R2. We had a very well thought out project plan, an itemized list and timeline of what needed to occur, and over 100 people including a team of VP’s that were on hand to monitor the event. Leading up to it we hit a pretty big snag.

We were migrating the users from SQL Server 2000 to 2008 R2 and an odd thing happened. The logins stopped working. We caught it in Staging. There was another consulting company that was also working with my client. Often you will work with consultants or contractors for many different organizations, and you have solid and good relationships. This was not one of those cases.

The competing company took this opportunity to state very loudly that I didn’t know what I was doing. That we could not just go from SQL 2000 to 2008 R2. The hash had changed for logins, and you had to stutter step to SQL Server 2005, then re-export the logins to SQL 2008 R2. This added an increased level of complexity, and threatened to blow our timeline. I left the office dejected and the client questioning my experience.

You don't want to do IT.
You want to go home and rethink your life.

The EDW Part 1

I was with a client in the financial industry. The mission to help pull data from a database, not SQL Server, to a new Enterprise Data Warehouse (EDW). The plan would have us pull from our Online Transaction Processing (OLTP) system to move the data over. They already had an Online Analytical Processing (OLAP) DW. The data was Extracted, Transformed, and Loaded (ETL) from the OLTP system to the OLAP system. The columns where not the same, they didn’t match up fully. This was using a 3^rd party product so we didn’t have full visibility into the data mappings.

The business trusted the OLAP system. Even though the OLTP was the source, they wanted us to validate our imported data against the OLAP, not the business rules and calculations provided to us using the raw OLTP data.

I didn’t agree with this approach. A source system of this type that had pure 100% financial data, that financial decisions were made off of daily, should be the trusted source. We should not be replicating the OLAP data but finding that the business calculations produced, validating them off of the source data and moving that data. After many meetings on this subject I found myself in a room with the entire project team. I realized that I was the only one passionately arguing this point of view. In fact I found everyone was unified in one direction. That direction was that I was wrong.

FIXING THE ISSUE (YOU)

Once you have realized that you are the issue the next step is to find a way to reestablish trust. Learning, adapting, and putting the goals of team forward showing you can be a productive member goes a long way.

The Upgrade Part 2

When I started thinking about the issue I knew I wasn’t wrong. Either that or I had gotten unbelievably lucky for every upgrade from 2000 to 200x that I’ve ever done. Either way I wanted to know which it was. If I had been lucky, well let's just say I would have a lot of phone calls I would need to make.

In order to be sure it was time to take a close look at the Microsoft provided scripts for transferring logins for SQL 2000 and guidance for SQL 2005 and up. What I found was that the hash output was indeed different. To test this I stood up a SQL 2000 box, made a user and a password and exported them. I did the same on SQL 2005. There were differences. The length was different. The 2000 scripts generated a password hash that was 102 characters long. The 2005 and up were only 42 characters long. Then it struck me those characters matched the SQL 2000 output exactally.

I used the SQL 2000 script to transfer the user to a SQL 2008 R2 instance. Then I logged on as the user. It worked. I deleted the user, and ran the 2005 scripts. It worked. Those 42 characters were the important part. That didn’t solve my issue with the client. Our passwords were not working. On a wild hare it struck me that the passwords were all lower case. I tried camel casing them. They worked. I found by default that SQL 2000 passwords were case insensitive.

Poor password management had led them to record the passwords as lower case. The hash had saved the camel case, and on export had enforced it by default on 2005 and up. I brought this to my client the next day. We realized that the passwords they had stored were not always correct. In order to fix this we had to reset and update every application and it’s password before we could proceed.

We did, and the upgrade rolled on.

The EDW Part 2

I stood at the front of the room and realized every eye was on me. I realized that the business firmly believed in the process they had laid out. I also realized, I was the only one not on board. This was a definitive moment. I could stand my ground, but very quickly I could see that would lead me off this project. Failure is not an option. So I went for option 3.

The process of not trusting the source is, and this is an understatement, not good. Even with that staring me down, I could see an opportunity. If I was onboard with the plan, I could work from the inside to validate that the source data was what we needed.

So I did just that. I wasn’t excited, but I smiled big. I wasn’t 100% convinced, but I threw in my hat, hard work, and rolled up my sleeves. That first day the grin on my face may have been strained, by the end of the next 4 weeks it wouldn’t be at all.

We didn’t have all the business rules or the ETL logic for the 3^rd party data warehouse that the business trusted. The people in the room knew that. They were committed to getting this right, and putting the puzzle pieces together. The process would be painstaking, but as I made my change of heart and discussed the validation we would need to do, mapping documents we would need to create, business logic we would need to confirm, validate, and how we would validate the imports it started to come together.

PULLING IT ALL TOGETHER

“So Balls,” you say, “That’s great that you fixed it. How do we fix it?”

Great question Dear Reader. These stories both had a positive outcome. They happened because I didn’t give up, and I continued to work to help the team succeed. I don’t want to paint this as if I’m never wrong. Just ask Adam Jorgensen (@AJBigdata | Blog), he’ll tell you that I’m wrong quite often. I’ve also blogged about learning from mistakes, mistakes are important. Be humble in the way you interact and listen to people. People who believe they are never wrong, suffer defeat far worse than those of us that recognize it as part of growing.

If I was wrong about the passwords from 2000 to 200x I wanted to know. I wanted to understand why, and what we could do to fix it. Had I been wrong, I would have sung it from the mountain tops. I would have blogged on it and gladly advised people on it. Instead I found the answer I was looking for and the logic to back it up, I share that just as freely as I would have my failure.

When everyone is fully committed to an idea that you do not agree with instead of assuming they are wrong, consider that you are. It changed my point of view on the project. It allowed me to embrace a team that wanted someone to take them on the path towards success and be part of that team. It also reinforced a very simple fact, I am not always right and I need to listen to others.

In each case you have to want to achieve the end goal, and that has to be more important than being right.

As always Dear Reader, thanks for stopping by!

Thanks,

Brad

Pages