In software development, there are — how to put it delicately? — prima donnas. It’s always been that way, but this year I’ve had more than my share to deal with, and it’s moved me to reflect on the nature of professional conduct. What, exactly, constitutes “professional conduct” in this field?
Accusations of “unprofessionalism”, after all, can be nothing more than wounded dignity. Recently one of my clients hired a developer for a small one-off specialty project that I was tasked to honcho. We got on fine, but the delivered product was not properly tested and simply didn’t work. I didn’t think the flaws ran deep, but it seemed pretty clear that the executable was tossed over the transom to me without sufficient testing. The nature of the problem was such that there is no way that valid output had ever come out of the program.
I worked with him in my usual easy going, non-shaming way to trouble-shoot it but it was a busy time for me and it was worked I hadn’t allowed for. I had to install various dependencies on my personal development machine and the back-and-forth with him on that took some time. One day he wrote me and said these delays were causing him “big financial losses”. Mind you it was a flat quote project for $2500 and there was nothing preventing him from taking on other projects — our testing and trouble shooting was a small side show. I mentioned as much and basically said, please don’t make that my problem — let’s continue to work together on this and get through it, get the software done and get you paid.
He then became 100% unresponsive for a week, and I suspected a bruised ego. Sure enough, he emailed the CEO of my client company complaining that I was “abusive and unprofessional” and demanding that another resource be assigned to work with him. He mentioned that he had a master’s degree and 30 years of experience up to the CIO level, as if this should insulate him from ever being questioned or said “no” to. The irony of the incredibly egregious unprofessionalism of his own conduct was apparently lost on him.
In writing my client he had included the email chain that led to that point. My client could not see what his problem was or what I had done to set him off. She gently told him all our resources were maxed out and he would need to work with me. He did, and we both basically pretended nothing had happened, and the job got done. In that sense, I guess, we both conducted ourselves … professionally.
My relationships with both clients and colleagues are uniformly smooth in the main, but I’ve had to deal on limited occasions over the decades with people who have personal problems that leak into their business relationships — petty jealousies, paranoia, inflated egos — the kinds of things anyone reading this has to deal with from time to time. The common thread that runs through those regrettable situations, in my view, has been arrogance.
One of my early gigs was to un-stick a project that hadn’t gotten anywhere in some months and the discovery I made about the root cause was that the developer who had been working on it had not so much as compiled the code in many weeks. He was obsessed with the perfect design and could not tolerate even the criticism of a compiler error message that might disagree with him. You can call that OCD, or fear — but at bottom, isn’t the inability to receive honest feedback, even from a machine, an example of the arrogance of insisting on being provided a perfect world to operate in?
Needless to say, that fellow thought I was unprofessional for sharing this problem with the client, and that the client was unprofessional for replacing him. But the client did enjoy getting a working system in a matter of days. Life is unfair sometimes. That fellow went back to academia to get his master’s degree and no doubt still thinks the whole situation was unfair to him — and may have never reflected how unfair it would have been to the client for things to continue to be “fair” to him.
That was an extreme example, of course, but it hasn’t been lost on me that most of the much more minor blind spots I’ve seen in myself and others have had to do with the idea that software “ought” to respond as expected by its creator, that users “ought” to use the software as expected, that acceptance testing “shouldn’t” take “so much” time, that we shouldn’t have so many budget constraints and procedures and so forth. In short, arrogance.
The most fundamental arrogance we developers are prone to is to elevate personal needs and requirements — even largely legitimate technical ones — over business needs and requirements. Admittedly, it’s a delicate balance, because neglecting legitimate design issues can provide short term business benefits and yet also long term business harm. But ultimately we are solving problems for customers, not building personal playgrounds. The final call on business value is seldom ours to make anyway.
To me, professionalism is best manifested by caring more about the sustainable advantage of the customer than about having a pleasing environment for myself. About making the customer look like a genius, rather than myself. That sort of thing. Caring too much about who gets credit or advantage or perks is the road that leads to colleagues, and ultimately clients, not wanting to deal with you.
Also, you should never leave the “corporate world” under the illusion that independent consulting actually allows you to escape dealing effectively with other people, even (and especially) difficult ones. Consulting is not “writing your own ticket” in that sense. In any event, often, people are difficult only because you haven’t taken the time or trouble to truly put yourself in their shoes.
I hope you’ll comment on this post to share with me your own experiences with (un)professionalism in software development, and more importantly, how you effectively managed those encounters. I’m particularly interested in how independent contractors deal with these things. We often are brought into troubled situations, not infrequently in troubled companies, where we are perceived threats to existing players. There may be resentments engendered by a perception that we make too much money, have too much freedom, or don’t have enough skin in the game — or simply because we are the outsider, the Other.
We technicians need all the people skills help we can get — let’s help each other out.
