A good friend of mine once found himself struggling over a bit code. He handed it to me hoping I could help. I looked over it for a bit and found the issue. When I handed it back to him, I explained the solution and why it worked. He nodded as I explained then turned to me saying, “Now that you explain it to me, it makes perfect sense. What I still don’t understand is what on Earth made you think to even it try that?”
To this day, I consider the above the single best compliment I have ever received from a peer. I could not even begin to tell you what the particular problem was because to me, this was just another day. Regardless of what I am hired for, troubleshooting across projects is inevitably what I end up doing.
At a different job, I exited a team meeting and returned to my desk. Shortly thereafter, one of my teammates walked over to me, a quizzical look on her face. “You know, I could go back to that meeting room, remove every piece of furniture from it except a single chair. I could then walk our entire team through the room one at a time and learn everything about that chair I could possibly want to know. You on the other hand, would be the only one to walk through that same room and say, ‘nice lamp.’ You just don’t look at things the way other people do…”
This sideways thinking is obviously both a gift and a curse. When applied to a practical project, or an issue at hand, it allows me to leap ahead intuitively to a solution. Often, I do not even need to figure out why it works, the original project team will do so once I have gotten the problem passed the initial hurdle. However, when applied to future thinking, I find I am often either thinking too far ahead or thinking of too big a picture. Further, since this vision is “obvious” to me, I may well have difficulty selling the idea to peers or management. Often times, others will implement similar ideas much later when other pieces start falling into place. I sometimes feel I am just a bit before my time.
This final piece is a simplification of many peer level conversations I have had, while serving as a second set of eyes on a problem.
Teammate: “Robert, could you help me out for a moment?”
Me: “Certainly, what’s the issue?”
Teammate: … gives quick overview of problem …
Me: “Okay, try this…”
Teammate: “That’s not the problem.”
Me: “I know, could you please try it anyway?”
Teammate: “Sure. See, I told you that’s not it.”
Me: “Okay, now try this.”
Teammate: “That’s not it either.”
Me: “I know, just try it.”
Teammate: “Sure. See, I told you that’s not it either.”
… several iterations of this later …
Me: “Okay, now try this.”
Teammate: “That’s not it.”
Me: “I know, could you try it anyway?”
Teammate: “Sure. See, I told you that’s not … oh wait…”
Me: “Ta-da…”
Honestly, I never thought the by-play above was unique. However, given how often that same dialog plays out, along with incidents like the other two above, I begin to wonder.
Too many times I have been asked to stay on jobs with no real work for me to do, just because something else might break soon. I have been told I am my own worst enemy when trying to exit this constant parade of “odd jobs” and work on a proper project, because I continue to succeed where others have given up. In the words of one of my team leads, “…you are the only one I trust to just go in and figure it out…”
In the end, that is what I bring to your team. I do not bring arcane and obscure knowledge of specific languages, frameworks and technologies. I do not bring an academic or abstract view of your domain. I do not bring the ability to wrangle schedules and personalities to keep a project on track. I am a combination of Sherlock Holmes and Captain James T. Kirk. I will ferret out the answers, and even cheat if I have to. I will return life to once dead projects and features, I will prove the impossible can in fact be done. What you do with these solutions, is up to you.