References and memorization

I was working on a document, and wanted to toggle the language on MS Word that was used for proofing (I downloaded the template from our UK subsidiary, so it was proofing in UK, not US, English). I couldn’t remember how to do it, so I consulted Google, found my answer, changed the setting, and went along my merry way.

For whatever reason, it got me thinking about Microsoft certification exams (it’s funny how one’s mind works sometimes). It’s been a long time since I took one. What got me thinking was that, when you take a certification exam, you are not allowed to bring any notes or references with you into the testing room (as far as I remember — I’m not sure if that’s still the case now; like I said, it’s been a long time since I took a certification exam).

In this day and age where finding information is as easy as picking up your smartphone, I really believe that memorization is overrated (and, maybe in some cases, even dangerous). I wrote as much a while back, and I still believe that now.

Back when I worked as an adjunct instructor, all my assignments, quizzes, and exams that I gave to students were open-book, open-note. I also told my students that they were allowed to help each other work toward the answers, including during an exam. They were not allowed to outright give each other answers; that constituted cheating and were grounds for failing the exam. Maybe some instructors might scoff at this approach, but my students were very good about adhering to those rules (many of them told me later that they learned more in my class than any other they’d ever taken), and there was a method to my madness.

For one thing, I told my students that the ability to look up and research information was an important skill to have. We, as imperfect human beings, are never going to remember absolutely everything, so to be able to know how find the correct answers is important. Second, when we’re in a working environment, the ability to work together as a team is critical. When you’re working within a team environment, being able to work with others to achieve a common goal is a big deal.

Finally, how many workplaces are going to tell you, “okay, put away all your books and references. You’re going to do this project entirely from memory.” I don’t know about you, but if a manager ever told me to do that, I wouldn’t be able to update and distribute my resume fast enough.

In his SQL Saturday presentation entitled “Why candidates fail the job interview in the first minute,” Thomas Grohser mentions that he does not expect any candidate to be able to know everything. If a candidate says that (s)he “does not know the answer, but here’s how I would go about finding the answer,” then that is a perfectly acceptable answer. More often than not, trying to do everything from memory is a bad and sometimes dangerous approach, and is a bad way of thinking.

We are not perfect. We will never remember everything. And anyone who says that (s)he knows everything is full of crap. Rather than try to brute-force memorize anything and everything, it’s more important to develop skills that teach you how to think and how to find, verify, and process information. If I was a hiring manager, that ability would be vastly more valuable than someone who says that (s)he “knows everything.”

Advertisements

Paying it forward

Once upon a time, I wanted to be the rockstar in pretty much anything and everything I did, whether it was my job, my extracurricular activities, or my relationships.  I wanted the glory and the recognition.  More importantly, I wanted to be respected for whatever I did.  In my youth, I thought that demonstrating that I was good at whatever I did was the path to glory.

But now that I’m older, that perspective has changed.  I no longer need (or, sometimes, even want) to be the rockstar.  These days, I get a great deal of satisfaction out of helping someone else become the rockstar. While I still try to perform well in whatever I do, it’s more important to me to help everyone around me be better.

This has become a passion of mine. It’s why I’m so passionate about speaking at SQL Saturday. It’s why I take such an interest in technical communication, writing, training, and mentoring. It’s why I continually encourage people to be better. It’s even one of the major reasons why I maintain my ‘blog. While it’s important to make myself better in whatever I do, I think it’s also equally important to make people around you better as well.

I’ve had a number of opportunities to give something back. For the past couple of years, I’ve taken part in a program by my alma mater, Syracuse University, specifically the College of Engineering and Computer Science (ECS).  They sponsor a “job shadow” program in which current students are paired with alumni working in various industries. The program typically takes place during winter break, between the fall and spring semesters.

Unfortunately, I work in a data-secure office, so an office shadow tends to be out of the question. (I don’t think students would really be interested in seeing me sit at a desk all day, anyway.)  In lieu of a job shadow, the university suggests other ways to interact with students — over a cup of coffee, lunch, and so on. For the past couple of years, I’ve offered to take students out to dinner. It offers a nice, relaxed atmosphere to chat, not to mention that, since I usually don’t have any commitments after dinner, I’m not constrained by time; I don’t have to worry about being back in the office by a certain time.

I’ve found numerous other ways to pay it forward. During one unemployment stint, I found a part-time position as an instructor at a local business school to hold myself over. I discovered that I enjoyed teaching so much that, even after I found gainful full-time employment, I continued with the teaching job for a few more years. I am heavily involved with my local SQL user group. By giving back to my user group, I can help other people with the same interests. I also wrote a while back about some of my networking activities in which I was able to give back. When you network, you have multiple avenues in which you can pay it forward.

As an old saying goes, a rising tide lifts all boats. Improvement doesn’t just mean making yourself better. It also means making everyone around you better as well. When you help other people succeed, then we all succeed.

When you make it hard for your customers to respond

This morning, I had an issue with my LinkedIn account. I was trying to reply to a message, and I kept getting “Send failed.” That was all I got — there were no error codes, additional information, or symptoms. I poked around LinkedIn’s Help section, and came across this page for dealing with messaging problems. I didn’t go as far as to clear my cache, but I did log out and back in, and I tried it in a different browser, all to no avail. In the middle of contacting LinkedIn’s support, the problem mysteriously “fixed itself.” If you work in tech, I don’t have to tell you how frustrating it is for an issue to mysteriously “fix itself.”

However, the issue I had, in and of itself, is not why I’m writing this article. When I heard back from LinkedIn, I got a message saying “go to this page” (the one I’d already found) and use that to troubleshoot. In response, it displayed the interface you see above. As you can see, they only gave me two options: “yes, I’m good,” and “no, I still need help.” The problem was, my response was, neither. No, I didn’t need help at that point, but I also wasn’t completely good, either. I wanted to inform them what had happened in case they wanted to investigate it further. But they did not give me that option. Between those two options, I clicked “yes, I’m good,” which immediately closed the case; I had absolutely no recourse to add more to it. I looked around for ways to send feedback, but I did not find any good way to do it. Replying to the email resulted in a response saying “you responded to an unmonitored mailbox.” The more I looked for a feedback mechanism, the more frustrated I got. The issue quickly went from “I’m reporting a technical issue” to “you guys need to fix your UI/UX.”

I’ve written before about how critical it is to get feedback, and how design can be a big deal. As much as I like LinkedIn as a business networking tool, I felt that LinkedIn fell short on both of these facets.

Let me start with the UX/UI design. I strongly felt that only those two options, especially if answering “yes” automatically closed the case, was a very poor design. As many people will tell you, the answer often isn’t simply “yes” or “no.” (One of the long-standing jokes among DBAs is that the standard DBA answer is, “it depends.”) And even after I clicked one of those buttons (in this case, I clicked “yes”), the interface was confusing. I was brought to a page that said “click to enter more information” (or something like that). The problem was, click where? None of the “links” allowed me to enter anything else, and there was no clearly logical eye path for me to follow. I had no idea what I was supposed to do once I got to that page. I kept clicking different links, trying to leave feedback. By the time I found a link, I wasn’t even sure that I was replying to my original query. I had no idea to what — or even where — I was responding.

I’ve said time and again that if you’re a technical writer — or a UX/UI developer — you don’t want to make your reader or end user work. Reading is work. Making your end user work is a sign of poor design.

Second, this experience made me question just how seriously LinkedIn takes feedback. True, nobody wants to hear bad feedback. I know I sure don’t. But if you want to improve, you need to know what it is you need to improve. How am I supposed to improve something when I don’t know what it is that I’m doing wrong? Not including a channel for feedback — or making it difficult to do so, as I allude to above — is doing a disservice to your organization and to your clients.

Good communication between you and your client is important. Not only does it help your client, it helps you improve your organization, and it builds trust between you and your customers. Making it difficult for your customers to communicate alienates them — and ends up hurting your business in the long run.

Who has the final say on a service issue?

I recently registered for Homecoming Weekend at the old alma mater. For me, it’s a reunion year ending in zero, so this year is of particular interest to me. (No, I won’t say which one it is. All I’ll say is, I’m getting old!)

While going through my own information on the Homecoming web site, I noticed a minor error. It wasn’t particularly big, and the error isn’t important in and of itself, but the university wouldn’t let me change it online; I needed to email them to get it fixed.

In response, I received a Jira service request notification indicating that it was in the queue. I knew right away that they were using Jira; we also use it in our office, and the email format and appearance is unmistakable.

The next email I got from them, a couple of hours later, is the graphic you see above, and as someone who’s worked in technology his entire professional career, I found it to be particularly irksome. When I received the message, my immediate thought was, “excuse me, but I am the customer. Who are you to say that my issue is resolved and completed?!?”

Sure enough, when I checked my information again, it still hadn’t been updated. I even tried clearing my cache and refreshing the browser. No dice. I wrote back, saying that I didn’t see the change and asking how long I should wait before I saw it. For all I knew, the web server had to refresh before any data changes appeared, so I gave it the benefit of the doubt. I received an automated message saying the case had been reopened (I was responding to Jira, after all). I didn’t get another response until this morning, when once again, it was marked “Resolved” and “Complete.” When I checked my information again, the change was there. I did not receive any other communications or acknowledgements, other than the automated Jira responses.

In their defense, to me, a department called “Constituent Records” sounds more like a data end-user role, rather than a full-blown IT or DBA role (I could be mistaken), so maybe they weren’t versed in concepts such as tech support, support levels, incident management, or support procedures. Nevertheless, I still found this to be annoying on a couple of levels.

First, it is up to the customer, not the handler, to determine whether or not an issue is resolved. The word “customer” can have a number of connotations*; in an internal organization, the “customer” could be a departmental manager or even your co-worker sitting next to you. To me, the “customer” is the person who initiated the request in the first place. An issue is not resolved until the customer is satisfied with it. It is not up to the handler to determine whether or not an issue is resolved. The handler does not have that right.

(*Side thought: the customer and handler can be one and the same. If I come across an issue that I’m working to resolve, I am both the customer and the handler. Nevertheless, the issue isn’t resolved until I, the customer, is satisfied that I, the handler, took care of it to my — the customer’s — satisfaction.)

Second, as a technical communicator, I was annoyed by the complete lack of communication from the person handling the request. The only communications I received were either comments contained within the Jira ticket or automated responses from Jira itself. Not once did I receive any message asking for any feedback or asking to see if I could see the change. The only messages I received — before I responded saying I didn’t see the change — was an automated Jira response acknowledging that they had received my request, and a second message that it had been resolved and closed. Boom. End of story.

I’m writing this article as a lesson for anyone working in a support role. First, feedback is important. You need to know that you’re handling the issue correctly. “How am I doing?” is a legitimate question to ask. Second, it is not up to you, the handler, to determine whether or not the issue is resolved. That right belongs only to the client — the customer who initiated the request, and whose issue you’re handling.

Memorial Day Murph — crossing the finish line

Yesterday, I did the annual Memorial Day Murph workout. I’ve written about it before. For those of you unfamiliar with CrossFit, the Murph workout consists of a one mile run, 100 pull-ups, 200 push-ups, 300 air squats, and another mile run. Needless to say, it is a LOT of work!

For those of us who aren’t professional athletes, many of us scale it down. Some people reduce the length of the runs. Many others reduce the number of reps. I set a goal of running (well, okay, “running”) the entire one mile lengths for each run. I broke down the reps into ten rounds of 5 ring-rows (since I can’t do pull-ups), 10 push-ups, and 15 air squats. I had every intention of doing the full twenty rounds, but when I reached round 6 and realized how much time had elapsed, I came to the realization that “twenty rounds isn’t happening!”

As you can see in the photo above, I had a nice cheering crew waiting for me as I crossed the finish line! I finished the workout in 1:04:31.

I started doing CrossFit to get into shape. I still continue doing CrossFit because of the great friends I’ve made and all their support. Find something that works for you, and you’ll keep wanting to go back for more!

No events near you? Try a virtual group — or start your own!

As I’m writing this, I’m sitting in on a webinar by Matt Cushing called Networking 102: Getting Ready for a SQL Event. (It was originally named “Networking 101,” but I guess he didn’t want it to conflict with mine! 🙂 ) This is actually the same session that I attended at Washington, DC SQL Saturday, and Matt does a great job! He even acknowledged me during his presentation today — thanks for the shout-out, Matt! If you ever have a chance to attend his session at a SQL Saturday, I highly recommend it!

Matt also mentioned, at the end of his virtual presentation, that it was a different experience. I concur — when I did my own a couple of weeks ago, I had to make some adjustments. I won’t get into that now — that’s another article for another time.

Watching his online presentation — and thinking back to my own from a couple of weeks ago — reminded me about the difficulty of attending events. I always encourage people to attend events such as SQL Saturday and a local user group. However, not everyone is able to do so. Maybe there isn’t a user group or event near you, or maybe an event you want to attend conflicts with something else on your calendar. Having grown up in the rural Catskills, I can understand how difficult it can be to attend some events, and I’ve had to pass on attending several events because of schedule conflicts.

Fortunately, for people in those situations, there are options.

First, since I started writing this article about a webinar, look into joining a virtual user group. PASS has a number of virtual groups available to join. I am a member of the Professional Development Virtual Group; as someone who does professional development presentations, I look into attending online presentations by this group; I’ve even done one myself, and I hope that I’m able to do more. Other virtual groups are available; do a Google search and see what groups might interest you.

Of course, there are some disadvantages to virtual groups. Because you’re generally only interacting with the presenter, networking and face-to-face interaction is impossible, so it’s difficult to connect with other people.

If you are in an area that doesn’t have a local user group that interests you, why not start one? The Albany SQL group started out with me meeting Dan Bowlin aboard a train while heading to a SQL Saturday in 2010. Since then, our group has grown in number (I’m not sure exactly how many, but last I checked, we’ve been sending emails to around 300-something people) with meetings each month, we have members who are actively involved with PASS and SQL Saturday, and we even host our own SQL Saturday each year. If you find that people in your geographic area share a common interest, consider starting a user group.

If your involvement with user or special interest groups is limited, either by time or geography, consider either joining a virtual group or starting your own user group. Those constraints shouldn’t leave you out of the loop.

Make goals, not resolutions

My previous post got me thinking about setting goals. I mentioned in my previous article that I hate setting New Year’s “resolutions.” I didn’t want to get into why in that article.

Well, in this article, I want to get into exactly why.

How many of you have made New Year’s resolutions? How many of you made them in years past? How many resolutions did you keep?

If I had to guess, probably not many, if any.

This is why I hate resolutions. They’re almost guaranteed to fail. Case in point: for those of you who go to a gym and work out, how packed is the gym in January? In all likelihood, it’s packed with people who resolved to go to the gym and work out this year.

Now, how many of these people are still at the gym by the end of the year? Or by July? Or even April?

I gave up making resolutions a long time ago. All I was doing was breaking promises to myself. And every time I did so, I just ended up disappointing myself.

Don’t set resolutions. Instead, set goals. If you want to do something to better yourself, setting goals is far superior to making resolutions.

Goals are measurable. Let’s say you make a resolution to lose weight and go to the gym. That’s awfully vague, isn’t it? That can mean almost anything. Let’s say you join a gym on January 1, do one workout, and never go again. You might say you broke your resolution. But did you really? You went once. That counts, doesn’t it?

However, let’s say you set a goal to lose ten pounds by the end of the year. Now you have something to shoot for, and it’s something that can be measured. You can keep track of how much weight you lose until you reach your goal, and you can measure aspects (calories, number of workouts, etc.) that will help you get there.

A goal is a target. In addition to being measurable, a goal gives you something toward which you can aim. You might hit it. You might not. Either way, you gave it a shot. Resolutions, on the other hand, are almost always doomed to fail.

If you miss your goal, that’s okay. When you break a resolution, you feel like you failed. It brings you down. It un-motivates you. However, if you miss a goal, it’s not the end of the world. You can either try again, or reset your goal toward something more manageable.

Speaking of being more manageable…

Goals are adjustable. If you find that a goal is unattainable, you can adjust it so it’s more attainable. And once you reach a goal, you can reset a higher goal, which will make you even better.

Goals can be set any time. Ever make a resolution in July? I didn’t think so. However, you don’t have to wait until the new year to set a goal. You can set them any time you want.

(There are probably a bunch of other reasons that aren’t coming to me right now.)

Personally, I’ve set a few small goals. For one thing, I don’t have much arm strength, so I struggle with any workout routine that involves supporting my own weight with my arms — pull-ups, rope climbs, handstands, etc. I set a goal of doing at least one real pull-up by the end of the year. Also, my home is, admittedly, a cluttered mess (it looks like it belongs on an episode of Hoarders). I told my wife that I would set a goal of decluttering a room at a time — the kitchen within a few weeks, the living room a few weeks after that, and so on.

There are a number of others I’d like to set as well, but I haven’t yet gotten around to setting them. As I go along, I’ll figure out what I need to accomplish, set my goals, and take steps to reach them. Again, I can set goals any time I want. I don’t have to wait until next year.

So what do you want to accomplish? What steps will you take to reach them? Whatever they are, you will be more likely to succeed by setting goals rather than making resolutions and empty promises to yourself.