Soft Skills: Controlling your career

I came across this article on SSC by David Poole titled “Soft Skills: Controlling your career.” It spoke to me in a big way, as it pretty much sums up my career in a nutshell. It’s a good read, and I encourage you to go click the link.

I’ve said before that I’ve made an entire career out of adapting to my environment. Soft skills are the key to being able to adapt.

All of my SQL Saturday presentations revolve around soft skills. I’ve been asked before about why I speak at SQL Saturday, when my talks don’t talk about data topics. The fact is, soft skills are important. You can know everything there is to know about data storage systems, recursive structures, or nuclear physics, but often, soft skills are ultimately what sets you apart.

Advertisements

Lots of user groups to choose from

Yesterday, I received a Meetup email (I get them regularly) regarding an AWS group (that I didn’t even know existed). I, personally, don’t deal directly with AWS, but my organization does use it extensively. There is an AWS user group meeting coming up this week. I sent the announcement to my coworkers; I figured that a number of them might be interested in it.

It made me think about the plethora of user groups that are out there. I write primarily about the SQL user group with which I’m involved, but I’m also involved with a UX user group and a .NET user group. I’m also involved with a number of extracurricular activities (that, for the purposes of this discussion, I count as user groups); I play with a large symphonic concert band, I have my CrossFit gym, and this Fall, I will be music-directing a show production that’s scheduled to be on stage in December!

I will confess that I have yet to attend a .NET user group event, and there are a number of other groups that interest me. What keeps me from attending them is lack of time. It seems like there is an endless number of user groups out there, but there’s only one of me, and there’s only 24 hours in a day and seven days in a week.

I’ve written about the benefits of user groups before. It’s a great source of learning, it often doesn’t cost anything to be involved, you support a cause that is special and specific to you, and it’s an opportunity to network and make new friends. (I should also mention that it’s a great excuse to get out of the house!)

And you never know where involvement with a user group might lead!

So if you’re looking to meet people and learn new things, go out and find yourself a user group. I have no doubt that there’s one one there that suits you!

Stop treating technical writing like a second-class citizen

File this under another technical writing frustration.

Imagine that you are an application developer. You finish an app for a client that you send for review. The app is clearly labeled as a “testing version,” and includes source code (yes, I know this last part doesn’t happen, but just humor me for a bit). You are meticulous with your updates, keeping track of version control and changes. You ask the client to review it and get back to you. You move on to work on other projects, forgetting about the request. A few weeks later, you remember the project, and realize that you hadn’t heard from the client. You contact them to follow up, and are chagrined to learn that not only are they using your test version app in production, they also changed the source code for what they need.

Sounds outrageous, right?

Now, substitute the following words and phrases: “technical writer” for “application developer,” “document” for “app,” “draft” for “testing version,” and “MS Word” for “source code.” Welcome to my world.

This is an actual workplace scenario that happened to me a while back, and I was reminded of this recently when the same client asked me for an MS Word version of a document (that I had sent as a PDF — I was never, ever going to send them an MS Word doc again) so they could make changes. I refused, and I told them why.

The client in question had taken my Word document — the one that I had asked them to review — and I will add that I had DRAFT stamps all over it — and were using it in their production environment. Not only that, they had made changes to it for their purposes.

Well, I found and incorporated their changes, removed the DRAFT stamps (they were obviously okay with the document), and slapped a version number on it.

I also told myself that I was never sending them a Word document ever again. They were only getting PDFs from me.

I’ll be honest. What the client did absolutely pissed me off. By “changing the document for their needs,” they completely compromised and undermined my work, they blatantly stepped on my toes, and they completely disrespected what I do.

Most of the clients I work with aren’t like this, which is why I usually don’t have a problem sending a Word document (with DRAFT stamps) out for review. Thankfully, the scenario I just described is, in my environment, the exception, not the rule. Sadly, however, there are still too many people who hold this attitude that documentation is just a side item, and treat it like a second-class citizen.

This is one of the things that drives me to do SQL Saturday talks. This is why I do my presentations. This is why I rant about poor treatment of documentation. And this is why I actively tried to leave a job.

I’ve said this time and again. Document development needs to be treated in the same way as software development. The life cycle, including version control, is no different. Not doing so undermines what documentation is. It’s a critical function in application and professional development. And as someone who has had experience in both application and documentation development, I demand: stop treating documentation like a second-class citizen.

PASS Summit — Nothing to see here

I haven’t written anything in a while about my PASS Summit prep. To be quite honest, I have nothing to report. I’ve been busy with several other things (among other things, I’ll make a trip to New York City before I head to Seattle), and I have plenty of things to keep me distracted (some of it in a good way).

For those of you new to my ‘blog (the rest of you can skip this paragraph), here’s a quick summary to get you caught up: this past July, I learned that I was chosen to speak at PASS Summit! If you’re a data professional, PASS Summit is a huge deal. If you’re familiar with SQL Saturday, I’ve heard it described as “the Super Bowl of SQL Saturdays” and “SQL Saturday on steroids.” Being selected to speak at PASS Summit is an enormous honor for me, as well as being a great boost for my career! (I should also mention that not only is this my first time being selected to speak at PASS Summit, this is also my first time attending, as well!)

I did get feedback about my presentation slides. I’m not sure whether or not I’m allowed to talk about that (it’s nothing bad), so for now, I’ll leave it at that. I also asked about luggage storage arrangements for the last day, after American Airlines pulled a fast one on me and changed my flight schedule. (Tip: I can store my luggage at PASS Summit. And from now on, I am avoiding American Airlines if at all possible.)

I’ve been poking around the Summit website for the latest updates. The only new thing that really caught my eye was a link to buy PASS merchandise. I can always use more polo shirts, so I will likely splurge on a shirt. (Heads up to my wife, a.k.a. she who controls my checkbook!)

I did speak to my mother this week, who asked me if I was planning on visiting my cousin (who lives in Seattle) during my trip. I said that, most likely, I wouldn’t have time. To be honest, it appears that there are a lot of activities going on around PASS Summit, and multiple friends who’ve attended in the past have told me to prepare to drink from a fire hose. So as much as I want to see people — I have several friends and family members who live in or near Seattle — I’m not sure if it’ll be in the cards for this trip. (And to those friends and family, if you’re reading this: if you do want to hook up, drop me a line; maybe we can work something out!)

So that’s about it for now. As I said, nothing really significant to report. Less than two months until I fly out to the West Coast! Looking forward to it!

First drafts are ugly

“The secret to life is editing. Write that down. Okay, now cross it out.”

William Safire, 1990 Syracuse University commencement speech

“No thinking – that comes later. You must write your first draft with your heart. You rewrite with your head. The first key to writing is… to write, not to think!”

William Forrester (Sean Connery), Finding Forrester

“Just do it.”

Nike

I will confess that this article is a reminder to myself as much as anything else.

Raise your hand if you’re a writer, and whatever it is you’re writing has to be perfect the first time around. Yeah, me too.

How many times have you tried writing something, but in doing so, you hit a wall (a.k.a. writer’s block) because you don’t quite know how to put something in writing? Or how often have you written a first draft, only to take a second look at it a second time and say, “what a piece of s**t!”

(And speaking as someone with application development experience, this happens with writing code, too. Don’t think that this is limited to just documentation. This is yet another example of how technical writing and application development are related.)

Someone (I don’t know whom) once said, “one of the stupidest phrases ever coined is, ‘get it right the first time.’ It’s almost never done right the first time!” In all likelihood, you need to go through several iterations — review, editing, rewriting, etc. — before a draft is ready for public consumption. It’s called a “draft” for a reason.

The fact is, nobody has to see what you write the first time around. If you’re trying to get started on a document, just write what’s on your mind, and worry about making it look nice later.

Don’t tell me how to build the clock! Just tell me what time it is!

This article’s title comes from something that a former manager used to tell me all the time — often enough that he seemed very fond of saying it. Nevertheless, it’s an important message. This is not the first time I’ve written about this issue, but it’s something that occurs all too frequently. It is a problem in technical and business communication, and the issue is something that bears repeating.

I was reminded of this during our daily status update meeting this morning. The gist of this regularly scheduled meeting is that everyone has a short time — usually no more than a minute, if that — to provide a brief update of what they have going on. The key word here is brief.

One person proceeded to go into detail about some of the projects he had going (he has a tendency to do so). He’s been pretty good about keeping his updates short and to the point, but he wasn’t always like that. It took several long meetings and complaints to the manager to get him to tone it down.

For whatever reason, this morning, he reverted back to form. He started getting into details about his projects that, while important for the projects themselves, were unnecessary for status updates. It got to the point that I stopped listening to what he was saying and pretty much just zoned him out. I don’t know how long he took, but I’ll guess that he took three times longer than anyone else. Or at least it seemed that way.

This is something that everyone does (yes, I admit to doing it, too — ironically, even this very article may be too long). And it is a big problem in communication.

A part of the issue stems from human nature. We all have a limited attention span. The length of that attention span varies, but for the purposes of this discussion, let’s assume that it’s short — say, no more than a minute (sometimes, that might even be too long). If we’re communicating something, we need to make sure that it’s short and simple — and it had damn well better be efficient.

This is why people in roles such as technical, business, UX/UI, media, and marketing communication have jobs. They are in the business of taking large amounts of information and boiling it down into a format that most people can understand.

Whenever I’m writing a user or step-by-step guide, I follow a general rule of thumb: if an instruction cannot be understood within a few seconds, it has failed. That’s when I go back and rewrite the instruction.

Most of the time, people don’t want — or don’t need — or don’t care about — details. Unfortunately, too many people trying to communicate ideas don’t understand this (and worse, they often don’t care). As a result, horrible documentation (or, in some cases, absence of) is pervasive.

Too many people don’t understand that reading is work. It takes effort to read and comprehend documentation. One of my big pet peeves is any time someone tells me, “it’s right there in the documentation,” yet when I look at it, the information I need is buried someplace where I have to fight through the noise of other irrelevant text to find it.

This issue is the basic tenet of my presentation about talking the language of technology. People don’t want detail. They just want the information they need. If they need more information, they’ll look for it.

Good communication makes it easy for a recipient to quickly get whatever information (s)he needs. Don’t make someone have to work to understand communication. Don’t tell someone how to build a clock. Just say what time it is.