Passionate programmers have a penchant for being irritable. Providing the absolute last line of defense between nascent idea and functional reality can be frustrating. The entire thought chain prior to the code we write frequently lives in diagrams, functional specs, wireframes, and the brains of those who claim to be the “idea guys.” Yet we’re the ones faced with the daunting, often underappreciated task of transforming an idea into a real thing. Bugs live only in code, never in napkin drawings.

In years past, software was this unapproachable, command-line-driven thing that only geeks, dorks, and nerds used. It was built by even geekier geeks, dorkier dorks, and nerdier nerds. Back then, it may have been OK to play the stereotypical role of the antisocial, generally off-putting curmudgeon.

Today, clients are everyday people, not just other software guys. They use the products of our labor like they use furniture. It’s just there. The line between when someone is using software and when someone isn’t is quite blurry. Technology is a mainstream industry now.

This means we need to button up how we work with the people we’re building software for. So, when one of our clients, one who isn’t tuned into how we work, asks whether they can just add another feature here that, in reality, breaks an already agreed upon assumption and undermines the entire architecture of your application, it’s all too easy to quickly retaliate.

Instead, be forgiving. Understand the view from above the hood while you’re entrenched working under it. If a client’s request isn’t practical, explain to them why. Give them an example scenario that opens up that “whole new bag of worms.” Offer an alternative solution to solve the problem they’re having.

In addition, make it a habit to talk to them in person. Hear their real voice and let them hear yours. Pick up the phone and call them instead of just emailing. You’ll be surprised at how far a compassionate-sounding voice can go in getting things set your way.