Browsing articles tagged with " Rant"

Strutting: We all Know When You are Doing It. So Stop.

Jun 25, 2014   //   by Karen Lopez   //   Blog, DLBlog  //  No Comments

Rant Level: High. It’s Friday. 

Kanye West Ruins Taylor Swift's VMAs Win

 

I was reading an ACM blog post by Judy Robertson about strutting, a tactic used by audience members at event.  Robertson discusses a specific type of this behaviour, done by IT people: nerd strutting

Garvin-Doxas and Barker (2004) refer to "strutting" as a style of interaction where people show off their knowledge by asking questions carefully designed to demonstrate that they know a lot about the topic, and quite possibly that they know more than everyone else around them. The problem with this in a learning situation is that students who lack confidence assume that they are the only person who doesn’t understand, and quickly feel even more demoralised.

The full paper is available if you’d like to read about the study these researchers did on Defensive Climate in the Computer Science Classroom.

I’m betting you’ve seen this behaviour before.  In fact, I’d bet that if you attend enough events, you could name the people most likely to nerd strut before the speaker has even gotten 15 minutes into her presentation.  They ask questions, often sprinkled with references to product codenames, Greek philosophers, small startups and archaic error numbers.   They use highly jargonized terms.  They use insider terms. They want you to feel outside the inner circle.  They want you to know just how freaking smart they are.  But you know what’s funny?  The vast majority of the people in the room can see what they are doing and silently smirk.   

I’m interested in hearing just what sorts of people fall for this bravado.  Everyone else in the room talks about how insanely annoying the behaviour is, but no one wants to do anything about it.  I’m not even sure what we can do about it, other than to ask audience members to stop.  

Insults R Us

Another tactic that nerd strutters do is sit in the audience and stage whisper criticisms of the speaker and the topics.  I find this incredibly annoying as an audience member.  It doesn’t impress me, nor does it make me feel as if the strutmaster is actually convincing anyone he is superior. A variation of this is a group of people, chatting with each other and loudly snickering about the speaker or the topic.   

If you are sitting in a presentation and you find it too "level 100” for your tastes, you should just get up and find a presentation more fitting for your enormous brain…or whatever body part is keeping you from learning anything.

Why it Matters

I know, some of you are saying “But Karen, just ignore the @$$#@+s that do this stuff”.  I do, mostly.  However, Garvin-Doxas and Barker found that the effect of many types of negative communication, even when it was not intended, has a negative impact on many students, especially women.  Yes, women should suck it up and learn to play the game of competition.  But we don’t do it that well.  In general, women prefer a collaborative environment.   We love a bit of friendly competition. But one where team members insult others in public? Not so much.

The authors point to the fact that IT work is highly collaborative.  Supporting and enabling a culture of jabs, insults, mockery and distain works against that goal.  I hear people constantly ranting that topic X should not be on a conference agenda because it is isn’t what *they* want  learn.  I say “choose another session – there are several other tracks”.  When I see someone nerd strut in front of an entire audience, I want to call them out – tell them they are showing off.  We can all tell when a question isn’t really a question. I don’t call people out on this, though, because no one else does.

What to Do

Robertson gives 3 tips in her blog post on dealing with nerd strutting.  Go read them.  I’d love to see the community deal with this in a consistent, collaborative way.

I’d like to add to them:

1. Encourage others to ask questions during presentations.  One of the reasons why many nerd strutters can do what they do, often several times in the same session, is that very few people ask questions or give commentary.  If enough people are asking legitimate questions, then the strutters get less show time.

2. Ask the Insult R Us people to take their conversation elsewhere. It’s annoying enough to hear anyone ramble on while you are trying to listen to the speaker.  It’s not rude or unfair to ask people, no matter what they are talking about, to either be quiet or to wander somewhere else.

3. Stand up to people who insult the work of others.  This one is the biggest pet peeve of mine.  It’s fine for people to be proud of their own work.  It’s not cool for them to insult the work of others just because they think it’s easy or low-level stuff. I don’t just draw boxes and lines all day.  BI professionals don’t just draw bar charts all day.  Developers don’t just type all day.  We all have difficult jobs.  I don’t need to step on someone else to raise myself up.  I will continue to speak out to the people who need to insult others.  I’m hoping you can, too.

Community Impact

From the paper:

Finally, when people communicate certainty in a dogmatic fashion, they also tend to communicate a low tolerance for disagreement. When defensive communication becomes habitual in a social context, it engenders a "defensive climate." Distrust of others becomes the norm, resulting in a social environment privileging competition over cooperation.

We all need to recognize that this negative behaviour hurts everyone.  It poisons the community.  It drives people away, especially new community members and those who want to work together to solve problems and build the community.   And we all need to work together to keep people focused on making the community an inclusive, inviting environment.

Garvin-Doxas, K. and Barker, L. J. 2004. Communication in computer science classrooms: understanding defensive climates as a means of creating supportive behaviors. J. Educ. Resour. Comput. 4, 1 (Mar. 2004), 2. DOI= http://doi.acm.org/10.1145/1060071.1060073

.

Strutting: We all Know When You are Doing It. So Stop.

Apr 26, 2013   //   by Karen Lopez   //   Blog, Fun, Snark, Speaking  //  12 Comments

Rant Level: High. It’s Friday. 

Kanye West Ruins Taylor Swift's VMAs Win

 

I was reading an ACM blog post by Judy Robertson about strutting, a tactic used by audience members at event.  Robertson discusses a specific type of this behaviour, done by IT people: nerd strutting

Garvin-Doxas and Barker (2004) refer to "strutting" as a style of interaction where people show off their knowledge by asking questions carefully designed to demonstrate that they know a lot about the topic, and quite possibly that they know more than everyone else around them. The problem with this in a learning situation is that students who lack confidence assume that they are the only person who doesn’t understand, and quickly feel even more demoralised.

The full paper is available if you’d like to read about the study these researchers did on Defensive Climate in the Computer Science Classroom.

I’m betting you’ve seen this behaviour before.  In fact, I’d bet that if you attend enough events, you could name the people most likely to nerd strut before the speaker has even gotten 15 minutes into her presentation.  They ask questions, often sprinkled with references to product codenames, Greek philosophers, small startups and archaic error numbers.   They use highly jargonized terms.  They use insider terms. They want you to feel outside the inner circle.  They want you to know just how freaking smart they are.  But you know what’s funny?  The vast majority of the people in the room can see what they are doing and silently smirk.   

I’m interested in hearing just what sorts of people fall for this bravado.  Everyone else in the room talks about how insanely annoying the behaviour is, but no one wants to do anything about it.  I’m not even sure what we can do about it, other than to ask audience members to stop.  

Insults R Us

Another tactic that nerd strutters do is sit in the audience and stage whisper criticisms of the speaker and the topics.  I find this incredibly annoying as an audience member.  It doesn’t impress me, nor does it make me feel as if the strutmaster is actually convincing anyone he is superior. A variation of this is a group of people, chatting with each other and loudly snickering about the speaker or the topic.   

If you are sitting in a presentation and you find it too "level 100” for your tastes, you should just get up and find a presentation more fitting for your enormous brain…or whatever body part is keeping you from learning anything.

Why it Matters

I know, some of you are saying “But Karen, just ignore the @$$#@+s that do this stuff”.  I do, mostly.  However, Garvin-Doxas and Barker found that the effect of many types of negative communication, even when it was not intended, has a negative impact on many students, especially women.  Yes, women should suck it up and learn to play the game of competition.  But we don’t do it that well.  In general, women prefer a collaborative environment.   We love a bit of friendly competition. But one where team members insult others in public? Not so much.

The authors point to the fact that IT work is highly collaborative.  Supporting and enabling a culture of jabs, insults, mockery and distain works against that goal.  I hear people constantly ranting that topic X should not be on a conference agenda because it is isn’t what *they* want  learn.  I say “choose another session – there are several other tracks”.  When I see someone nerd strut in front of an entire audience, I want to call them out – tell them they are showing off.  We can all tell when a question isn’t really a question. I don’t do call people out on this, though, because no one else does.

What to Do

Robertson gives 3 tips in her blog post on dealing with nerd strutting.  Go read them.  I’d love to see the community deal with this in a consistent, collaborative way.

I’d like to add to them:

1. Encourage others to ask questions during presentations.  One of the reasons why many nerd strutters can do what they do, often several times in the same session, is that very few people ask questions or give commentary.  If enough people are asking legitimate questions, then the strutters get less show time.

2. Ask the Insult R Us people to take their conversation elsewhere. It’s annoying enough to hear anyone ramble on while you are trying to listen to the speaker.  It’s not rude or unfair to ask people, no matter what they are talking about, to either be quiet or to wander somewhere else.

3. Stand up to people who insult the work of others.  This one is the biggest pet peeve of mine.  It’s fine for people to be proud of their own work.  It’s not cool for them to insult the work of others just because they think it’s easy or low-level stuff. I don’t just draw boxes and lines all day.  BI professionals don’t just draw bar charts all day.  Developers don’t just type all day.  We all have difficult jobs.  I don’t need to step on someone else to raise myself up.  I will continue to speak out to the people who need to insult others.  I’m hoping you can, too.

Community Impact

From the paper:

Finally, when people communicate certainty in a dogmatic fashion, they also tend to communicate a low tolerance for disagreement. When defensive communication becomes habitual in a social context, it engenders a "defensive climate." Distrust of others becomes the norm, resulting in a social environment privileging competition over cooperation.

We all need to recognize that this negative behaviour hurts everyone.  It poisons the community.  It drives people away, especially new community members and those who want to work together to solve problems and build the community.   And we all need to work together to keep people focused on making the community an inclusive, inviting environment.

Garvin-Doxas, K. and Barker, L. J. 2004. Communication in computer science classrooms: understanding defensive climates as a means of creating supportive behaviors. J. Educ. Resour. Comput. 4, 1 (Mar. 2004), 2. DOI= http://doi.acm.org/10.1145/1060071.1060073

.

Was I Too Snarky? A Big Data NoSQL Roast

May 7, 2012   //   by Karen Lopez   //   Blog, Data, Data Modeling, Fun, Professional Development, Snark, Speaking  //  2 Comments

SNAGHTML47a48628

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:

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.

Deadlines and Data Architects: You know the Date, Do You Know the Deliverable? #MemeMonday

Feb 6, 2012   //   by Karen Lopez   //   Blog, Data, Data Modeling, Database  //  7 Comments

It appears I’m an expert at deadline-driven accomplishments.  I mean, it’s meme Monday and even though I’ve known about the deadline for today’s post for weeks, I’m writing it at lunch on said day.  I’ve been thinking about what I’d write about for all this time, so it’s not like I’m just starting…but still, the deadline is what making this post happen.  I wish I could be the type of person who gets stuff done because it just needs to be done, but deadlines are what drive me. 

The ultimate inspiration is the deadline.
-Nolan Bushnell

I’ve been thinking about some experiences I’ve had working with other data architects and working with deadlines.  Usually as part of a team, we don’t get to set our own deadlines; they are set by a project manager or if we are lucky, via negotiation with the DBAs, developers and other architects on the team.  Our deliverables are typically the input into their deliverables, so their success is depends our getting our deliverables to them.  In my experience, though, it’s too common for data architects and data modelers to forget what deliverable those teams are waiting for or for them to make it available in the right format. 

In his post for #mememonday, Thomas LaRock (@sqlrockstar | blog ) give his best tip for working towards a deadline: work backwards.

What is Your Deliverable?

imageThis is the most frustrating question.  It should be very apparent to a data architect what deliverables the team needs from them.  But time after time I see modelers focused 99.999% on the data models.  Yes, your data models should be beautiful.  They should be complete, correct and pretty.  Every single one of them should get a trophy. All the meta data you want to capture about them should be in the data model.  Do you think, though, that your development DBA and developers are tapping their feet waiting for the PDFs of the data models?  Or do you suppose that they just might want that alter script to run in their environment so that they can get to work on their deliverables? 

Ideally, the team wants both.  They want the model to be created and they want the scripts with all the changes needed for their next deliverable.  I can assure you, though, that the scripts are what they want first.  I can also assure you that no one will love the data models more than you do, Mr. Data Architect.  So embrace the love you feel for the data models and funnel it into getting the "real" deliverable done:  DDL.  Sure, it hurts a bit that they don’t love your models as much as you do, but they will learn to love them because they produce beautiful databases.

On most my projects (mostly development ones) I never lose sight of the fact that ultimately, the data models are a method to get to good quality databases and data.

What Makes for a Good Deliverable?

I worked with a data architect who was very passionate about her data models.  She spend days making them beautiful.  She filled them with all kinds of nifty meta data to help people understand their data better.  She wrote definitions that were paragraphs long, then added more notes to them just to make it even better.  She often missed review meetings because she was too busy making a more beautiful data model.  She missed deadlines for delivering DDL because she wasn’t quite sure on how to do that.  She researched data modeling layout techniques to make models more readable.  She demoed different layouts and took surveys about the alternatives to find just the right one.  And she got further and and further behind on delivering revisions to development, her only direct customer of her work.  The team had gone from every other day deliveries of fixes and enhancements to the development databases to every other week.

Our modeler didn’t have time to learn the features of our target DBMS because was busy making the model a perfect data model. Our sprints were failing because database changes were coming too slowly and were often done incorrectly.  The DBAs and developers had to spend days cleaning up the DDL she had produced because she didn’t know how to use those features of our modeling tool.  So not only did she miss the deadlines, she missed the deliverables.  She didn’t understand this, though. In her mind, the data model was all anyone needed.  In reality, what they really needed was working DDL scripts to apply to their environments.   That was what good meant to the team.

What Format?

I worked with another data architect who would spend months working on the data model, then publish it inside a PDF of a Word document.  The actual data model file was not shared.  No DDL was shared.  Nothing was delivered that teams could actually import into their tools or apply to their local development environment.  This also meant that it was nearly impossible to comment on the data model or easily provide corrections or feedback.  The modeler wanted corrections to come to him in emails and he would make them and generate the Word documents and PDFs months later.  Requests for the data model file itself were met with "You don’t need that, just retype the model in whatever tool you use".  We can’t build stuff on PDFs.  Produce them, sure.  But they aren’t the deliverables we are looking for.  Your team (your customers) can tell you what format works best for them.  Just ask.

Where Do You Deliver the Deliverables?

I work with many data architects who don’t use the same deliverable locations as the rest of the project team and I think that’s a huge failure.  Professional development teams use some sort of versioning or configuration control environment to share their work product.  Data architects should use those, too.  Yes, we have our repositories and model marts, but those are typically only accessible by people who use the modeling tools.  They are my versioning control for the models, but I also deliver to the teams in the same place they expect to find all the components of their systems.  Maybe it’s just a wiki, or an intranet location. Where ever it is, I’m delivering there.

I worked with a data modeler who refused to use or learn the team’s versioning system.  So he just emailed around files, with no version numbers and expected people to be able to search through their emails to find scripts to deploy them in production environments. He seemed to randomly include and exclude people in the distribution list.  He often just attached a bunch of files, then said "here they are" in the body of the message.  Email is the worst versioning system in the world.  Don’t use it for deliveries.

Another approach I find annoying is fairly new, though.  I work with a an architect that keeps all the files he works on for several clients on Dropbox. All in one giant folder.  When he gets his work done,  he sends out an email saying: it’s all on Dropbox.  We as a team have to try  to figure out what the files are, which is the right version and try to ignore all the other stuff that sitting there in the folder.  As afar as I’m concerned, he might as well randomly generate his data models.

Work Backwards

If you have the answers to those questions above, you can work backwards to meet your deadlines.  My inefficient team members mentioned  above don’t do this.  They start with a generic to-do list of how to produce data models, start at step one and work their way as far as they can before they hit the deadline.  They often miss deadlines because they haven’t started at the end and worked backwards.  Don’t be that guy (or gal).  Know what you are expected to deliver, when, where, and in what format.

I start with what my deliverable is, what format I need to produce it in, and what measures I should use to ensure it’s good enough.  Then I start there with the tasks that will get me closest to that completion.  It’s only when those are completed do I keep working backwards to fill in the other high priority tasks.  If I still have time left, I do more.  I make it prettier.  I make it more useful.  I make it beautiful.  I love it.

Not all data architecture is done on development projects.  I understand that.  If your duties include supporting development teams, though, you need to support them.  That means loving your data models, the data AND databases.  There’s no reason why you can’t have it all.  Just remember which parts you’re supposed to deliver first.

Have you worked with data architects or modelers who worked backwards and got the job done?  What about people like I’ve mentioned in this post?  What would you wished they had done instead?

I’m Hiring This Girl One Day…#WIT

Dec 25, 2011   //   by Karen Lopez   //   Blog, Generations, Professional Development, Snark  //  2 Comments

I’m so blown away by how well this girl rants against the onslaught of PINK on girls and females.  For us grown-up girls, the concept of "shrink it and pink" as a marketing approach makes me want to run screaming out of the store.  I had an exhibitor take a nice 16GB USB drive I was picking up out out of my hand and replace it with a blinged out pink 2GB one, saying "Oh, you want this one instead".  No, I didn’t.  And the fact that this vendor thought I did spoke volumes for how they felt about their female customers.

Sure, I cart around Barbies and have my fair share of girlie toys, but my Barbies are working girls – Technical Barbies that have job.  Astronauts, School teachers, FBI agents, Computer Engineers.  Action figures, I call them, because they do something other than look pretty. Most Barbies look like some type of working girl that involves being pretty, but I’ll keep that discussion for later.

Anyway, this video of Riley on Marketing gives me new hope that someday we’ll raise girls to have good analytical thinking.

 

Riley, You Go Girl!

 

In fairness to retailers, they stock and display merchandise in a manner that sells best.  Parents (and Aunties and Uncles), they do this because you like it.  Stop liking it.  Don’t just buy for your little girl from an aisle with big sign that says "Girls" over it.  Think about where you want your darling girl to be at age 18 – still trying to find a Prince to make her a Princess…or readying to enter post-secondary education so that she never has to rely on anyone but herself.  Sure, buy her a Laundry Barbie and a all that princess stuff.  Tell her that she is your princess.  Let her have her truly silly girlie moments. But please don’t let that be her only professional development plan from age 5-25. 

All I know is that when I hire people, I want a hell of lot more Rileys than I do princesses.

Rant: Worst Way to Be Asked to Help? With No Details and No Responses #mememonday

Oct 3, 2011   //   by Karen Lopez   //   Blog  //  4 Comments

Tom LaRock (blog|Twitter) posted his MemeMonday call to share stories via blog posts and he asks:

What is the worst way you have ever had someone ask you for help?

The ones that stick out to me are the times where we would get a cryptic email, the subject line would say “our batch failed” and the text of the email would say “Please fix.”

I have to say that my experiences are right up there with Tom’s.  I happen to do volunteer support of some web applications and databases that are used by IT professionals to collaborate on a long-time multi-vendor, global project.  Even though the users are IT professionals, they often assume that there’s some magic that lets me understand what’s going on, what problem they are having, and just get it fixed.

For instance, I’ll get e-mails that look a lot like:

  • The website isn’t working and I need to get some work done.  Fix it.
    Which website?  What isn’t working?  What are you trying to do?
  • I couldn’t get it work, so I’m emailing it.
    What is "it"?  What is this file you attached?  What are you expecting everyone to do with it?
  • I tried to get it to work for several weeks, then gave up.
    What is "it"? Why did you waste weeks before asking for help?
  • [in status meeting] I don’t know how to use that site, so I didn’t use it and didn’t get my committed to work done for the last month.
    What?  You waited until the monthly status meeting to raise this issue?  What did you try? Whom did you ask for help?  Did you watch the video we prepared on how to use it? Why do you think this is a good way to work?

We IT pros like to gripe about end users and how they don’t even try to use the technology, but I have to say based on my experience too many of us are doing the same things.

So I like to remind everyone, even IT professionals, that requests for help should include:

  1. Real nouns and virtually no pronouns.  "It" is especially troublesome in help requests.
  2. A summary of what you need help with, right at the top.
  3. A description, with details, of what you are trying to do, how you tried to do it, what you are using to do it and error messages/numbers you are seeing. Screenshots get bonus points. Names of servers, URLs, accounts (no passwords, please), databases, tools, browsers, etc. are going to get you help faster.
  4. A recognition that the recipient, unless they work at a help desk/support org, probably needs to make room in her schedule to help.
  5. Information about what your priority/deadlines are.
  6. Screenshots, again, are wonderful.

If you claimed it will be the end of the world unless a solution is provided ASAP, it’s helpful if you respond to questions and requests for information ASAP. It’s also helpful if you copied the world when you send your request that you follow up once a solution has been provided with a copy-the-world response that says that. Thanks get bonus points, too.

< /rant>

Have a day.

Dataversity: Zombies, Zachman, Mason-Dixon Line and Normalization Rants

Jun 16, 2011   //   by Karen Lopez   //   Blog, Data, Data Modeling, Database, Professional Development  //  No Comments

Two of my posts are now up over on Dataversity.net, a portal of all things data for data professionals.

The first, now with images working correctly, is Hiring Data Professionals: Mason Dixon Lines and Zombies in Your Job Postings. In that post I reflect on some of the craziness in job postings I’ve seen over the last few months.

image

In my most recent post, Normalization Myths that Really Make Me Crazy – Introduction to a Rant, I start a series on normalization myths. I expect this series to provide hours of new content for my Contentious Issues presentation.  In the introduction I talk about why a series and the emotions people feel about normalization.  Please stop by and leave your thoughts there.

image

I’ll be writing more than a dozen posts for Dataversity this year and I appreciate your reading my posts there as well as those here at InfoAdvisors.

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to www.datamodel.com by Email


Recent Comments

Categories

Archive

UA-52726617-1