Over the past week, I’ve listened to and read several articles that have started me thinking more about the Psychology of Programming.
Not that I haven’t been thinking about this for a while. I’ve been quite intrigued by human behavior for a while now. But more recently, there was this podcast over on dotNetRocks about “Punishment Driven Development”. And this comment:
The happiest people in my experience are those that have options. They have transferable skills, see their employment as a personal choice, have self-confidence that they are providing value to the company and are in a position professionally and personally where they could change job if they needed. The feeling of being trapped in a position from which you can’t escape (either a dissatisfying job, bad manager or whatever) will lead to negativity.
Which I almost agree with, except I think it is the negativity that leads to feeling trapped. And then there is the book I am reading, “Influence: The Psychology of Persuasion” which goes into detail on why we make decisions that seem to go against our better judgment.
Then there is another podcast that discusses the decisions we make as we start a new JavaScript project.
And all of this culminates into the following thoughts: 
What Makes You Happy?
It really does amaze me that I work with people who seem so unhappy with their work place and yet, aren’t making any effort to find another place to work. As a consultant with nearly 30 years of experience, I can tell you first-hand that some places are better than others to work. There is probably a place for you if you’d just try to find it.
Or, maybe the problem is you. Maybe you’ve never liked working. Or maybe you like complaining. Maybe being happy is an attitude and isn’t really dependent on our circumstances. Maybe, the happy people like their jobs?
Or maybe it is just easier to blame the company than to take responsibility. I find happy people take action. Make opportunities. Learn new stuff.
The unhappy people I know blame something or someone for who they are.
It’s All in your Head
Here is a scary thought though. All your ways of reacting to events in your life are learned responses. Most of those responses you learned before you were 5. But, here’s the good news. Since they are learned responses, you can, if you want to, re-learn responses.
We all have behaviors we don’t like. Some of us get angry for stupid stuff. Some of us over eat. Some drink too much. Some smoke. In almost all cases, the behavior isn’t the real issue. The question we need to ask ourselves is why do we do those things? In what way do we believe doing these things is going to help us? What would you need to believe differently in order to change? What is keeping you from believing something different?
It’s Just an Opinion
I have a rule. “Never argue about opinion.” I’ll present why I believe something is true. State all my reasons. Clarify if I think that is necessary. But as soon as I realize that the discussion has turned into an argument where no one is going to convince the other of anything. I disengage.
Not everything is opinion. I’ve had people leave comments correcting my understanding and pointing to authoritative documentation that says they are right. Thank you. But, in the grand scheme of life, there is very little that falls into the realm of fact. Most of what we argue about as programmers is opinion.
What is interesting about opinion is that the more you know about a subject, the more opinionated you are likely to be. That can be a good thing. Show me a programmer who doesn’t have opinions and I’ll show you a programmer who is just doing what they’ve been told to do. Show me a programmer who has an opinion but can actually argue multiple sides of an argument and I’ll show you a programmer who really knows his stuff. If you hold opinions so strongly that you are offended when someone disagrees with you, you have an issue.
Herd Mentality
For years, it has puzzled me how, as a community, we can know that writing unit test for our code is a worthwhile activity, and yet hardly anyone I know does this. Truth be told, it is a struggle even for me.
But, here’s an interesting fact. We tend to do what we SEE others doing. If no one on your team is writing test, you think, “we don’t write test here.” This behavior explains why, in test after test, groups will ignore people who need help while individuals by themselves will provide aid. This impacts a lot of our life if you think about it. How many times have I assumed that someone else is going to call the power company when the power goes out during a snow storm? Certainly, if the whole street is impacted, someone will call.
The very fact that it has impacted the whole street is indication enough that no one else has called. I hope I remember this the next time the power goes out.
Appeal to Authority
Another scary statistic is that people will do whatever they are told to do if an authority figure has told them to do it. If there is any question about what we should do, we will try to figure out what the authority figure wants.
This is how con men work. In a very scary experiment, a “doctor” calls the nursing desk and tells the person who answers the phone to administer a drug to a patient. The problem is, the prescription is too high and is of a drug that is not approved for the nurses to give. Yet, because a doctor has said so, they are willing to comply In a more humorous example, a patient had an ear ache in their right ear. The doctor left a note with instructions to administer ear drops to the R ear. So, the nurse administered ear drops to the patients rear. Neither the nurse nor the patient questioned the instructions.
Oh, but that would never happen to programmers now. Or would it?
Again, I go back to the point of testing. I can’t tell you how many times I’ve heard programmers tell me they “aren’t allowed to write unit test.” For the most part, I’m not sure anyone asked, they are just assuming that the boss won’t let them because of the Herd Mentality I mentioned above. But let’s assume the boss really has made such an edict. Is that a good reason to not tests? I’m not sure it is. At least no more so than administering ear drops to someone’s butt.
But I’ve also seen this behavior first hand. I was on a project once where the organization claimed to be “Agile.” For the most part they were. They worked iteratively. They had something resembling sprints.
But a “boss” several layers up the ladder who we never saw had “instructed” the team to do this project using a waterfall approach because “we already know what this product is supposed to do.”
The problem is, while this project was a rewrite of an older system, the rewrite encompassed many changes to the existing system. So, even using that argument, using waterfall made no sense. But, everyone on the team also knew that what made a project an agile project vs a waterfall project had a lot more to do with being able to adjust. Why no one ever told the manager he was wrong is beyond me. What is further interesting is that even though that project received a new manager, the team STILL tried to obey the old rule because they hadn’t been given an alternate direction.
Inertia
The famous last words of every dying group are, “But, we’ve never done it that way before.” Why?
Did you know that people will work twice as hard to keep the dollar in their pocket than they will to gain an extra dollar? This explains so much of human behavior for me. This is why startups have such an advantage over established companies. The startup has nothing to lose. As soon as they feel like making a change will cause them to lose something important, they’ll stop innovating. They become the established company. If an established company can survive long enough to have nothing to lose, they might innovate. For an example of this, check out the turn around of both Apple and Microsoft. If you look very closely, you’ll see that Apple is moving into the “we have something to lose” cycle.
Now, how does this apply to you as the lonely programmer?
Well, back to our sad programmer example. Could it be that our sad programmer doesn’t change jobs because he’s holding on to his dollar instead of trying to get a new one?
Could it be you aren’t testing your code with formal unit test because you are holding onto your dollar?
When is the last time you tried anything new?
Break Free
And so, the question naturally becomes, “How do we break free?”
So much of this is a part of who we’ve learned to be. Many of our behaviors have helped us get to where we are. But like the company who has moved from startup to established player, we need to become comfortable with being uncomfortable so that we can not just break free, but break into a better version of ourselves.
Maybe you are comfortable where you are. I don’t know Personally, I’m always trying to improve. I’d much rather have the new dollar than keeping the dirty old one. You might have a different set of values. Maybe a different opinion.
I could be wrong. But, what if I’m right?