Monday, November 7, 2011

Friendly Neighborhood Team Killer

Highlights from the latest Database Weekly.

Andy Leonard posted something really great about Performance-Based Management over at SQL Blog. The crux:
“[F]riendly competition” kills teamwork faster than anything else. Good people feel less motivated to help because they are punished for the success of others.
Please read all of Andy's appropriately titled post for yourself: Performance-Based Management Stinks.

Someone I'm unfamiliar with, Hugo Kornelis, has a great post (also at SQL Blog) called Principles of Modeling: the Concreteness Principle. His specific intent is to help database designers move past abstract examples and instead use concrete examples whenever possible. The post has a lot to say about communication in general. The post is steeped in database jargon, so I'm not sure it would resonate with someone unfamiliar with databases. But hell, give it a try anyway. All he's basically getting you to consider is that sometimes the question we hear isn't really the question that was asked. Spoiler alert -- here's the ending:
"If this blog post has helped you to become more aware of the way you talk with people, the way you ask questions, or the way you make an argument; if you now try to avoid abstractions and use concrete examples instead, I have achieved what I aim for. Even if you are not (or not always) able to present those examples in a notation that’s familiar to the person you are talking to."
How can you resist?!

Monday, October 24, 2011

Monday Morning

Today is Monday, which means I get to peruse the Database Weekly newsletter from SQL Server Central. I don't even know how or when exactly I first subscribed to the Database Weekly, and now I can't even find a link to share here. But here's what the email looks like:

Anyway, I get this fantastic database newsletter each Monday, and I always plow through it and find interesting links that I click but don't exactly have time to read. I'm sure plenty of great links get lost in the whatever of time and the ether and all that. So, for the record, here's what looked interesting to me this week:

Book Review: MDX with Microsoft SQL Server 2008 R2 Analysis Services Cookbook
I'm dying to build a cube using Microsoft SQL Server Analysis Services (SSAS), and MDX is sort of the language of the Microsoft cube, as far as I understand. This book would be beyond what I need to read now, but who knows, my curiosity may get the best of me and it may end up on my bookshelf before long.

SQL Server table columns under the hood
Good FYI info on understanding what a table is made of. I usually just highlight the table name in an SSMS query window and hit Alt+F1 to get the details on a table. This post acknowledges that my method is a common one, and then asks this:
"But ... ‘What are the physical columns of this table?’. Huh? Is there any difference? Lets see."
 Hmmm, there's another way. Good to know. May come in handy some day.

Week before last was the annual PASS Summit, a big geek fest for SQL Server enthusiasts. Don't misread me -- I totally wish I'd been there. I follow a bunch of SQL pros on Twitter, and after the PASS Summit a little Tweet thread materialized about what should happen when a presenter at a PASS event (the Summit, SQL Saturday, or SQL Rally) cancels before the event. I was surprised how many people supported a zero-tolerance attitude on speaker cancellations that Steve (Twitter | Blog) writes about in his editorial. I've never been involved with organizing one of these events, so I've never felt the pain of trying to fill a gap in the session schedule. It's just that this SQL Server community is full of compassionate, helpful professionals, always eager to share tips and reply to help requests from novices (me!). Adopting this "If You Cancel, You're Banned" stance seems very out of character for this crowd.

Sunday, October 23, 2011

Job One: Me

Steve Jobs died a few weeks ago. You can't escape news, blogs, and quotes about him and all of his lasting nuggets of wisdom. And I'm inclined to let the dust settle before buying into every nugget of wisdom that he ever espoused, propagated by the endless information machine, the machine that can never get enough of well-known people dying. So I'm kind of annoyed that the most prevalent Jobs nugget is informing my current attitude about life and work:
Your time is limited, so don't waste it living someone else's life.
Jobs said this in his famous Stanford commencement address, and if you search Steve Jobs today you'll find tons of links to it. So here's another one.

How is anything more true than that? And why is it so hard to break free of the path that others (directly or indirectly) set out for us? In my own head, the quote is ringing as this question:
Why aren't you doing what you want to be doing?
And I keep answering back something to the effect of, "It's not that simple, man! I got bills to pay, babies to raise." But that's not really an answer. It's dodging the question. It suggests that "what I want to be doing" is watching endless movies amidst a pile of empty Diet Coke cans. But the thing here is work.
Why aren't you doing the work you want to be doing?
Now we're getting somewhere. Accept that work is necessary. Not just for paying bills and raising babies, but for mental stimulation, for life satisfaction, for purpose, for meaning. Accept that every day I will get up and do something productive, something that solves a problem, satisfies a need. How then is this not the most important question to be asking? Doesn't the problem or need deserve someone wholly interested and dedicated and passionate about its resolution or fulfillment? And doesn't one's passion, dedication, interest, time and labor deserve a worthy task? And doesn't it feel like now I could loop back and around again, endlessly? Worthy task deserves quality work deserves worthy task deserves quality work... round and round it seems to go.

Now I'll try to take this back to the beginning, about "living someone else's life." I'm hearing this Jobs quote everywhere I turn, and it has seeped in. Lately I find myself questioning nearly all my actions and decisions, testing whether I'm listening to my own voice or someone else's. And that questioning has led me to write this little rant and post it. Because the hardest thing about this blog has been to make it my own, to use my voice. I can no longer insist that what I post here must conform to the expectations of someone who is not me.

And I feel better already.

Thursday, June 30, 2011

Read Receipt

Found a good piece this morning on Fast Company's Co.Design where a design firm was asked to rethink the common sales receipt. The story's subtitle sums it up well:

Why shouldn't receipts be a way of connecting with customers, in a whimsical way?

Good example of using technology and creative thinking to make something meaningful out of a ubiquitous throwaway item.

Sunday, April 17, 2011

Watch Out?

New technology is great and all, but my wristwatch works. It does exactly what I want it to do--it tells me what the time is. I don't need a better tool for that. I don't need an app.

That's why I was surprised to come across an article in The Atlantic recently that says the wristwatch is quickly becoming old-fashioned. According to the Benoit College Mindset List more and more people are forgoing a wristwatch in favor of the clock on their cell phone.

I don't see myself ever making that trade.

Just as I don't see the wisdom in forgoing a wristwatch for a cell phone, I'm equally puzzled by what Fossil is trying to do in response to the decline in wristwatch interest. Fossil is designing the MetaWatch. The MetaWatch maintains a Bluetooth connection to your smartphone so that, just by looking at your watch (which, if you're under 24, you don't even want to wear in the first place), you can conveniently be apprised of new messages, pictures, or content urgently awaiting your attention on your smartphone, which is all the way in your pocket.

Saturday, April 2, 2011

One Less Cook in the Kitchen

I just sat through one of the most rewarding sessions at SQL Saturday in Dallas. John Paul Cook gave priceless SQL Tips & Tricks. And unbelievably, right at the end, he told the sparse audience that this was his last SQL-related engagement ever. He recently quit his job and is set to begin nursing school, with the idea of being a medical records expert.

I'll be forever grateful to John for:
  • Ctrl+R in SSMS
  • Ctrl+H with 'Use: Regular expressions'
  • Alt+Select
  • and the wisdom of using Portable Apps on Production servers
John blogged a lot at SQL Blog, and I would expect his posts to remain online for the foreseeable future. The blog archive is a great reference source, but I can't imagine it will compare to the peculiar charm John has in person. I would love to have John Paul Cook as a teacher. But at least the digitization of medical records will be in good hands.

Monday, March 21, 2011

Do What's Hard

Any IT professional who serves any type of end user could benefit from reading this post by DBA Survivor.

I'm not a DBA, just a lowly Business Analyst supporting corporate business systems. Support is a reactive role. We're only needed when there's a problem. And one thing I've learned is that responding to a problem is often as important as solving a problem. It's important to let the user know I'm trying, whether the problem is in my area of expertise or it's something I know I'll have to hand off to someone else. A quick phone call, email, visit to the user's desk--any of these responses communicates to the user that someone hears them, and is trying to help. People like to be heard.

And if I fail to respond promptly, or if I fail to follow through, or if my solution doesn't work, the best medicine for everyone is to take responsibility. Owning up lets me get back to the problem at hand instead of wasting my energy dancing around some failure or oversight that's in the past and can't be undone anyway. Taking responsibility for failure is hard, people know it's hard, and people appreciate it when they see it.

So check out Responsive Versus Responsible. It's a quick read, and worth it.

Friday, January 7, 2011

What it isn't

Someone in one of my MIS courses once tipped me off to Joel on Software. "Joel" is Joel Splosky. He worked on the early Microsoft Excel development teams. His whole backstory is posted on his blog.

Joel's been posting stuff for years, and I'll sometimes just poke around his archives looking for some nuggets of IT wisdom. Joel is very good at laying out how not to do things, or why what seems to be the most intuitive approach to a problem is really the wrong way to go.

Today I came across this post from 2000 (which seems like ancient history, yet the article is refreshingly relevant). It's called The Process of Designing a Product, and what's so great about the post is ... well ... what it isn't. That is, it isn't a boring instruction manual. It isn't some stupid Wiki-How article that really conveys no actionable information. The article is, like, human. I mean, it's geeky, but it's written for geeks who don't realize that most people aren't geeky like them. And by most, I mean 99.9% of software users in the world.