Collaboration, cooperation, and competition

This is another article based on stuff that I picked up from SQL Saturday #814.  This time, I’ll talk about Matt Cushing’s presentation about networking.

Whenever I’m speaking at a SQL Saturday, I always make it a point to attend sessions that are similar to mine.  At #814, I met Matt Cushing, who was doing a session on networking.  In fact, our presentations had very similar titles; they both started with “Networking 101.”  That very much caught my attention, and once I finished my own (my presentation was in the time slot immediately before his), I went to his room to catch his presentation.

A big reason why I attend presentations similar to mine is that everyone is different, and will therefore present differently.  Other people will have different perspectives of the same topic.  I want to see these other perspectives.  They might have ideas that will help me enhance my own presentations.  Every time I attend a session in which the topic is relevant to my own, I come across something that either never occurred to me, presents an idea in a different way, or reinforces concepts in my own presentations.  These are important, and they help me make my presentations even better.

Matt gave a great presentation!  I found his own self-assessment on his ‘blog.  I found out that it was Matt’s first-ever SQL Saturday presentation.  I had no idea!  He did a great job with it.  (Matt, if you’re reading this, well done!)  I don’t remember all the points from his session (I’ll need to download his presentation slides), but one takeaway was that “competition is good, cooperation is better.”  (This thought inspired the name of this article you’re reading now.)

This concept of cooperation is applicable to countless situations, and SQL Saturday presentations are no exception.  Many presenters refer to other speakers or other presentations; even in my own presentations, I’ll encourage audience members to go check out other presentations that are similar to my own topic.  (Ed. note: I need to make sure I add a reference to Matt’s presentation in my own slides!)  Matt and I joked that we should encourage SQL Saturday organizers to schedule our sessions back-to-back; we even went as far as to say that we should do a joint presentation.  (Matt, I’m game if you are!)

In a way, Matt is a competitor in that we did similar presentations.  However, we were both able to learn and feed off each other, which enables us both to improve; it’s a win-win for both of us.  Competition is a healthy thing; it drives us to do our best.  But when you cooperate with your competition, there’s no telling what you can accomplish.

Advertisements

SQL Saturday #814 — the debrief

I had a great time speaking at SQL Saturday in Washington, DC this past weekend!  Chris Bell and his team put on a great event, and it’s one to which I will definitely submit again!

I wanted to write this up quickly for a couple of reasons.  One is to acknowledge the SQL Saturday #814 team for the great job they did!  I also wanted to write this to note a few things that I experienced — enough so that I wanted to ‘blog about them; you will see articles about these this week while they’re fresh in my mind, and I wanted to note them while I was thinking about them.  First, Eugene Meidinger asked me what I thought was a very good and legitimate question.  Second, I walked in on the tail end of a presentation by Kevin Feasel that I definitely wish I had seen.  Third, I sat in on another presentation by Matt Cushing that I thought was very good!  Finally, I sat in on a post-event session by George Walters about job opportunities at Microsoft, which I also found interesting!

I will be addressing these thoughts in upcoming ‘blog articles, so stay tuned!

If at first you don’t succeed…

“Gotta run a little faster, gotta reach for the sky, gotta come a little closer, even if I lose, I gotta try…”

— Kansas, “Inside Of Me”

I will confess that the song lyric above is one of my favorites, and probably one of my most overused quoted lyrics.  It isn’t the first time I’ve quoted it to start a ‘blog article, and it likely won’t be the last.  I’ll admit a level of bias because it comes from my favorite band, but the lyric also talks to me in a way that few do.  I came across a couple of things today that reminded me (again) of this lyric.

First, I received an email that I had been turned down for a speaker’s program, sponsored by my fraternity, to which I had applied.  Not a piece of news that I wanted to hear, but I took it in stride.  I saw something that interested me, I thought I’d be a good fit, and I gave it a shot.

(I should note that, as part of the application process, I recorded a presentation video of myself doing a “lightning talk” that I entitled “Why you need to be on LinkedIn.”  I wanted to wait until I’d heard about my application decision before making this video more publically available.  I’m posting the link here for all of you to enjoy — or trash, whatever the case may be!  I realize that the audio quality is not that great; I apologize in advance for that.)

(I should also note that I replied to the email, thanking them for considering me, and to ask for feedback as to what I could’ve done better.  As I’ve written before, feedback is always important if you want to get better.)

Second, I came across this article that talks about tomorrow night’s basketball game: Syracuse vs. Cornell, or as I refer to it, the “Boeheim Family Reunion.”  (For the benefit of those of you who are clueless about college basketball, Jim Boeheim is the Syracuse men’s basketball head coach, his younger son, Jack “Buddy” Boeheim, is a freshman on the Syracuse team, and his older son, Jimmy, is a sophomore playing for Cornell.)

What I wanted to note about the article was a quote from the family patriarch.  Some background info: the Boeheim men are notoriously competitive, a central point of the article.  The article mentions: “Jimmy talks about the endless games of Candyland they played against their dad, the loser always demanding a rematch. Jim Boeheim never let the boys win. Victories needed to be earned or what was the point of competing?”

It got me thinking that these were a metaphor for one’s career and life in general.  Your career and your quality of life are often competitive, sometimes even cutthroat.  You have a choice: either forget about the entire thing, or give it another shot.  In regards to the former, I ask a question: how important is it to you?  If it isn’t important, not worth your while, or it isn’t a big deal, then give it up and move on to whatever is next.  But if it is important, then it’s up to you to get off the mat and keep fighting.

It’s one of the ideals that keeps CrossFitters going.  It’s about getting better.  Granted, I’ll likely never get to the level where I’ll be competing against Mat Fraser, but as long as it’s possible for me to improve (which is the case in just about anything and everything I do), I’m going to keep going.

In regard to the speaker’s program, being accepted would’ve been a nice boost to my speaking endeavor and potentially my career.  But if I wasn’t accepted?  No biggie.  Hey, I came, I saw, and I gave it a shot.  C’est la vie.  All I can do is learn from it and take another crack at it when (or if) another such opportunity comes around again.  I can sleep at night knowing that, at the very least, I tried.

I’ll stop short of quoting the infinite number of clichés, memes, or articles (to which I’m adding yet another by writing this) about picking yourself up and trying again.  All I’ll say is that they’re true.  Just keep going.  If at first you don’t succeed…

How do different cultures use your documentation?

The other day, I sat in a meeting in which we were talking about our product documentation, and someone mentioned something that had never occurred to me.

It had to do with who used our product documentation.

I found out that native English speakers (for the sake of this article, I’ll refer to them as “arch-typical American end-users” — whatever that means) mostly ignored the documentation (that I had written), inferred what they needed primarily from the application interface, and used the documentation primarily as a reference source.  This was something I’d anticipated, so naturally, I developed the document with that mindset.

However, I learned that users whose first language was not English utilized the document much, much differently.  (Disclosure: I currently work in an office where the majority of my coworkers are Asian-Indian.)  Many of them first read the documentation thoroughly before using the application.

I don’t know how much these people used the document as a reference guide as compared to how much they used the UI — we didn’t go into that discussion — but it completely changed my mindset as to how to approach documentation development.  I haven’t (yet) done any research, but I am now curious as to how people from different cultures and backgrounds approach documentation.  I have no doubt that this topic has been researched; if anyone knows of any authors or references, feel free to say so in the comments section.

For those of you who don’t know me, I should mention that I am Asian-American (specifically, Korean-American), but I am a native English speaker.  I don’t speak any other language fluently.  I do not speak Korean (what little I know came from what little my grandmother tried to teach me and from M*A*S*H reruns), and my personal foreign language experience comes from my German classes in high school and college.  That puts me in a unique situation; when it comes to my writing, my initial audience is American-English speakers, but my ancestral background makes me appreciate audiences from other cultures as well.

Cultural differences in communication are always an interesting topic.  I remember reading an article about how Chevrolet had issues with selling a particular model of their car in Spanish-speaking countries, because “Nova” translates to “not going.”  I also recall a conversation with someone who mentioned that a simple American gestures as a thumbs-up is the equivalent of “flipping someone the bird” in some other countries.  So it goes to show that what you’re trying to communicate could actually be miscommunicated, depending on your audience’s culture.

I’ve espoused time and again that a writer needs to know his or her audience when developing a document, and I continue to do so.  This realization made me realize that my audience is more diverse than I thought it was, and that I will need to plan for that whenever I am developing documentation.  And it’s not just a matter of what I’m writing in my words — it’s also a matter of how my document will be used.

So I guess the moral of the story is to be wary of what you’re writing.  You never know who will be reading — or how they will be using it.

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.

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.