Dont rite so gud? Don’t let that stop you

Eye no that a Lot of ppl dont Right to gud. That shudnt keep ppl frum Riteing. Lot’s of ppl dont Right gud.

Did you have trouble reading that paragraph above? I actually had trouble writing it. The late Harry Chapin had a song called Six String Orchestra in which he intentionally plays badly. I once said that if you’re an accomplished musician, one of the most difficult things to do is to intentionally play something badly. If you’re a writer, I suppose the same is true for intentionally writing something badly. I remember reading a novel, Flowers for Algernon, in which a mentally-retarded man, writing in the first person, increases his intelligence after an operation. It was interesting reading the account as his intelligence and his awareness increased, and I can only imagine as to how challenging it might have been to write.

Anyway, in my technical writing presentation, one of the points I try to make is that not being able to write well should not discourage people from contributing to documentation.

I’m the first to admit that I’m a grammar snob. I’ll often be that person who is “silently correcting your grammar.” I cringe anytime someone doesn’t know the difference between “your” and “you’re.” I have to hide my eyes anytime someone uses an apostrophe-S as a plural. And I still believe that anyone who says “irregardless” should be flogged.

That said, I understand that not everyone is a good writer. Just because someone does not write well doesn’t mean that person should be discouraged from writing.

For one thing, as I said before, everyone has to start somewhere. Someone once said that “one of the dumbest quotes ever coined is ‘do it right the first time.’ It’s almost NEVER done right the first time.” And the one sure-fire method to improve is to practice. The more you write, the better you’ll get.

If I had to offer a piece of advice to someone who wanted to get better at writing, I’d suggest reading material by your favorite author, then try emulating that author’s style. For example, a few of my favorite authors include Stephen King, Tom Clancy, and Terry Brooks. I enjoy their books and their writing style. After reading their works, I found myself wanting to emulate how they write. I discovered that, over time, my writing kept getting better.

For another thing, an inability to write well doesn’t mean a person lacks intelligence or knowledge in a subject. That person often contributes to documentation as a subject-matter expert (SME). An SME has a great deal to contribute, but knowledge transfer can be challenging. To be fair, this is not an easy thing to do; one of the most difficult tasks is to communicate knowledge to other people. (I even have an entire presentation about this.) People often have valuable information to contribute; the challenge lies in how to convey that information. If someone with information doesn’t write well, that shouldn’t stop him or her from doing so.

Granted, if a piece of writing needs to convey a “good face” (say, client documentation or marketing materials, for example), then it’s important for it to be well-written. But if it’s a mere matter of knowledge transfer, it’s more important that a concept is written down rather than not be written at all. If an idea needs to be cleaned up, go ahead and write it down, and let someone else do the grammatical heavy-lifting. Not being a good writer should not be an impediment to writing at all.

Advertisement

Testing is important for documentation, too

For those of you who produce documentation, how often have you sent your documents out into the real world, only to have it returned to say it’s all wrong? Or have you ever received feedback saying things like “this is difficult to read,” “I can’t follow this,” and so on?

One of my most frustrating aspects of technical writing is any time — every time — that I ask people to review what I write, my request goes ignored. As I’ve written before about the nature of documentation, requests for document review are often met with indifference and disrespect. A lot of people just don’t think it’s important. It is critically important. I don’t always know about the subject that I’m writing, and I’m often at the mercy of subject matter experts (SMEs) who know more about the subject than I do.

It’s not just the subject matter, either. I’m the first to admit that I’m a grammar snob, but I’m also not perfect, either (I was not an English major, after all). Many a time have I confused “who” and “whom,” ended a sentence with a preposition, used an apostrophe-S for a possessive, forgotten to put “I before E,” and so on. Likewise, I try my best to design documentation for better readability, but I also realize that there’s always room for improvement, and it often takes another set of eyes to provide a way to make something better than never occurred to me.

I’ve argued before that documentation needs to be treated like software. Like software, documentation has a life cycle. It needs to be maintained. And as such, it needs to be tested. Documentation, like software, will have bugs that need to be addressed.

It also isn’t just a matter of reading a document and saying “yeah, this looks good.” User testing should also be a part of it. If you’re writing step-by-step instructions, how will you know if they’re accurate? Back when I was a grad student at RPI, one of my writing projects included user testing as part of the project. I wrote a set of instructions for a procedure in my office (the document served a dual purpose for me — not only was I getting graded for it, I was also contributing to my workplace). To test it, I asked one of my co-workers to follow it as she went through the procedure I’d documented. She caught issues with my steps that I never would have caught on my own. From that user testing, I corrected the issues and made the document even better.

As a technical writer, I expect — and demand — people to review, test, and scrutinize what I produce. I demand excellence from myself. In order to achieve excellence, I need other people to review what I do. And I want to know that what I’m producing is of good quality and factually accurate. Without that critical feedback, I’ll likely not know whether or not I’m doing my job.

Treat documents like software

This is a followup to my earlier article about Agile and documentation projects.

I’m currently working on a document in which I’m outlining a group of processes within our application. My manager sent me a JIRA ticket to track the project. The ticket includes a few sub-tickets to track some of the specifics of the project.

It then occurred to me how we’re able to make documentation projects work in an Agile environment. It’s something I’ve been espousing for a while; in fact, I even make mention of it in my documentation presentation. I even made mention of it when I presented it a couple of weeks ago. (Ed. note: I wish I’d thought of this when the gentleman asked me this question at that user group meeting!) As it turns out, the answer is pretty simple.

The answer: treat documents like software.

Too often, documentation is treated like a second-class citizen. It gets absolutely no respect. That lack of respect is why I travel to SQL Saturdays preaching the gospel of documentation. Documentation is an important piece when it comes to technology planning; yet it is often treated as an afterthought.

In my current working environment, what makes document projects work in Agile is that they are treated with the same level of importance and respect as application updates. In a sense, document updates are application updates. They are important for end-users and developers alike.

In my daily Scrum meetings, I discuss progress made on my projects — almost entirely documentation projects. These projects are discussed on the same level as application and database updates. Tickets are created and tracked for these projects — just like applications.

I’ve had the luxury of having worked in both professional software development and technical writing environments. I can tell you from firsthand experience that the development lifecycle between the two environments is no different. So why do technical managers keep insisting on treating documentation differently? We are able to make documentation work because it is treated on the same level of importance and respect as application updates. Granted, it might be handled with a lower priority level (that’s okay), but the way documentation is handled is no different from the application.

If you want your documentation to be successful, consider it at the same level as you would your software development. It is a critical part of technology development, and it needs to be considered with the same level of respect.

The CrossFit Open 2019

This morning, I registered for this year’s CrossFit Open, which starts tonight. This is the third time in four years that I’ve signed up for the Open. (I was unable to participate last year due to commitments and subsequent time constraints.) Thousands of participants from around the world, representing many age groups and skill levels, participate in the Open. The best of them go on to the CrossFit Games. (The Games are represented by world-class-level athletes, of which I’m not even close, so don’t expect to see me participate at a regional anytime soon!)

Why participate in the Open? For one thing, it’s an opportunity for pseudo- couch potatoes athletes like me to take part in such an amazing event. Think of it as a Little Leaguer competing on the same field as, say, Aaron Judge. For another, it’s a measure of how far I’ve come in CrossFit since I started doing it over four years ago. When I first started, I couldn’t hold a squat without falling over on my backside. Now I can hold one almost indefinitely. Granted, I still have a long way to go — I still am unable to do anything involving pulling myself up (pull-ups, rope climbs, etc.) — but I continue to keep at it. Maybe someday, I’ll get them! It’s also a measure of how you do against your peers. You’ll get an idea as to how you stack up against similar athletes.

Other reasons? Well, let me, once again (as I’ve done several times before), quote one of my favorite song lyrics by my favorite band

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

“Inside Of Me” by Kansas

If you want to see how I do over the next five weeks, click here to check out my Open profile. We’ll see how this goes!

Wish me luck!

Treat All Sensitive Data as Important

Reblogging another important article by Steve Jones.

Voice of the DBA

We know that not all the data in our company is important. We have databases that contain orders or inventory or schedules, often much of which isn’t easily or directly related to an individual. At least, it’s not if you have a normalized database. If you use SQL Server to emulate Excel spreadsheets, it’s possible that most of the rows of information in your system contain sensitive data.

In some systems, there is definitely some data that is sensitive and needs more care than other data. We know this, and with legislation like the GDPR, we must protect this data. We also need to ensure we know where this data is, and having a good data catalog is important. This is something that few of us have, though I expect this to be a more regular part of our job as data professionals. SQL Server is building data classification into…

View original post 235 more words

When it isn’t appropriate to say “please”

I recently ran a work report that provided a list of diagnostic descriptions within our application. These diagnostics are stored in a database table, and they appear when an issue is encountered within the application. They provide an error code, a description, and a recommended course of action.

I was running this report so I could document the application used to generate the report. But when I looked at the results, something struck me.

There were sixty-one active diagnostics. Looking down the column containing the recommended courses of action for each diagnostic, something stuck out at me like a sore thumb.

In EVERY SINGLE action, the first word was “Please.” Every single action started with “Please ask…” or “Please perform…” or “Please do this…” Every. Single. One.

I was raised to be polite. My mother always taught me to say “please” when asking for something. For the most part, I agree with this. All children should be taught to say “please” and “thank you.”

That said, this is not appropriate in most professional-level technical communication.

When you’re writing technical instructions, you are telling someone how to do something. You are NOT asking someone for a favor!!! This is another one of my technical writing pet peeves. Writing professional technical instructions involves using language that’s direct and to-the-point. Unless the tone of your document is laid-back or colloquial (the “For Dummies” series of books comes to mind), it is NOT supposed to be conversational.

Now, I’m sure a number of people reading this might not agree. It should be pleasant to read, you might say. Here are the reasons why I don’t agree.

Instructional language should be neutral. See what I wrote above. I’ll say it again: you’re telling someone what to do, not asking a favor. You’re trying to get your reader to complete a task, not trying to make friends with him or her.

It’s extraneous. One of my tenets of writing instructions is that it needs to be as simple as possible. In my documentation presentation, one of my major points of emphasis is the KISS principle. A big part of keeping it simple (which, granted, isn’t easy) is to eliminate anything extraneous. Extra words add complexity. The less complexity that’s in an instruction, the better.

It’s annoying. When you’re reading a set of instructions, reading “please do this” and “please do that” gets old after a while. I’ve read instructions like that before (including the report I describe at the beginning of this article), and by the time I got to the end of the document, I wanted to slap the writer more than I wanted to finish the task.

When you’re having a conversation, saying “please” is very much appropriate. But technical writing is not a conversation. Conversational language is not appropriate in professional technical writing. As a technical writer, I’m imploring you: please stop saying “please!!!”

Can Agile and documentation projects co-exist?

When I spoke at the New England SQL user group meeting yesterday, an interesting question came up. An audience member spoke about Agile development, and he mentioned that, because of the nature of Agile, document projects were doomed to fail.

At this point, I should mention a few things.

  1. I currently work in an environment that uses Agile development methodology.
  2. Just because I work in said environment doesn’t mean I know anything about Agile.
  3. Even as my workgroup’s technical writer, I am considered a highly valued member of the workgroup.
  4. Somehow, we make it work.

In regards to #4 above, the gentleman had a simple question: “How?”

This question came up during a point in my presentation in which I argued that document projects should be treated like software — in that, in an ideal environment (stop snickering!), a formal document should be subject to planning, development, and testing. This is a point that I’ve alluded to before.

The person asking the question went as far as to say, “if you can make the case as to how Agile can make technical writing projects work, then you should make a presentation out of it — and I’ll even help you sell it to Agile.” He even gave me his business card. Indeed, one of my big reasons for writing this article is as a reminder to myself to revisit this subject — after I’ve had a chance to do some homework about Agile development. It’s something I’ve been meaning to do; I even went as far as to begin a draft article about Agile development.

So, to the gentleman who brought up this (great) question, you were heard. And I will make sure that I come back to this at some point — once I’ve had a chance to do my homework on Agile.

The relationship between technical writing and application UI

During a recent work meeting, we were discussing an online Wiki-like internal document that I’d written. There was mention of a line that needed to be included. I mentioned that I’d need to figure out how to word it, and where it should go — pretty typical work when editing any technical document.

For some reason, during that conversation, I started thinking about how locating that — and other pieces within the document — affected its readability. That thought made me think about interfaces — how certain UI/UX pieces on an application can influence how an end user views and uses it.

That’s when it occurred to me: there is a direct correlation between technical writing and UI design.

It should be an obvious idea, but for me, it was a revelation. There isn’t a lot of difference between how a document is laid out and how a user interface is arranged. Many design principles between them are the same. The user’s eye path follows the design. How he or she reads the document or uses the application is affected by how the document is laid out or how the UI is designed.

I’ve written before about how design is important. I’ve also written about documentation issues (time and again). Like everything else, technical writing and UI design is a skill. A good technical document and a good user interface both require planning — as it turns out, the same kind of planning — to execute properly.

Learn More than Technology

Nice article by my friend, Steve Jones.

Voice of the DBA

I’ve been lucky and successful in life in many ways. Certainly I’ve worked hard, may long days and nights, but plenty of others have as well. In fact, there are plenty of people I know that have worked more hours, but been less successful. Conversely, I know some that have worked much less and been more successful. It’s hard to know what the best way is for each of us to examine how to move forward in life, but it’s also not really helpful to compare yourself with others as a measurement. What I’d note you should do is decide if you think you’re becoming more or less successful and find your own path.

This could mean very different things to different people, and that’s fine. I don’t want to live other people’s lives. I want to live my own, learning from positive and negative things that happen to others…

View original post 392 more words

Upcoming speaking engagements (as of 2/5/19)

Things are getting busy. My SQL Saturday presentation efforts are paying off. It seems like I have a lot of stuff coming up! So for those of you who are having trouble keeping my schedule straight (like I am), here’s what I have so far.

I’ve also applied to speak at the following events. I don’t yet know whether or not I’ll be speaking at any of these, but we’ll see what happens.

There are some other events for which presentation applications are not yet live, but once they are, I intend to submit to them. They include:

  • October 5: SQL Saturday Pittsburgh
  • November 5-8: I intend to apply to speak at PASS Summit, Seattle! PASS Summit has been described as “the Super Bowl of SQL Saturdays,” so getting picked to speak here would be a big deal. We’ll see what happens!

So that’s how my schedule is shaping up so far! Of course, as the year progresses, this schedule is subject to change.

I’ll see you somewhere on the road!