A few words can make a difference

A couple of weeks ago, the Rensselaer Polytechnic (the RPI student newspaper) published a couple of op-eds in regard to the situation at RPI.  (My friend, Greg Moore, wrote a piece a while back related to this issue.)  In response to the op-eds, I decided to respond with my own letter to the editor.

This morning, a friend posted to my Facebook that my letter, to my surprise, was garnering some attention.  I won’t say that it’s gone viral, but apparently, it’s caught a number of eyes.

I should note that my donations haven’t been much.  I was only a graduate student at Rensselaer, not an undergrad, so the social impact on my life wasn’t quite the same, and other financial obligations have kept me from donating more of my money.  That said, I’ve donated in other ways; I’ve been a hockey season ticket holder for many years (going back to my days as a student), I’ve attended various events (sports, cultural, etc.) on campus, and I’ve donated some of my time to the Institute.

Although my donations have been relatively meager, more importantly, I wanted to spread the word that I was no longer supporting RPI, and exactly why I was discontinuing my support.  How much I was contributing isn’t the issue; the issue is that I am stopping contributing.  For the first time in years, I have no intention of setting foot in the Field House for a hockey game during a season.  I wanted to make clear exactly why.  A large number of alumni have announced that they were withholding donations.  I wanted to add to that chorus.  It wasn’t so much how much I was donating; rather, I wanted to add my voice, and hopefully encourage other students and alumni to take action against an administration that I deem to be oppressive.

One of RPI’s marketing catchphrases is, “why not change the world?”  It looks like I’m doing exactly that with my letter.  Don’t underestimate the power of words.  Indeed, with just a few words, you can change the world.

Advertisements

Don’t keep an idea to yourself

My friend Greg Moore recently commented on a Facebook post regarding our upcoming SQL Saturday (tomorrow!) in which he credited me for my idea about a forum about women in technology.  The idea had occurred to me when I saw that Rochester SQL Saturday was doing such a forum, and I suggested that we should do one as well.  To be honest, I’d forgotten that I’d made the suggestion until I saw Greg’s comment earlier this week.

It just goes to show that you never know where an idea might lead.  I made a simple suggestion about an idea I’d seen about a forum discussion.  Tomorrow, it’s going to become reality.

For whatever reason, it made me think about the following meme.

Image result for sharknado meme

So the moral of the story: if you have an idea, don’t keep it to yourself.  You never know where it might lead.

Always ask someone to test your product

This morning, one of my colleagues posted this message to our Slack channel:

please ask someone else to test your code before pushing it

It brought to mind an important thought (and more ‘blog article fodder): any time you produce something, regardless of what it is — a software application, documentation, a presentation, a music composition, a dish you cooked, etc. — always ask someone else to test it out before you send it out for public consumption.

That testing could take several different forms — it could be an end user trying your application, somebody reading your document, listening to your presentation or your music, trying your dish, and so on.  Testing results in feedback, which results in improvements to your product.

Whenever we produce something, we have our own vision — and our own biases — as to how the product should come out.  We expect our products to be perfect as resulting from our own visions, and we expect (and demand) that the consumers adhere to our visions and how we expect the products to be viewed or interpreted.

Unfortunately, we are blinded by our biases.  The world does not share our same visions.  People who use our products will never, ever, perfectly interpret how our products should be consumed.  More often than not, we’ll find that what we produce will be used or interpreted in ways that never occurred to us.

Even in my own workplace, I write and edit a lot of online documentation.  Much of what I write comes from other sources, often about topics about which I know little (or, sometimes, nothing).  I try to write material based on the information I have at hand.  Very often, I come across gaps that need to be filled.  I’ll do my best to ask original authors what was intended, or to dig for information to fill those gaps.  But in absence of those resources, I end up making assumptions and using my own intuition to fill in the blanks.  Those assumptions might not necessarily be correct, and what I write could end up being different from what was originally intended.  It is for this reason why I am constantly asking my colleagues, “take a look at what I wrote.  I want to make sure what I wrote is accurate.”

In a manner of speaking, creating products is a form of communication — in that what we produce results from an idea in our heads, and the end users — the consumers — are the ones “listening” to the communication — in this case, the end product.  If you are familiar with the basic communication model, a sender creates a message, a receiver interprets the message, and the receiver reacts to the message in the form of feedback.  Producing a products works in exactly the same way — a producer creates a product, a consumer uses the product, and the consumer reacts to the product, generating feedback.  In between the sender and the receiver is “noise” that degrades the message or the product (it is not literally noise — the “noise” can simply be the fact that the sender’s and receiver’s interpretation of the message are not one and the same).

So, any time you create some kind of product, always ask someone else to try it out.  You’ll find that the person’s feedback will result in tweaks to your product.  And you will end up with a better product.

The importance of accepting critical feedback

A few weeks after giving two presentations at SQL Saturday #526 in Rochester, I received my session evaluations.

I was quite happy with my evaluations for my presentation on how to talk to non-technical people.  I received mostly positive reviews and high scores.

My disaster recovery presentation? Not so much.

My presentation got low scores.  Some of the comments I received included, “needs significantly more actionable & useful take-aways,” “attendees need to leave with action items, ” “very little in the way of reputable facts,” “needs to be updated for 2016,” and “paper is not the solution to documentation anymore” (my presentation was about the importance of documentation in disaster recovery, and this was a point of emphasis — more on that in a bit).

However, despite the negative feedback, it was that on which I focused — not so I could sulk, plot my revenge, or wallow in despair, but rather, so I could improve.  The fact is, the feedback I received was not what I wanted to hear.  It was what I needed to hear.

How else was I going to get better?

It seems like such a simple concept.  You want to get better at something.  You ask people to tell you what’s wrong.  Ideally, when people do tell you what’s wrong, you go back to fix it.

Unfortunately, we don’t live in an ideal world.  Too often, people who are told what’s wrong react adversely, sometimes violently.

Why?

The fact is, people listen to what they want to hear, not what they need to hear.  More often than not, people go looking for feedback, but instead of paying attention to red-flags that need to be addressed, they keep cycling through until they find feedback they like and justifies their position(s).

This is human nature.  It’s also a recipe for disaster.

If you don’t believe me, do a Google search on “groupthink.”  This mindset of ignoring negative feedback defines one of groupthink’s major symptoms.  And if you don’t believe that this type of thinking is destructive, look up the history behind the Bay of Pigs Invasion and the Challenger disaster.  Researchers cite these as prime examples of groupthink, and one of the major contributing factors in each of these disasters is the willful ignorance of certain facts — negative feedback that the people involved desperately needed to hear and address.  It is a phenomenon that impairs quality decision-making and incapacitates our ability to improve.

I am no expert in psychology, and I cannot adequately explain why people are so averse to feedback.  I’d guess that it might have something to do with the fact that people avoid things that are unpleasant.  It’s like experiencing pain.  If you feel pain, you need to find out what’s causing it and address it.  Pain is feedback.  We don’t like it, but we need to address it to improve.

As for my presentation, it includes a section where I list “takeaways from the experience.”  I went into my slides and reworked the section.  Instead of simply listing what I learned, I reworded the points as action items for the audience.  As part of those action items, I wrote them in a way that could be applied to today’s technical environment.  And as for the comment about “paper no longer a solution,” I realized that the person had a point (although I didn’t completely agree with him) and came up with a compromise that should satisfy both opponents and defenders of paper.

Hopefully, my next session evaluation will be better than the last!

(Note: The “next time” is coming up very quickly; I will be giving this presentation this coming Saturday, June 4, at SQL Saturday #517 in Philadelphia.)