The 89: Official Cocktail of SQL Saturday #89

I need to put out an “official” SQL Saturday #89 debrief (hint: it was pretty great), but I want to throw out one cool piece of SQL Saturday history that was made last weekend.  As far as I know, SQL Saturday #89 in Atlanta is the very first SQL Saturday to have an official, original cocktail.

Allow me to set the stage… It’s Friday evening.  Pre-con sessions are done, printing and badge assembly isn’t.  The whole volunteer crew heads to our HQ at the Staybridge Suites to finish up.  Aaron Nelson (blog | Twitter) is driving Adam Machanic (blog | Twitter) about town.  Before getting to the hotel, Aaron and Adam hit the package store.  Adam arrives with an armload of liquid motivation.  He heads to the kitchenette and begins to Concoct.  We less savvy cocktail drinkers ask what he’s making.  He announces that he’s making it up with a few things he picked up.  We realize that we might possibly be in the midst of a genius moment, so we step away and let the man work.

A few moments later, Adam begins to distribute drinks to the volunteers.  I taste mine.  It’s heaven.  Refreshing and crisp, with just the right amount of bitter.  It makes the super-slow printer that we named something very derogatory and inappropriate (hint: think harlot with very poor hygiene) look just a little bit better.  It brings a smile to my face, and the carpal tunnel syndrome I’ve developed during the paper-cutting-filled day begins to ease.  The whole crew feels the weight of the biggest SQL Saturday ever in Atlanta begin to lift.  We decide that we must name this masterpiece.  After a brief discussion, we settle on it.  The 89.

Once there is a drink in every hand, Mr. Machanic jumps in to help.  That, my friends, is exactly what the SQL Server community is all about.   Friends, teamwork, volunteerism, and one hell of a good cocktail.

And now, the recipe:

The 89 (Invented by Adam Machanic):

Materials:  Abuelo Anejo Rum, Cranberry Juice, Lime Juice, Cointreau, Angostura Bitters, Ginger Beer, Highball Glass, Ice

— 2 oz Abuelo Anejo Rum (or similar aged rum)

— 1 oz Cranberry Juice

— 1/2 oz Lime Juice

— 1/2 oz Cointreau

— 5 dashes Angostura Bitters

Build in highball glass with ice, top with Ginger Beer, Stir

A Call to Arms: Ladies, I’m Looking at You!

I’m helping to organize SQL Saturday #89 in Atlanta. This morning, I looked to see where we were with speakers and submissions. Running through the list, I saw we had 32 speakers. Awesome. Scrolled through again. We had three women. Not awesome.

As of right now, we’re at 35 speakers and 3 of them are women. That’s 8.6% for those keeping track at home. That’s less than 1 in 10 speakers. I just spoke at SQL Saturday #77 in Pensacola, and was the only female speaker. This is not good. This is not the trend I want to see. (By the way, thank you to Melissa Coates (Blog | Twitter), Jen Underwood (Blog | Twitter), and Sarah Barela (Blog | Twitter) for submitting!)

I have a very strong opinion about objectivity in our community. Pick me based on the value of my content, not based on my gender. I’ve said a few times, publicly, that if we just leave smart women to their own devices, gender diversity will work itself out. Wow… That’s just not happening.

What is happening? Was I wrong? Where are we missing the boat? Where are the smart women who are database professionals, and why aren’t they clamoring to submit sessions? You know what’s the worst? I tried to think of someone I could call and say, “Submit already”! I couldn’t think of anyone. That made me angry. Really angry. Ask Aaron Nelson (Blog | Twitter). Poor guy had to listen to me rant (a lot) today. On reflection, I’m mostly angry with myself. I don’t have anyone in mind? I haven’t thought through who I should be encouraging to submit an abstract? Shame on me.

So, I’m stepping off my standard-issue Gender Neutral Soapbox and putting out a call to arms. Ladies, (yes, you… I’m talking to you), submit a session to a SQL Saturday. Get involved! Put yourself out there. Is it scary? Yes. It’s also fun, exhilarating, and rewarding. The first time someone e-mails you to tell you that your presentation taught them something useful, you’ll be hooked. I promise.

Here’s my commitment to any woman who’s trying to decide if she wants to try her hand at presenting and is on the fence: I will be there for you. I’ll review content, help you practice, give you pep talks, whatever you need. There are too few of us out there. Get involved. Help prove me right – that we’re just as capable, just as passionate, and just as ambitious as the boys.


What Are We Doing Here, Exactly?

There’s a secret about being a developer that I forget all the time.  I know it, and I should remember it, but in the daily drama of life, I tend to forget it.  Here it is:  Knowing how to do something is the easy part.  Knowing what to do… that’s hard. 

Technical skills allow me to execute on a plan.  The good news is that if I don’t know how to do something, there is a wealth of resources out there to help me out.  I can probably pilfer a bit of code from a blog, find a checklist, or even call a friend.  Knowing the plan?  That’s the hard part. 

Brent Ozar (Blog|Twitter) wrote a brilliant post about being a consultant.  It was so brilliant and apropos that I e-mailed him to ask for advice on a few things I’m dealing with.  He was awesome, and thoughtful, and gave me some great ideas.  He even recommended a book, The Secrets of Consulting by Gerald Weinberg.  I read it, and I immediately felt better.  Everyone should read it.  It validated something that had been creeping around in the recesses of my brain:  I didn’t have a good plan.

Why not?  Well, I’d been so busy executing that I’d forgotten to take a step back and think.  It happens to the best of us.  I tend to be an intuitive person.  I feel like something’s not right long before I can put my finger on it.  It makes me crazy.  It’s like the intelligent part of my brain is whispering, “Audrey… Audrey… Pay attention.  This isn’t working”, while the rest of my brain is totally focused on crossing things off the to-do list.  The problem?  Maybe the to-do list is dead wrong. 

So that’s what development managers and project managers are for, right?  They put the plan together. They figure out the what, we figure out the how.  Right.  Right?  Hogwash!  Yeah, I said it.  Hogwash. 

Here’s what I believe.  Every person involved in a project, from the college intern to the CTO needs to do a personal assessment of the project they’re on.  I’d flat forgotten this personal belief of mine.  In the rush to deliver, I’d jumped headfirst into a project without first grounding myself.  So, after talking with Brent and reading Weinberg’s book, I assigned myself a task:  Assess the Project. 

Now, I’m not the first person to do this, and I’m certainly not the first person to talk about this.  But I constantly have to remind myself to actually do it.  It is a liberating exercise.  Putting onto paper what’s worrying me about a project makes it real.  If it’s real I can do something about it, or at least see it coming before it smacks me in the face. 

I have a few personal rules for my assessments: 
1)      It is a personal document.  For my benefit.  I might use it as a reference for later communication, but for now, it’s just me and my stream of consciousness.  I don’t worry about sounding negative or hurting feelings.  If I think it’s going to be really bad, I might even write it at home and on the personal computer.

2)      It is mostly a problem-defining exercise, not a problem-solving exercise. 

3)      No edits till I’m done.  None.  No tweaking, rewording, or rethinking.  This one is hardest for me.  I can’t help myself sometimes, and the urge to soften a harsh word or begin in-line rationalizing is tough to resist. 

4)      This is not a technical document.  It is an emotional document.  Everything from “I don’t know how to do X” to “Mr. End User refuses to cooperate” is fair game. 

Anyway, here’s my process.  I ask myself some questions, and answer them.  Really, it’s just a set of lists. 

1)      What is the current state?  – What’s going on in the business that prompted this project in the first place?  What needs to be improved/created/maintained?  Is the system too slow?  Are users complaining?  Are we losing customers? 

2)      What is the desired state?  – What does everyone want the world to look like when this project is done?  Is capacity higher?  Turnaround faster?  Errors reduced?  Is there a totally new process?  Is there a shiny new system? 

3)      What are the problems? – (Remember, we can use the politically incorrect “problem” because it’s a personal document) What’s keeping us from getting to the desired state?  What issues do we keep tripping over?  Who’s being difficult or unrealistic?  Is the schedule reasonable?  What am I awake at 4:00 AM worrying about? 

4)      What can I fix? – Here, I sort of break one of my rules.  I try to identify what I can fix that’s broken.  Key point:  What, not how.

a.       Right Now – What can I do right now without anything else happening first?  I don’t worry about time or resources; I just list everything I could theoretically fix.
b.       Right After – If I fix the things I could fix right now, what’s next?
c.       And Then?  – If I can theoretically get through the “Right Now” and “Right After”, what could I do? 
TANGENT 1:  It’s interesting to see if putting together these three lists naturally gets me to the desired state I defined in List 2.  BUT… I resist the urge to force it.  Be honest.
5)      What is my conclusion? – This is the part where I get to rant.  I just start writing about where I think this project is headed.  Hopefully, the first 4 lists I’ve put together have helped me get my head on straight.  If not, well, that tells me something too.  Seriously, I rant.  I tell it like I think it is.  No one is going to read what I say except for me.  Do I believe the project is going to fail?  I say it.  Then say why.  Do I think we need to go in a different direction?  I put it down.  Do I think I’m failing to deliver?  Why?  It’s the most liberating part of this process.  Feels like confession.

6)      What questions do I have? – I read back over my first 5 lists, and start writing down any questions I can’t answer.  Doesn’t matter how big or stupid or rude.  In the past, I’ve written thing like, “Does anyone care if this project succeeds?”, and “Can we hit deadline if [Name Redacted] keeps screwing up?”  I might never ask these questions out loud, but it’s therapeutic to ask myself.  I might even come up with a few that need real answers that I can ask in public and look proactive and smart. 

TANGENT 2:  If I can’t put the 6 lists together off the top of my head, this is a giant, flaming red flag.  If I can’t define where we are, or where we want to go, or what I can do to help get us there, I’ve got real problems. 

So, I’ve poured my thoughts and worries and soul into answering 6 basic questions.  What now?  I put it away.  I leave it alone to marinate for a day.  Then, I open it back up again.  I read it and try to see what the basic feel is.  Is it optimism or despair?  Was I overly negative, or did I apply false optimism to my lists?  And, most important, do I see the beginnings of a plan? 

Ninety-nine times out of a hundred, I see things I could be doing differently.  I can begin to filter out the things I can improve versus the things I have no control over.  I usually see a plan emerge.  I see a way out of whatever hole I’ve dug for myself (or been thrown into).  Most importantly, I have a lodestone in this assessment next time the manager asks me what I think.  I’ve already thought about it and put it on paper, and I’m not fumbling around trying to describe some general feeling of “Not Rightness”.

I don’t believe that there are impossible projects, but I do believe that there are impossible plans.  More than there should be, actually.  I know that Development Managers get sick of hearing us whine about the plan.  But, if I can say, “I have a few specific questions and ideas about the plan”, they usually sit up and listen.  See, there’s another dirty little secret that my dear friend Josh Lane told me once:  We all think there are these experts out there that have all the answers.  Guess what?  There isn’t.  It’s us.  We’re it.

Scary as hell?  Yes.  But it also means that it’s on us as developers to not just solve problems, but to help define them as well.  Ask anyone in our business… it really is harder than it looks.

Julie to Present “Cool Tricks to Pull from your SSIS Hat” at SQL Saturday #62 in Tampa FL

I am honored to be presenting at SQL Saturday #62 which will be held in (hopefully) warm Tampa, Florida on January 15, 2011. The title of my presentation is Cool Tricks to Pull from your SSIS Hat, and it covers the basics of SSIS variables and the Expression language. I will also be participating in the Women in Technology panel discussion.

This event, the first of 2011, will be bustling with fantastic speakers. I’m especially looking forward to the Powershell/SSIS Smackdown with Aaron Nelson (Blog|Twitter) and Mike Davis (Blog|Twitter).

I am also going to the PreCon which will be the Friday before the main event. This is a huge bargain and I didn’t want to miss the opportunity for an entire day of training on (SAN) storage and virtualization for DBA’s and BI for $99. I imagine I’ll be switching from room to room throughout the day. Sign up before tomorrow to join me at this price!

From Pam Shaw and Jose Chinchilla on the PreCon–>

We will also be hosting a Day of Data on 1/14/2011, the day before SQL Saturday #62 in Tampa at the Italian Club in the historic Ybor City district. We are offering 2 all day sessions from which to choose. For the DBAs we have Denny Cherry presenting Storage and Virtualization for the DBA. For the BI focus We have Stacia Misner presenting Business Intelligence End-to-End. The cost is only $99 per person thru 1/5/2011, after that the price goes to $109. This price includes coffee, juice and donuts, lunch, and course materials. Click here to register for Day of Data.

T-SQL Tuesday #13 – Make Nice with the Business

This month’s T-SQL Tuesday asks the following question:  What issues have you had in interacting with the business to get your job done?   First, much thanks to Steve Jones (Blog | Twitter) for hosting this month’s event. 

As the old joke goes, this job would be great if it weren’t for the users.  (insert rimshot here) Seriously folks, my job title has “Business” in it, so I’d better be able to figure out what the user is asking for.  Being a BI Consultant is one part developer, one part psychologist, one part archaeologist, and two parts translator.  If the user asks for a report, that’s great.  Actually, that’s more than I often get.  Sometimes I get vague, conflicting requests.  Sometimes I get requests that just confuse me. 

Take my Top Five Favorite requests from end users: 

5) “There’s this report that John used to produce in 1997.  It was great.  It took him 12 days to put it together, but it had everything I needed.  I want that, only sooner.”

It’s a shame that John checked himself into a mental facility in 1999 and is now spending his days creating lovely landscape paintings with non-toxic watercolor paint and taking meds on a rigorous schedule.  It’s also a shame that no one can remember what the report looked like, only that it was really good. 

4) “I want to slice and dice the data however I want.”

Not bad.  At least they’re referring to being able to filter the data in some way.  The scary part of this request:  “However I want”.  Do you want to slice the data by what color shirt you were wearing on that day?  Let’s narrow this down a bit. 

3) “I’m not sure what I want, but I’ll know it when I see it.” 

–Sobbing–  You’ll know it when you see it?  Okay.  Okay… let’s extend that deadline. 

2) “The data should be sexy.” 

Sexy?  Let’s define sexy.  I think beautifully-structured, properly normalized, and well-performing data is sexy.  Is this what you meant?  No?  Wow, I thought we were on the same page here. 

And my all time favorite user request….

1) “I want it to be like an iPhone.  You know, an Apple feel to it.”

What, you want the data to wear a black turtleneck?  You want to be able to swipe and pinch the data? 

Users, I love you.  You keep my mortgage paid and my kids in shoes.  Truly, if it weren’t for you, I’d be out of a job.  But, sometimes, you make for good happy hour stories. 

Just this past week, I ran into a situation that BI Consultant nightmares are made of.  Let me set the stage: 

I’ve been at a new client for about 3 weeks.  Let’s just say I’m not exactly the resident expert yet.  It’s a very large client, with a very challenging data environment.  It’s the beginning of the month, which means that end-of-month and some quarterly reports are due.  Most of these processes have not been automated yet.  Read:  We’re copying query results into Excel and e-mailing them.  The one guy who is the resident expert is on vacation.  I get an e-mail asking for a report that I’ve never seen before. 

I take a deep breath, gather myself, and respond, “Yes, I’ll get that to you.” 

I make a quick phone call to the guy who’s on vacation, get a bit of info, and create the queries to run the report.  I slap that data into Excel, e-mail it out, pay myself on the back, and go home.  Everything looks great from my end. 

Next morning, 7:24 AM, an e-mail is delivered to my inbox.  To paraphrase, it said, “I don’t trust these numbers.  There’s a huge variance in the 3Q numbers that we can’t explain.  I have a meeting at 9:30 about these results, and I’d like to definitively say whether they’re correct.” 

Crap.  I’m not even through my first cup of coffee yet.  I top off my coffee, and begin my investigation.  This is the archaeologist part of my job.  On the surface is a report that isn’t making sense to the business.  My job is to dig backwards until I either come up with an explanation or prove that the data is correct.  No easy task, considering that I honestly don’t know where much of this data is sourced from. 

Step 1:  Verify Your Own Work – First, I opened up the query I ran to produce the report.  Key point here.  I saved it.  I save everything.  My first move was to verify syntax.  Did I do something stupid like join a table to itself or create a funky WHERE condition?  Did I accidentally paste something into Excel improperly?  (Tangent:  This is why automation is a Good Thing.  Eliminates human error.)  Nope, All quiet on the Western Front. 

Step 2:  Verify the Data Load – This data was sourced from a report database that is populated via an SSIS package.  Luckily, the guy who wrote the package sits a few rows over from me.  I check in with him, and he confirms that nothing has changed since the last load.  I ask for the source files anyway so that I have some outlets for additional research. 

Meanwhile, my Key2 Consulting compadre, Josh Robinson (Blog), is doing something really cool to help me out… He pulls the data into Excel and fires up PowerPivot.  Using the graphing functionality he’s got with the tool, he can point out anomalies in the data by different dimensions to try to narrow down exactly where we’re seeing the suspect data.  I was writing manual PIVOT statements in T-SQL, which was much less efficient than what he was doing.  Lesson Learned:  PowerPivot ain’t just for end-users.  It’s a great diagnostic tool. 

Step 3:  Verify the Source Files – I take a look at the source files.  Ha!  There!  The source data has the same disparity that the business users are complaining about.  This is good news.  This is a lead.  Now, I just have to find out who created these files. 

Step 4:  Find the Source File Owner – I make some calls, do some checking, and voila!  I have a name and a phone number.  It’s a very large company, so he’s halfway across the country, but I’ll still be able to get in touch with him. 

Step 5:  Contact Source File Owner – I call the guy who creates the source file.  He doesn’t know me from Eve.  After the requisite introductions, I ask about the change in the data.  He responds, “Oh yeah, we changed the way we’re pulling this piece of data.  You should see a huge increase in the number of gizmos from this month to that month.”  I thank him profusely, and move on. 

Step 6:  Wrap it all up – I make a courtesy call to the woman who is probably drumming her fingers on the table waiting for the data.  Then, I write up an e-mail with our findings, and I send it out to anyone who might care.

Wait, you thought we were done?  No, we’re not done.  Let’s back up a bit.  Yes, we explained the questionable data.  But a good archaeologist knows to dig just a little bit more.  I ask the business users, “Hey, so that source data changed, and the change was applied to this month but not that month.  Are we okay with that?”  This lead to another round of conversations.  Ultimately, we decided to keep the data as-is and note the reason for the change.  The point is, if you want to try to make friends with your business users, you answer the questions they have, and then try to think of the ones they haven’t asked yet.  They’ll love you for it.

T-SQL Tuesday: Why are DBA Skills Necessary? – A Datachix Perspective

I have a few confessions to make: I encourage my son to watch Phineas and Ferb because I secretly enjoy it. Jersey Shore is strangely entertaining. I claim that I don’t sing, but if you ever see me alone in my car on I-85, I’m probably wailing away. I read all four Twilight books. I have a crush on Nathan Fillion.  And… lean closer… I’m going to whisper this one: I’m not a DBA.

My resume would say otherwise. I can point to multiple job titles throughout my career that have the words “Database Administrator” in there somewhere. Guess what? I’ve never been a DBA, and if pressed, I’d call myself a Developer. Now, I’ve made peace with this. I love what I do, and I’m pretty good at it, even if it is difficult to explain to non-technical people the difference between being a DBA and a Developer. I think the confusion comes from the fact that there are so many job titles, and they’re all kind of vague. People assume that if you work with data you’re a DBA. They assume that we all have the same skill set. The truth is so much more complicated.

See, there is a LOT of specialization out there. I’m currently a BI Consultant. Before that, I was a Data Architect, doing BI work. Before that, I was a “DBA”, developing relational databases. But, at the end of the day, I’ve got a specialization. I model and develop databases, and I move data around. Over the past few years, I’ve started traversing the BI stack, but at the end of the day, I’m really just a Database Developer. The simple truth is that there are so many angles and disciplines within the data universe, you have to be specialized. To borrow a silly cliché, anything else would be drinking from the fire hose. You’d get soaking wet, and you’d probably still be a little thirsty.

So, to the point. Paul Randal raised some great questions for this T-SQL Tuesday, “Why are DBA Skills Necessary?” I want to focus on a sub-topic he suggested, “Should there be cross-over between developer skills and DBA skills?” On the surface, the answer is an obvious, “Yes!” It was for me too, until I actually sat back and thought about it. My new answer is, “Yes, to a point.” See, asking me, a non-DBA, to attempt to be a DBA is like asking a psychiatrist to perform heart surgery. Yes, they both went to medical school, and yes, the psychiatrist could probably hold up his end of the conversation with a heart surgeon, but really, would you want him to cut on you? Probably not.

Here is my perspective: I need to be aware of what’s going on within the Database Administration universe. It’s why I attend both the Atlanta MDF, which is largely DBA-focused, and the BI User’s Group. I read blogs, books, and articles related to the entire data universe, not just my specialization. In fact, there are many, many things DBA’s do that I wish I knew better. I need to have a good vocabulary in the discipline, and I need to be able to carry on intelligent conversations with DBA’s. Does this mean that you should trust me to be your DBA? Probably not. By the same token, I also see application development in the same way. I should be able to discuss application development intelligently, but I don’t really know how to do it properly. Don’t get me wrong… I’m competitive enough that I want to be an expert at everything, but I’m also realistic to know that I’m never going to.

See, to lump us all into one “DBA” bucket is to diminish the amazing job that so many DBA’s do every day. To pretend that I could step into a server room and hold my own unassisted is not only arrogant and delusional, it is dangerous.

Which brings me to the next point…

“At what point does a SQL Server installation need a DBA to look after it?” Immediately! Friends, your DBA is not just the chick who does backups and restores. You know how developers complain about not being brought into the development cycle early enough? Like when requirements are being created? Well, how does the DBA feel? We pretend that we understand the DBA discipline, and muck around in our development environments, making wild assumptions based on test data sets. Then, just before going to production, we dump an entire environment on the DBA and ask her to make our hot mess of a product perform well. Even worse, we act like that annoying taxi passenger telling the driver to take the Connector instead of the Perimeter because its 5:17 on a Friday and we think we’ve got Atlanta traffic down to a science. Like I know more about how to get around the city than the guy who does it for a living? Right.

Good DBA’s, and I’ve been lucky enough to work with quite a few over the years, know as much or more about the business being served by the database as the rest of the development team. That’s a key point… The DBA is part of the development team. Business requirements translate into administrative requirements, so get that DBA in the room early and often! And if you’re lucky, by hanging out with the DBA more, you’ll learn a thing or two about her side of the world.

On Bobby Cox

Today is Day 1 A.B. (After Bobby)  I can’t help tearing up a little when I watch the video of his last post-game press conference.  He was a class act and I can’t imagine baseball, especially Braves baseball, without him. 

I know what you’re thinking… “Datachix, what does this have to do with data?”  Well, Dear Reader, let me tell you.  We could all learn a thing or two from the legendary Skipper.  Actually, there are five. 

1) Loyalty is NOT overrated.  I don’t know that I’ve ever heard Bobby say a harsh word about his players, even after a loss.  He might point out mistakes they’d made, or reasons why they lost, but he immediately followed it up with a comment about how they’d get them next time, and how his boys played hard.  I don’t know about you, but I wouldn’t have been able to resist bashing Brooks Conrad after 3 errors cost us Game 3 in the NLDS.  What did Bobby say about whether he’d bench him?  “I’ll have to sleep on it.”  That’s classy.  How many times have I railed against a fellow developer who broke a build?  How many times have I complained loudly about how a project was going?  More times than I’d care to admit.  And, managers all over IT could use his playbook to improve their management style.  In a perfect world, Bobby would become the development manager on my next project.  Tell me you wouldn’t work harder for him than anyone. 

2) Stand up for your team.  He’s been ejected over 150 times (161 I believe, if you count the post-season).  If Bobby saw an injustice being carried out by the umpires, he was going to get out there and in someone’s face.  Now, I don’t suggest that we all get ourselves carted out of the building by security next time something unfair happens, but there is something to be said for a manager who’s willing to step in and take the heat for his guys.  Many times, he would step in and get himself ejected to save one of his players.  Next time you see a co-worker getting treated unfairly, ask yourself:  What Would Bobby Do? 

3) Find your passion and live it.  Bobby Cox started playing baseball professionally over 50 years ago.  Can you even imagine spending 50 years of your life doing anything?  If you truly love what you do, then good for you.  If not, then find it.  If nothing else, find something you love about your career and focus on that.  Bobby was a mediocre baseball player.  He only really played two seasons professionally.  How lucky are we that he decided to stick with the game that he loved and find a way to be a part of it instead of going off to sell insurance somewhere? 

4) Be a mentor.  Ask anyone who’s played for Bobby.  He’ll tell you that Bobby was a mentor, a teacher.  Jason Heyward will be a better player because he got just one season with Bobby.  There’s a reason that the Braves clubhouse is considered one of the most professional and welcoming in Major League Baseball.  Bobby set the bar, and then taught his guys how to reach it.  HOw many less experienced people do you work with every day?  Do you shrug and roll your eyes when they struggle, or do you step in and patiently teach them how to improve.  Again, What Would Bobby Do? 

5) Talk softly, but don’t be a softie.  Okay, so Bobby’s temper was legendary (note the 161 ejections).  But for the most part, he’d sit there on the dugout bench or lean against the railing, quietly watching the game unfold.  He didn’t rant.  He didn’t rave.  He made decisions, sometimes tough ones, with respect and thoughtfulness.  I see so many of us (myself included), so eager to prove our worth and expertise bluster and proclaim our ideas for the world to hear.  How about we take a page from Bobby’s book and just let the record speak for us?  How about we make tough decisions with less drama?  How about we sit back and watch the game unfold for a while before we jump to conclusions?  That’s Bobby’s way. 

Anyone who knows me personally knows that I love my Braves.  When I adopted Atlanta as my second hometown, I was lucky to have a great baseball team to go along with it.  Bobby Cox was a big part of that.  In an age of juiced players, and scandals, and waning interest in the sport, Bobby represented an old school approach to a game that I’d grown up with.  So, if you ever see me sitting back, quietly watching the game unfold, resisting the urge to jump in with opinions and half-formed ideas, you’ll know I’m getting my Bobby on.

Why You Still Count as a Person if You Have Used Microsoft Access—(or How Old Are You, Julie? (or the overuse of parenthesis in early 21st century Bloggery))

( )

(A Short blog post for DYFHID.  This is like, eight years later than I had hoped, but I do like to keep my promises.  )

Yes, people rag on MS Access. Yes it’s a tippy tool.  YES, you really SHOULD wean yourself off of Access and move to SQL Server as quickly as possible if you like this crazy mixed up data business (and making money). 

But let me share my Holly Hobby Sewing Machine story with you.  (really Julie, Holly Hobby?  How old are you?) 

When I was a kid I had a toy Holly Hobby sewing machine.  It was made of thin plastic parts, glued together with finger paste.  It couldn’t do much.  If you tried to sew through more than 2 kleenex depth worth of fabric, or tried to go too fast, or tried to do any fancy curves or zig-zags, it would complain loudly and break in some dramatic way.   But –using it I learned the absolute basics of sewing and sewing machines.  Thread the needle. Thread the bobbin.   Push the pedal to sew the fabric together.  Avoid Puckering. (tee hee, you said pucker).   I quickly realized I needed a better tool and moved on to a domestic sewing machine designed for grownups with denim, and even eventually supported myself as a costumer using super duper industrial machines capable of sewing diamonds to kryptonite at the speed of light.

There was a similar evolution in my technical career.   I spent the first four years of my career at a business where the primary data was stored in a COBOL application.  The reporting and data extraction were all done through ODBC links to —(drumroll please) MS ACCESS 97. 

It was tippy.  It didn’t scale.  It was located on my local machine.  It used way too many staging tables, because its memory couldn’t process the data from the application without freezing and dying.  If you tried to do anything fast or fancy, it would complain and break, just like my toy sewing machine had done 15 years previously.  But—using it I did learn the absolute basics of sewing database programming and design.  Create a table.  Create another related table.  Write queries.  (Access does not in any way prevent the design of properly normalized data models)

 I forged on learning how to write decent (albeit tippy) databases and got quite a lot of work done with them, considering.  I did realize that I needed to make the switch to the heavy duty Server Technology and paid for my own training in SQL Server, then through stubborn perseverance got a job using it.  Several jobs later, here I am.  I haven’t seen the inside of Access in years.

Here is my point (and yes thank you Ellen DeGeneres, I do have one) (**are you quoting the title of Ellen DeGeneres’ 120 year old book?, SERIOUSLY Julie HOW OLD ARE YOU?)

I am not a bad developer because I started with Access.  It didn’t cause brain damage.  I was a good Access programmer and I am a good SQL Server developer because I have a fairly logical, process oriented mind.  No matter what tool I am using, I still have to process my data logically and efficiently.  I still have to listen to my users, formulate a plan for how to realize their dreams and implement that plan, using the best tools at my disposal. 

A person can have a lot of technical knowledge about SQL Server and still miss the mark on a project through any number of missteps (I.T. projects are fraught with peril—never forget that).  Never underestimate the importance of being smart and attentive.  You can’t fix stupid with a better tool.

(Now if you’ll excuse me I’m off (to lunch) at Piccadilly.)