I read Software by Rob‘s article on Personality Traits of the Best Software Developers and I was really intrigued by the Pessimistic trait. Rob (I’m assuming that this is the writer’s name) contends that pessimism is a great trait for software developers, but you have to read the section on pessimism carefully to get a good appreciation of what Rob is trying to say.
Pessimism is good as an initial reaction to a situation. At some point optimism must take over from pessimism though. Originally this post was going to be an argument that there were actually three favourable phases that a good developer went through: cynicism, pessimism and optimism. After a number of discussions, I’m no longer sure that cynicism is a positive trait for a developer.
Let’s look at the definition of cynicism. Webster’s says:
An attitude of scornful or jaded negativity, especially a general distrust of the integrity or professed motives of others
The first word that jumps out at me is negativity. It doesn’t matter if you’re a McD’s drive-thru attendant, a software developer or the head of state, negativity is counter productive. A single person’s negativity is like molding peach in a basket. All the other peaches will mold more quickly with it around. On a software development team, one negative member will slowly infect and corrode the rest of the team. We all know that corrosion is bad, but imagine your software development team as a steel girder bridge. Corrosion (negativity) is no longer bad, it leads to failure, destruction, mayhem and death. Okay, maybe death is a stretch, but some marketing people are high strung enough that you can realistically see them walking into a developer pod after a project failure and offing someone.
The second word that I was immediately drawn to in the definition of cynicism is distrust. In my software development experience distrust is a product of the environment (thanks to D’Arcy from Winnipeg for pointing this out to me). The environmental causes of distrust can range from a belief that the business will always impose a deadline without first consulting the technical team to an understanding that the decision maker has no apparent focus or concern for the company / project / team / product. Regardless of the reason for the distrust, it is a gnawing problem that will, like a termite, slowly erode the foundation of the structure you belong to. The thing that we often fail to realize is that this erosion will only take place from the level where the distrust reside and lower. Essentially, distrust at any level will permeate that level and the ones below it, but rarely will it proceed higher.
So where do I end with these thoughts? Cynicism is cancerous. Unlike cancer though, we can determine the root cause of it and attempt, and often succeed at, treatment. Treatment is not easy though. It can be an arduous road that takes a great deal of time. The first thing you need to do is determine the root cause of the cynicism. Rarely will you be able to approach a cynical software developer, ask “Why are are you so cynical?” and get an insightful response. Instead, I think, you need to take your time and listen to the cynic in his/her natural habitat. Don’t ask questions. Instead listen to their gripes and try to get an understanding of why they’re bitching. Is it just because they don’t want to try to do new work or take on a new technological challenge? Maybe it’s because they’ve been burned by the client (who ever that is) enough that they can’t see by the “Here we go again” thoughts that they are having.
Regardless of the cause of the cynicism, you need to treat it like a software defect. The sooner you address it the cheaper and easier it is to resolve. There are two difficult things in this. First you have to make sure you’re not the cynic on the team. If you are, and you’re a team lead, all is lost for your team until you can change your outlook on things. The second is that you have to be able to recognize that a team member is becoming jaded and cynical. This is difficult because the onset of cynicism is slow and gradual. Anything that changes in this manner makes it hard to see that a change is occurring. The best advice I can offer is that, if you’re a team lead or senior team member, you should make the time to remove yourself from the work environment and find a place where you can think clearly about the situation and the people. Maybe it’s going for a walk around the proverbial block, or maybe it’s taking the day off and getting completely away from the environment and team. Either way, you need to make the time to isolate yourself and perform constructive analysis of the team members and their outlook on the software development life cycle. Of course this is no good if you don’t listen and talk with your team members, so make the time to do that too. It doesn’t have to be formal conversations, but listen to what they say when you drop a bombshell piece of work, or a small change, on their plate. In the end maybe the reason for the cynicism is addressable. Perhaps you can go to the ‘boss’ and talk about how his way of working is adversely affecting the team. Maybe the issue is with the person though, and this is much tougher to address. If you can’t work with the person though, you have to be able and willing to cut rope and let them go where the currents may take them. It’s not good to have to do this, but the prospect of amputating a cancerous limb sometimes is better than living with, and fighting, it.
I’m the biggest cynic of them all. Like so may other things in life I think you have to take account for yourself before you work on, or with, others problems.