First Day of Work Karen: What I Would Tell Her #mememonday

It’s time for another Meme Monday, as assigned by Tom LaRock (blog |@sqlrockstar ). In his post, he asks us to write about:

If you could go back in time and meet yourself on Day One of your IT career, what advice would you give?

What a great question.  I’ve previously blogged about What I Would Tell my 16 Year-old Self .  All good stuff there.  Especially about the hot rollers.

But what would I say to Karen Lopez, brand new Senior Systems Analyst (yes, that was my first job title)?  There a bunch of small stuff that really turns out to be big stuff later:

• Skip the Full Day Voice Mail Training.  Sure, it was mandatory, but the guys only had to do a half-day version of it.  Insist you don’t know need a full day.  Set the direction for how the team sees your role on the project from the start.
• Don’t let that clerk at the Passport Office talk you into bad data quality: alphabetizing your names on your passport.  That one decision is going to impact you more than you can ever imagine.  But you will get some great data quality presentation material out of it.
• Respect your boss, but don’t let him manage your career.  My first boss started on the same day I did.  He wasn’t a twenty-something, though.  He had retired from the US Army the day before and had come to work for the defense consulting company I worked at.  To manage projects for the US Army.  Funny how that works.  He brought with him his military bearing…and his need to be in command of everything, even the technical design of the application we were building.  Even though he was an accountant and had no technical experience or training. 

  He and I didn’t really look at life the same way, but he was my boss.  I let him manage my professional development plan, my training, my assignments much more than I should have.  He wasn’t a good fan of female engineers, either.  So our non-technical tester was the guy who did all the demos and presentations, even though he really could answer any of the technical questions he received.

  Karen, that boss should not have been able to set your path, only guide it.

• Don’t try to explain everything that caused a bug or a mistake in a deliverable.  Just fix it and fix the problem that led to it.  Nobody really cares why it happened unless the think you are going to do it again.  Fix it, learn from it, move on.   Don’t make your mistakes stand out more than anyone else does.  Be honest, but don’t broadcast them.
• Never accept the first offer.  I can’t tell you, Karen, how many times you are in a negotiation and don’t even realize it.  The earlier you realize this, the better off you will be.  Think your boss is doing you a big favor by sending you on a local one day course?  Sure, she is.  But she’s sending Chad on a full week of bootcamp training because he asked for that instead.  Think you are fortunate because you are getting a 5% raise? You are, but Chad got 10% because he negotiated it.
• You will make great friends at work.  But they are your colleagues first.   Save the details of your life for friends outside work.
• No one cares what shoes you are wearing…as long as you can keep up the sprint with everyone else.  Wearing impractical shoes is going to slow you down. That’s literal and figurative advice.  See, double the value.

I think First Day of Work Karen did okay over the years. She got to work at all three branches of the US government during her first job.  She played volleyball on the Mall.  And she learned a lot about voice mail, a bleeding edge technology then.  But there were more important things to learn along the way.

Was I Too Snarky? A Big Data NoSQL Roast

At Enterprise Data World last week I had a chance to defend my crown at the Lightning Talk sessions.  Lightning Talks are 5 minute presentations, usually done to highlight one point or to motivate people to go do something.

Most of my lightning talks, though, are rants on some thing.  Think a 5-minute long roast.  This year, I picked on Big Data and NoSQL names and terms.  While it appears that one person didn’t fully grasp the "roast" part of this rant, I think I did okay. At least most of the laughter wasn’t at me, but with me.

Mark Burnelli, Senior New Editor at SearchDataManagment.techtarget.com wrote an article about my rant:

The humorous verbal shellacking of big data — which generated plenty of audience laughs — came at the hands of Karen Lopez, a senior project manager and principal consultant with InfoAdvisors Inc. Lopez is also proprietor of the popular Datachick Twitter feed and often uses that outlet to post admittedly snarky comments about the world of information management.

Datachick gives ‘big data’ a verbal beat down at Enterprise Data World

I did start my presentation by saying:

By the way, every single one of these rants is totally unfair, cherry picked and irreverent.  I know. It’s shocking.

I will be blogging the entire rant over on Dataversity.net and will post here when it goes live.

Update:

• My blog post with the Big Data rant is now up on Dataversity.
• John Biderman has blogged there about his NoSQL Epiphany.
• Paul Williams coved this rant in is Overview of Enterprise Data World 2012.

I should also mention, to those of you snickering, that I am currently drafting a similar rant for the RDBMS technology/naming/terminology set.  It will also be full of snark.  Shocking, I know.

I’m Speaking at Enterprise Data World – Atlanta

I’m not sure, but I think I’ve been attending the Enterprise Data World event (formerly the Wilshire Meta-Data/DAMA Symposium) since 1998 and speaking at most of them.  There’s a reason I keep going back: this is my annual "revival" for networking and collaborating with other data professionals.  I need that fix, every 12 months or so, to focus on sharing and caring about data modeling, database design and tools.

This year the event will be held in Atlanta, so at least we’ll be warmer than some years, right?  I remember a particularly freezing March in Boston.  I don’t want to repeat that, ever.

By the way, there is still time to register and I believe there is still a $100 discount available.  If you can’t find that, contact me and I’ll see what I can do for you <grin>.

My Events

This is a busy year for me at EDW.

Kick-off Panel: I’ll be part of the "Welcome Panel" moderated by Tony Shaw of Dataversity.  Jaime Fitzgerald, Peter Aiken, Sue Gueuns and I will be talking about our tips for getting the most out of the event, including our recommendations for the sessions we most want to attend.

http://edw2012.dataversity.net/sessionPop.cfm?confid=65&proposalid=4803

Size Doesn’t Matter: I’ll be defending my Talk Champion crown sweatshirt at this year’s Lightning Talks.  All other speakers, be warned.  I talk FAST.  I’m also known for going for the cheap jokes that get votes.

http://edw2012.dataversity.net/sessionPop.cfm?confid=65&proposalid=4813

ER/Studio Special Interest Group: I’ll be leading a user-to-user discussion of Embarcadero and their database and data modeling tools. We will have Embarcadero reps there to contribute, but this is still a user group meeting.  You don’t have to be a current customer to attend.

By the way, there are also SIGs for CA ERwin Data Modeler and Sybase PowerDesigner going on at other times. 

http://edw2012.dataversity.net/sessionPop.cfm?confid=65&proposalid=4505

Finding Myself: A Case Study on Your Data Model, My Data and Me:  This is my regular session at the event, where I take a snarky look at how your systems mess with my data…and how I pay the price for that messiness.  I hope you’ll join me for this irreverent look at cost, benefit and risk choices that "they" make when "they" manage our data. 

http://edw2012.dataversity.net/sessionPop.cfm?confid=65&proposalid=4496

Data Modeling Power Panel – Contemporary Issues in Modeling:  I’ll be participating in Alec Sharp‘s panel along with Michael Blaha and David Hay on forward-looking topics in data modeling and management.  My topic will focus on NoSQL, especially extensions to relational DBMSs.

John Zachman

This year marks the 30th year since John Zachman shared his Zachman Framework with the world. There will be a special event on Wednesday evening to recognize his contributions to enterprise architecture over the last three decades. 

Social

Of course in addition to all the great sessions, there will be social events and time for catching up on what other data professionals have been up to since I saw them last year in Chicago.

For those of you who can’t make it, a bunch of us will be tweeting using the hashtag #EDW12.  You can follow along on Twitter, even if you aren’t signed up for it, by going to http://search.twitter.com and searching for "EDW12"

I hope to see you and get a chance to chat with you at this year’s EDW.  That’s why I go…the sessions are great, but the chance to share ideas, tips, tricks and data stories is what keeps me coming back.

Sometimes You Just Shouldn’t Jump In Feet First #FailFriday

Pipeline im Bau (Photo credit: Wikipedia)

 

Thinking about it, this could also be titled “There’s No I in Team” or “Communication is Key”.

About 20 years ago I was a young(er) Engineer working away at a company learning all about how things worked.  I was given the task to look after and inspect a pipeline project that was about 20 kilometers long.  One of the tasks at the end of the project is to test the pipeline before it is put into service.  The tests are done with water and the pipeline is pressurized almost to its full theoretical yield strength.

In the days leading up to the tests there wasn’t much for the inspector (me) to do so I helped out the contractor doing some menial tasks on the site.  One of them was filling this long pipeline with water.  We used a small water pump that pumped at a maximum of about 200 psig.  Not much compared to the full yield pressure we were going to test at.  As you can imagine when you are testing a pipeline at over 1,000 psig you have to use some pretty heavy duty fittings so we could pretty much do whatever we wanted with that little pump…including closing the valves with the pump running.  Remember this as you read on…

The day of the test everyone got there, we set up the test assembly, the dead weights to measure the pressure and a high pressure piston pump.  This piston pump can pump in excess of 3,000 psi, but it pumps relatively slowly compared to the pumps we used to fill the pipeline.  But think about it, water is incompressible so if the pipe is already full of water it doesn’t take a lot more to get it to the test pressure.  I forget the exact values, but it was probably about 400 to 500 gallons of water that we needed to pump in.

So we started pumping water and found it was taking extra time to get the pressure to rise the way it should.  Sometimes you see this if there’s a bit of air in the line, but in this case the pump just seemed extra slow.  I had been on tests before (and had them go wrong before) and I knew (or thought I did) what was happening.  We stood at the top of the excavation looking down at the test head and wondered what was wrong.  Without saying anything to anyone, I jumped in the excavation and put my ear next to the valve.  It didn’t sound right to me.  So guess what I did….I closed the valve.  In my mind I thought there might be something in the valve and if I closed it and opened it again right away maybe it would help.  It was a sound theory, right?  Wrong.

Remember what I said about using heavy duty fittings?  The valves were 2” ball valves rated at 3000 WOG or 3,000 psig.  Remember what I said about the piston pump being able to pump in excess of 3,000 psig?  Guess what happened when I closed that valve WITH THE PUMP RUNNING?  Let’s just say I never got the valve open again.  I took the top of the valve, the handle and the stem in the chest.  Lucky for me I was bent over the valve far enough and it was late fall I was wearing enough winter gear it wasn’t too bad.  I got a face full of water right away so I didn’t even realize I got hit by anything else.  It wasn’t until later that I started feeling a dull ache that let me know.

I was working with a team.  Had we actually talked about the issues and what we should be doing I never would have dead headed such a strong pump against a closed valve.  We may have closed the valve and reopened it based on my theory, but we would have shut the pump off first.

Sometimes you just shouldn’t jump in feet first.

Yeah, Those Strawberries #FailFriday

As I called for last week, this is my #failfriday blog post.  I’ve made so many mistakes, it was difficult to pick one.  There was the time I did a quick spellcheck of a letter to a key client and managed to change his name to Murderer, as in Dear Murderer.  Those were good times.  Then there was the time I generated and printed about 1000 graphs for evidence in a court case and managed to screw up the last data point on every single one of them.  This was an instance of an off-by-one error.  So they all had to be redone on a pen plotter.  That takes days….and lots of pens.

Of course, I’ve had many of the #fails that most people shared on Twitter: Running a script or command in the wrong location, usually the wrong server or directory, and wiping out data that had not been backed up.  I have a feeling this is a requirement to become a professional: this fail changes you for the rest of your career.

I decided to pick a trivial fail, but one that showed the dangers of being a data architect.

Strawberry Fields Forever

In Ottawa I lived near a strawberry farm.  How wonderful it was to have fresh strawberries, picked minutes before, for several weeks.  One night I was driving back from the city and stopped by the farm to see if they had any for sale.  I remember I was wearing a suit, heels, the whole business chick outfit. Not really strawberry picking attire.  So I was on a mission to get berries that had been picked by other people.  You could buy strawberries two different ways:

• Pick Your Own:  Basically the farm gave you trays and you picked your own and paid the cheapest rate.  Because carrying trays was hard work, people would fill the trays, then bring them to sales hut to hold them.  Then the pickers paid for all of  them at once.
• Already Picked: Local kids would pick the berries and bring them to the sales hut and get paid for picking them.  Buyers like me paid a premium for having the hard part done for us already.  However, if you got there late in the day, like I did, the chance of finding these was rare.

So this was my plan: buy a flat of “already picked” berries.  That was my category, remember.  Not “Pick Your Own” but “Already Picked”.  See, I was thinking like a data architect.  Those were 2 subtypes of STRAWBERRY: ALREADY PICKED STRAWBERRY and PICK YOUR OWN STRAWBERRY.

So I waltzed up in my blue power suit, looked at the shelves in the sales hut and saw many flats of berries and asked the bored teenage sales girl “Are those strawberries already picked?”

Are those strawberries already picked?

….I’ll let you guess what happened next.  If you picked “laughter, eye rolling and general snickering”, you’d be spot on.  See, it turns out that the sales girl didn’t live in a land of data architecture, where everything is categorized, sorted and taxonomized to the 9th degree.  She lived in the real world, that place where strawberries are either still on a plant or not. 

I  learned my lesson that day.  Data architects sound funny outside their normal habitat, those whiteboard-shrouded conference rooms where data is managed.  And sometimes we sound really silly in the real world.  We need to remember that.

#FailFriday meme: I Was Young and Didn’t Know Any Better

For 24 Hours of PASS I moderated a panel of SQL Server experts on mistakes they made: I Was Young and I Didn’t Know Any Better.

So I’m inviting everyone, including my panelists, to share a mistake they made, how they recovered from it, and the tips they want to share on making things right after making a mistake.

While this is a #FailFriday meme, you can take your time to put your post together – post it anytime in the next week.  I will summarize all the posts here.

For this week, you should write about mistakes you made because you were inexperienced.  We’ll have a new #FailFriday about other type of fails next month.

No need to do anything special for linking.  If you want to appear in the summary, use the hashtag #FAILFriday or leave your link in the comments.  My post coming up when I get to the next airport.