THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server 2012 Integration Services Design Patterns. His background includes web application architecture and development, VB, and ASP. Andy loves the SQL Server Community!
Note: Comments are moderated. Spam shall not pass! </GandalfVoice>

On Developer Communities: Feedback and Communication

Note: I never write about personal stuff that's happened until at least 12 months have passed. This affords both the event and my opinion of the event perspective that only time can bring. :{> Andy  

Introduction

I've written pieces of five books. Some of the publishers maintain forums for readers to ask questions or provide feedback, which I think is very cool. I subscribe to these forums (fora?) and reply as often as possible. I reply to all posts regarding content I authored.

I wrote it. I cash the royalty checks. I am obligated to support it. In my opinion.

A Funny Thing Happened On The Way To The Forum... 

A while back, I saw a forum post and related email chain from the publisher about some of my content. I replied to the forum post within 90 minutes of seeing the post, making a suggestion that I thought of as obvious, but which I may not have explained well enough for this reader.

The email chain followed, in which the same reader stated they had not received a response even though several days had passed.

I was confused. I'd just stopped doing billable work to answer this post - in pretty good time - and the reader was complaining in email to the senior management of the publishing company and editors of the book that he'd been ignored for days?

I expanded the hidden text in the email chain, the remainder of the thread, and discovered the reader had emailed the publisher's technical support a while back and had apparently received no response. Only later did he post to the book's forum.

I'm Here To Help

In this case, I was able to determine the reason for the frustration on the reader's part. That's not always the case. Regardless, I always want to help.

Most of the time, the folks I get to help are appreciative - realizing they're getting free (or nearly free) support and that the person offering the help has other priorities like (crazy as this sounds) spending time with their family or doing billable work.

It's a give and take sort of thing. Authors and MVPs enjoy non-tangible and difficult-to-quantify/qualify benefits for providing said support - like the attention of being an author, getting to hang out next week at the MVP Summit, peeking behind the curtain some at what's coming, and developer cred.

Bottom line, I enjoy learning new things a lot. It's my main motivation for sharing and helping others learn.

The Response

The originator of the post was flustered, to say the least. I was telling him to do the same thing I wrote - the very thing he complained wasn't working. In so many words, he indicated a lack of confidence in the quality of the book, the authors, the publisher, and me personally.

I don't know if you've had that experience, but it's no fun.

I had a list of questions a mile long, but I decided to ask them one at a time. Why? I troubleshoot serially, not in parallel. I'm not criticizing those who troubleshoot in parallel, I'm just stating it's not my style. I also find it's easier for the person I'm helping.

I also requested screenshots so I could see what he was seeing. In this case, something that should have been obvious and present simply wasn't. In the end, we were able to try a few things and the last one worked (like looking for your car keys... they're always in the last place you look).

Conclusion

The issue was resolved and the customer was happy.

Was it resolved fast enough for me, him, the author team, or editors? It sure didn't seem like it while we were working on it. After the fact, however, all was well.

It turns out to be another anecdote to demonstrate Andy's Law of QualityTime (like SpaceTime, only different):

Deliver quality late, no one remembers.
Deliver junk on time, no one forgets.

:{> Andy

Published Monday, February 23, 2009 6:00 AM by andyleonard

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

No Comments

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

My Company


Other Blog

Check out my personal blog...
http://andyleonard.me

Contact Me

Twitter: @AndyLeonard
Email: andy.leonard@gmail.com

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement