Justin C Barrett:

The Dangers of ‘Can’; Coping With Being Visionary

I have been described as a “visionary” developer in the sense that I have a knack for coding my way through problems and overcoming challenges, often ending in landing on a solution we hadn’t thought of to begin with.  I take that as high praise, considering the sources where I’ve heard that said, and I humbly accept the compliment.  However, one thing I find myself not articulating is that that compliment comes with an implicit responsibility; anytime I’m asked a question with “can”, my answer must include consideration for “should”.

Example:  I can use an app on my phone to run a command at 8am to send a good morning message to everyone in the office,  send a start command to a wifi-enabled Raspberry Pi RC Car to put a cup of coffee on my desk (freshly brewed by the wifi-enabled coffee maker), and fire a confetti cannon when my phone connects to the company wifi, marking my arrival.  Now would you like to discuss the part about a coffee-wielding RC Car driving blindly down a pre-installed path from one end of the building to the other?  Or the havoc wrought when the coffee maker didn’t have a k-cup preloaded?  Should we go ahead and get a Roomba for the confetti?  Is “RC Car Casualty” covered by our insurance?

Now, obviously that scenario is rampant with sarcasm (I mean really…when is the coffee maker not preloaded?) but the sentiment stands.  The trick I’ve learned is to enforce a policy of “give me a ‘use case'” whenever I’m tasked with answering a “can”.

For instance:  I was driving home tonight and passed through a small construction zone.  There was a large metal plate on the ground covering (what I know to be) a manhole that was being worked around.  We’ve all seen these and you know what I’m talking about when I say I grit my teeth and imagine my tires shrieking a little as they meet those sharp edges.  Somewhere, sometime, somehow, someone asked someone else “can we just slap a steel plate over it to cover it while we’re still working on it?” and Else-person said “sure.” and that’s where the conversation stopped and action started.  Else-person went off to talk to the steel plate maker people, got a steel plate, dropped it over that hole and strained his arm a little patting his back after solving such a heinous dilemma.  The hole is covered!  All is well.  On to the next thing.

By using the “use case” filter, Else-person may have responded instead with “well, cars are going to drive over it, so let’s make sure we’re not going to gouge chunks of rubber out of every car going over 5 miles an hour on this freeway” and then, when talking to the steel plate maker people he might have said “hey, lets round the edges and make an angle on either side, like a short speed bump” and poof, no more need for a mouth guard while driving through construction zones.

In case you missed it, I am Else-person and whenever I’m asked “can”, I typically reply with “should” or some example of why that idea may require modification.  As a developer, I believe that any challenge that I take on is just a matter of time before I get through it; I don’t see impossibility, that’s my secret.  Part of my responsibility for such openness is to constantly game-out scenarios to make sure that I’m not going to trip my boss with an RC car, burn them with scolding-hot coffee, and season it with my arrival confetti.  Just that simple query is enough to solve a great deal of head (and other) aches down the road.  The answer, by the way, is obviously to use an aerial drone instead.  Just make sure it’s out of the way of the cannon….

 

Written by Justin