We techno-geeks like to think that we make all our decisions based on dispassionate evaluation of empirical facts, but there are times when things just don’t pass the sniff test. I’ve been in this game for nearly 30 years and my sniffer sometimes smells that “off” quality of the air in the IT fridge in ways that it’s hard to articulate, even to myself.
For example, currently I’m part of the input to a client’s decision process to move from hosted servers to cloud servers. Some on my team use words like “no brainer” and talk about cutting our hosting budget by over fifty percent with virtually no downside. They may even be right, but I’ve yet to see an “it’s too good to be true” scenario like this that didn’t ultimately prove — well — too good to be true. I’ve also yet to experience a major decision involving the use of the term “no brainer” that didn’t involve people seeing what they wanted to see rather than what was actually there. I know that the decision, ultimately, will be less clear than early hopes would indicate, but that it’s important to do the hard work of seeing the warts and dangers of an idea as clearly as its virtues.
I also am painfully aware that our hosted service vendor deserves tremendous loyalty and respect for providing an infrastructure that Just Works for the better part of two decades across multiple clients. There is a particularly nasty smell involved in lightly abandoning them for the sexy chick in the cloud who barely has a customer service department.
I also have on my plate at the moment, a proposed database schema change that “smells” because it’s adding complexity that experience suggests to me may point to a leaky abstraction somewhere. I’m having trouble communicating my sense of smell to the other person involved, in part because they only see the part that mildly simplifies things for them.
In both these situations it’s easy to be seen as obstructionist, “can’t do”, and stuck in the past — even as dense. Yet it’s part of my value proposition to bring my experience and seasoning to bear on decisions like this, so I assert myself in discussions that I’m tempted to just ignore in favor of focusing on more enjoyable moment to moment projects.
Although a few of my readers are more experienced developers, most are young people “managed” by slightly less young people and/or by people with little practical knowledge of your craft at all. If that describes you, let me encourage you to look for patterns in people’s behavior and to perform rigorous post-mortems on every success and failure you encounter along the way in your career. As the years pass, you’ll sense, more than see, recurring themes which you will label “trouble”, “good”, “better” and “best”. Learn to trust these things. “Use the Force”. Build up a fund of wisdom that you can bring to bear.
There is no one “right” decision in the vast majority of cases. Don’t be mindlessly influenced by other people’s enthusiasms or by a desire to please or by a fear of potential conflict.
Dealing with people terrifies many technologists. It’s often why, in medicine, people abandon clinical work for research, or why, in IT, people flee from responsibility and develop “us vs them” mentalities about “empty suits”. Resist the temptation to blame all your problems on the suits. Own your role in things. Learn to appropriately assert yourself and trust your own judgment. It’s often all that stands between you and nice things like advancement, recognition, and trust. Those things come not just from cranking out heroic code, but from learning how to steer a steady course through difficult choices and taking into account how those pesky humans will act and react over those decisions.
Consider devoting less energy to seminar after seminar, tool after tool, methodology after methodology, and instead pay more attention to developing a personal philosophy of software development and interaction with others. In this way you’ll bring your own unique value proposition to the fore and you’ll be less and less the fungible commodity that modern business often wants to view you as.
With a little effort in this direction, you can be more than a Sack O’Skills. You can’t put “good bullshit detector” on a list of skills and experience, but having one of those will save you much grief.
