Want to get ahead? Don’t get comfortable

“Moving me down the highway, rolling me down the highway, moving ahead so life won’t pass me by…”
— Jim Croce, “I Got A Name”

“It’s important to be able to make mistakes.  If you don’t make mistakes, it means you’re not trying.”
— Wynton Marsalis

“Don’t look back.  Something might be gaining on you.”
— Satchel Paige

“Insanity is doing the same thing over and over again and expecting different results.”
— unknown

Late last Friday afternoon, our manager stopped by our workspace for a chat.  Some of it was just small talk, but he also wanted to give us a reminder of something, which is what I want to write about here.  I don’t remember his exact words, but the gist of what he said went something like this.

“We want you to develop personally and professionally,” he said (or something to that effect).  “The way you do that is to take on tasks that you know nothing about.  Volunteer to do things you wouldn’t typically volunteer.  If you see a support ticket, don’t worry about looking to see whether or not you know what it is or if you know how to handle it.  Just take the responsibility.  That’s how you develop.  If you want to move ahead, you need to step out of your comfort zone.”

Indeed, these are words to live by, and it isn’t the first time I’ve heard this.  I have had countless experiences where I’ve been told that I need to step out of my comfort zone in order to improve.  In my music experiences, especially in my ensemble performance experience, I’ve often been told by good music directors that I need to attempt playing challenging passages to get better.  When I first started doing CrossFit, one question we were asked was, “would you rather be comfortable or uncomfortable?”  The point was that in order to get better, some discomfort would be involved.  I also remember one of the points of emphasis back when I took a Dale Carnegie course; each week would involve stepping a little more out of our comfort zone.  We would do this gradually each week until we reached a point where we had drastically improved from where we had started.

Falling into a rut is common, and while it happens in all different facets of life, it is especially easy to do in the workplace.  Sometimes, the work environment can slow down, and you have a tendency to fall into a routine.  I’ve had this happen more often than I want to admit, and more often than not, I’m not even aware that I’m doing it.  Every once in a while, a pep talk or some kind of a jolt (such as a kick in the butt — whether it’s from someone else or myself) reminds me that I need to branch out and try new things if I want to get (and stay) ahead.  I am well-aware that I need to step out of my comfort zone to get ahead, but I am also the first to admit that I will sometimes forget about this, myself.

Too often, I see people who fall into ruts themselves, and who have no desire to step out of their comfort zones.  As much as I try to tell these people to at least try to do something about it, they insist on remaining where they are.  These people strive for mediocrity, which is a major pet peeve of mine, and something for which I have no tolerance or respect.  People want to remain in their “happy place,” but what I don’t understand is how these same expect to get ahead, yet refuse to leave their comfort zones to do it.  These people will be stuck in a rut forever, and they have no right to complain about it.

Everyone has a dream, or at least some kind of goal they want to achieve.  The fact is, if you want to reach that goal, or at least take steps toward it (whether you reach it or not), you need to get uncomfortable to do it.

Advertisements

Want to learn about a topic? Try writing about it

Every now and then, I’ll peruse the forums on SSC.  In addition to people answering questions about SQL Server, there also tends to be some banter, which is probably not unusual in many forums of this nature.  One of the comments I’ve seen time and again is something like, “I learn more about subjects by answering people’s comments on these forums.”

There is more truth to this statement than people realize.  In my experience in writing about technology, I often find that I end up learning about the technology about which I’m writing — sometimes to the point of becoming a subject matter expert.

Several years ago, I taught part-time at a local business school (roughly equivalent to community college level).  I taught primarily general mathematics and a few computer classes.  I was once asked to fill in for another instructor who taught statistics.  My problem: I didn’t know much about statistics.  So, I read up on it (along with the syllabus that I would be teaching that day).  I wanted to at least be able to sound like I knew what I was talking about.  As it turned out, by teaching that class, I actually learned something about it.  The students were not the only ones who got an education that day.

The other day, I began writing a draft article regarding a subject about which I’d like to learn more: BI (edit: the now-finished article can be seen here.).  I’ve dabbled in BI a little bit; I worked a previous job where I was asked to perform some data analysis (which is how I learned about cubes and pivot tables), and I took a course in decision-support systems in grad school.  I’m seeing more SQL Saturday presentations about BI; indeed, there are even SQL Saturday conferences dedicated to BI topics (usually indicated by the words “BI Edition”).  It is a topic about which I do have some interest, and it’s something about which I’d like to learn more.

My friend, Paresh Motiwala, who was one of the organizers for SQL Saturday Boston BI Edition a while back, encouraged me to apply to speak at the event.  I said to him at the time, “the only thing I know about BI is how to spell it!”  (His response: “Hey, you know how to spell SQL!”)  On hindsight, I probably should have applied; it turns out that even BI Edition conferences accept professional development topics, under which nearly all of my presentations (so far) are categorized.

So if I claim to know so little about BI, why did I decide to start writing about it?  Well, I’m trying to learn about it, and I’d like to pass along what I learn.  But, I want to place a greater emphasis on the first part of that statement: I’m trying to learn about it.  Writing about it makes me learn something about it a little more in-depth.  And by doing so, I discover that I have a better grasp of the topic.

Hopefully, relatively soon, you’ll see an article from me about BI.  Hopefully, I’ll have learned enough writing about it that you’ll be able to learn something from me.  And hopefully, I’ll have demonstrated that I’m learning something new, and improving myself in the process.

If you want to learn something new, try teaching it or writing about it.  You’ll be surprised how much you, yourself, learn in the process.

SQL Saturday #741, Albany, NY, July 28 — the schedule is out

The schedule for SQL Saturday #741 in Albany is out!  (My presentation is scheduled for the first session of the morning.  Ugh!)

I will be doing a brand-new presentation (so new, in fact, that as of this article, my presentation slides are not yet finished!).

My new presentation is titled: “Networking: it isn’t just for breakfast anymore.”  It is based on my ‘blog article of the same name.  We will discuss networking, what it is, and why it’s important.  We’ll discuss where and how to network, and ways you can break the ice.  We’ll even have an opportunity to network within the confines of our room.  (I suppose an alternate presentation title could be, “Networking for beginners.”)

If you’re looking for networking opportunities or looking for ways to improve upon your networking skills, come check out my session!  Click this link to register for SQL Saturday #741, and join us in Albany, NY on Saturday, July 28!

See you there!

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.

Humble beginnings

Once again, the Facebook “On This Day” memory feature shows it can be a curious thing.  And again, this is one I wanted to share.

The picture you see above showed up on my Facebook memories feed this morning.  Three years ago today, I gave a presentation at my local SQL Server user group meeting.  I had come up with a presentation idea that I thought would be of interest to my user group, as well as other technical professionals.  I jotted down some notes, put it into a presentation, and presented it at my local user group.

About a month later, I gave this very same presentation at our local SQL Saturday.  It was my first SQL Saturday presentation!

I was curious as to how other events would take to my presentation.  Later that year, I submitted it to, and was accepted at, another SQL Saturday.  It was my second time speaking at SQL Saturday, my first time speaking at an event in “foreign territory,” and my first SQL Saturday — speaking or attending — outside of New York State.

Since that humble beginning, I’ve spoken at 13 (soon to be 14) SQL Saturdays at seven different cities around the northeastern United States.  Thanks to this endeavor, I’ve traveled around the region, met a lot of great people, expanded my professional profile, started a ‘blog (that you’re reading right now!), enhanced my career, gained more confidence, improved my presentation skills, and become a better person.  This all came about because of these conferences and from this simple start three years ago.

I hope I’ll be doing many more!  Happy three year anniversary to me!

My hometown SQL Saturday: I’m speaking, July 28

I just got the official word that I will be speaking at my hometown SQL Saturday.

As of right now, I don’t know which presentation(s) I’m doing; I only know that I am speaking!

Come join us at UAlbany on July 28!  Go the link above to register, and mark your calendars!

Birth of a user group

At SQL Saturday in New York City yesterday, I debuted a brand-new presentation: So you want to be a SQL Saturday speaker?  Although only two people showed up, they were very receptive and engaging, which is exactly what I want out of my presentations.  As someone once said, the size of the audience doesn’t matter; just play your best.

What I found fascinating, however, was the interaction between the two gentlemen.  Both were from Long Island.  They traded contact information, and started discussing the idea of creating a SQL user group around there.

It brought to mind a memory from eight years earlier.  It was in 2010.  I was traveling down to New York for my very first SQL Saturday.  I had exchanged messages with someone on a SQLServerCentral.com forum about the conference; he was also coming from the Albany area, and was attending the same conference.  We met on the train, we talked, and we discussed the idea of creating a user group in the Albany area.

The gentleman was Dan Bowlin.  Our forum conversation from eight years ago is still on SSC, and can be found here.  We became friends, and we still remain friends to this day (although Dan no longer lives in the Albany area; he took a job down in Connecticut a couple of years ago).  The group we ended up founding is now CASSUG (Capital Area SQL Server User Group).  We didn’t know what we were getting into with our initial foray into this endavor, but CASSUG now has a few hundred members, holds meetings every month, and hosts its own SQL Saturday (our next one is coming up in July).  From a simple beginning, a user group was born!

I’ve written before about the benefits of user groups.  I’m hoping that this dialog between these two gentlemen leads to the creation of another one.  And I hope to hear about meetings for the Long Island SQL Server User Group (LISSUG) sometime soon!

Maybe they’ll even invite me down as a guest speaker sometime!