Monday, June 8, 2009

Whats and Whys

I just realized something about myself today: when someone is talking to me, I'm not only listening to what they are saying, but also trying to deduce why they are saying it. Not consciously, of course, or else I would have realized that I'm doing it long before now. :)

In hindsight, I think this has been mostly a good thing. As a software engineer, when a request comes in for feature "X", rather than just understanding that the customer wants feature "X" and immediately starting to work on solving that problem, somewhere in the back of my brain I'm thinking about why the user asked or "X". What are they probably trying to accomplish? Is there perhaps a simpler way to achieve the same result that we can present as a counter-proposal? Is this something other customers might need too? If they are asking for feature "X" now, then they'll probably need feature "Y" at some point in the future too.

Which is to say that I think this has made me a better software engineer. However, sometimes it takes me a night or two of "sleeping on it" before I start being aware of the implications of the request. I've gotten into the habit of splitting my project to-do list into "things needed to do what the customer specifically asked for" and "things needed to do what the customer probably wants" categories. Obviously, the items in the list needed to satisfy the customer's explicit requirements always take priority. But I'll freely add items to the "customer will probably want" list as they occur to me, to be implemented in down time between projects or assigned as introductory tasks to junior engineers to get them familiar with the code base. From experience, I've found that this process results in more generic solutions to problems that make the product more resilient to changing requirements and adaptable to new customers.

On the flip side, I've gotten myself in trouble a few times by reading to much into my wife's words. I don't think I'm unique in that regards either. :)

Today I realized that I am sometimes perplexed by requests/statements from my Japanese co-workers. Of course there is the language barrier which means that it takes a lot more effort on my part to understand what is being said. But sometimes I know I comprehend what they are saying, but I still have an uneasy, discontent feeling. That is when I realized that my brain is subconsciously trying discern the "why" behind the statement and failing, causing the uncomfortable feeling.

As for why it is failing, I'm still unsure. But now that I think I know what is going on, I can work to address it. I suspect it may have nothing to do with the fact that the statements are in Japanese, but rather be a symptom of information asymmetry inherent in working in a large company. In which case, it would explain why I always seem to flourish in small company environments where information is more evenly distributed, hence making it easier to deduce the "why" behind new tasks.

1 comment:

jjinux said...

Good post, and I know exactly what you mean.

In the BDD world, we start our tests like this:

Feature: User Sessions

So that I can access subscriber-only junk, admin the site, etc.
As a registered user who is a subscriber or admin
I want to log in and access things that have access controls on the

The BDD guys are all about asking "why, why, why." Apparently, the trick to getting them to shut up is to say, "Because the boss things it's necessary to make money and sustain the business." ;)