Thinking economically

As I mentioned in a recent post, I've just completed reading Dear Undercover Economist by Tim Harford. I acquired a copy of Tim's book at the SAS Professionals Convention, and I was fortunate enough to meet Tim in person and have him sign the book. He impressed me as very smart, very personable, and quite tall (and as I'm 6'1" myself, it takes above-average height to impress me).

I do enjoy books of this genre: where the authors examine everyday behaviors and rationalize how incentives, which are often not obvious, play a huge part in deciding what people do. Freakonomics and Super Freakonomics are also part of this genre, and fascinate me as well.

I think that I enjoy these books because I tend to try to understand, from a rational perspective, what motivates the people that I interact with. For example, why does my 5-year-old daughter still throw temper tantrums? They gain her nothing. (Or do they?) Or, to bring in an example from my professional life, why does a SAS customer ask for a very specific feature in the product I work on? What's he (or she) really after as an outcome, and what's the best way to provide that outcome with the most utility for all customers?
Let's take a more concrete example. As I often educate customers about the benefits and capabilities in SAS Enterprise Guide for SAS programmers, I sometimes encounter someone who asks, "what about the DATA step debugger?"

It's true: we can't access the DATA step debugger in SAS Enterprise Guide. The debugger is part of the windowing interface in SAS display manager, and can't be run from within a client that connects to SAS as a headless server.

Update: as of 2016, the DATA step debugger is included in SAS Enterprise Guide. As requested!

Most people who program in SAS use the tried-and-true techniques for debugging: PUTLOG and LIST statements, OBS=0, and runs of partial steps to check their logic. But there is no question that you can get better information from a debugger if you know how to use it. And some of those customers (who know how to use it) tell us that they miss it when they use SAS Enterprise Guide.

What about the people who don't use the debugger, or even know about it? They don't bother to tell us that they don't miss it. And that's a constant challenge for folks who create software products: people are quick to ask for things they want (and that's good), but they don't often tell you about the things they're content with. That's why you have to ask.

But all of us who write programs can agree on one thing: we can benefit from a tool that helps us to write better programs. In SAS Enterprise Guide 4.3, we'll get a big boost in programmer productivity by having a program editor that offers syntax suggestions, autocomplete and built-in keyword help. This is a feature that will bring all SAS programmers forward, not just those that need to see what's in the PDV right now.

I believe that we will see a more comprehensive debugging tool in SAS Enterprise Guide, eventually. It's a natural feature to add for our programmer persona, an audience that we identify with and care deeply about. Making SAS customers happy -- that's what motivates us.