Cognitive Dissonance in Programming

Cognitive Dissonance in Programming

In the field of psychology, cognitive dissonance is the mental discomfort (psychological stress) experienced by a person who simultaneously holds two or more contradictory beliefs, ideas, or values. The occurrence of cognitive dissonance is a consequence of a person performing an action that contradicts personal beliefs, ideals, and values; and also occurs when confronted with new information that contradicts said beliefs, ideals, and values.

In the fable of The Fox and the Grapes, by Aesop, on failing to reach the desired bunch of grapes, the fox then decides he does not truly want the fruit because it is sour. The fox’s act of rationalization (justification) reduced his anxiety about the cognitive dissonance occurred because of a desire he cannot realize.

Programming – perhaps more than any other profession – is an individual activity, depending on the abilities of the programmer himself, and not upon others. What difference can it make how many other programmers you run into during the day? If asked, most programmers would probably say they preferred to work alone in a place where they wouldn’t be disturbed by other people.

The ideas expressed in the preceding paragraph are possibly the most formidable barrier to improved programming that we shall encounter. First of all, if this is indeed the image generally held of the programming profession, then people will be attracted to, or repelled from, entering the profession according to their preference for working alone or working with others. Social psychologists tell us that there are different personality types – something we all knew, but which is nice to have stamped with authority. Among the general personality traits is one which is measured along three “dimensions” – whether a person is compliantaggressive or detached. The compliant type is characterized by the attitude of liking to work with people and be helpful. The aggressive type wants to earn money and prestige, and the detached type wants to be left to myself to be creative.

Now, every person contains a mixture of these attitudes, but most people lean more heavily in one direction than the others. There is no doubt that the majority of people in programming today lean in the “detached” direction, both by personal choice and because hiring policies for programmers are often directed toward finding such people. And to a great extent, this is a good choice, because a great deal of programming work is alone and creative.

Like most good things, however, the detachment of programmers is often overdeveloped. Although they are detached from people, they are attached to their programs. Indeed, their programs often become extensions of themselves – a fact which is verified in the abominable practice of attaching one’s name to the program itself. But even when the program is not officially blessed with the name of its creator, programmers know whose program it is.

Well, what is wrong with owning programs? Artists own paintings; authors own books; architects own buildings. Don’t these attributions lead to admiration and emulation of good workers by lesser ones? Isn’t it useful to have an author’s name on a book so we have a better idea of what to expect when we read it? And wouldn’t the same apply to programs? Perhaps it would – if people read programs, but we know they do not. Thus, the admiration of individual programmers cannot lead to an emulation of their work, but only to an affectation of their mannerisms. This is the same phenomenon we see in art colonies, where everyone knows how to look like an artist, but few, if any, know how to paint like one.

The real difficulty with property-oriented programming arises from another source. When we think a painting or a novel or a building is inferior, that is a matter of taste. When we think a program is inferior – in spite of the difficulties we know lurk behind the question of good programming – that is a matter at least potentially susceptible to object proof or hypothesis. At the very least, we can put the program on the machine and see what comes out.

An artist can dismiss the opinions of a critic if they do not please him, but can a programmer dismiss the judgment of the computer?

On the surface, it would seem that the judgment of the computer is indisputable, and if this were truly so, the attachment of a programmer to his programs would have serious consequences for his self-image. When the computer revealed a bug in his program, the programmer would have to reason something like this:

This program is defective. This program is part of me, an extension of myself, even carrying my name. I am defective.

But the very harshness of this self-judgment means that it is seldom carried out.

Starting with the work of the social psychologist Leon Festinger, a number of interesting experiments have been performed to establish the reality of a psychological phenomenon called “cognitive dissonance”. A classical experiment in cognitive dissonance goes something like this:

Writing an essay

Two groups of subjects are asked to write an essay arguing in favor of some point with which they feel strong disagreement. One group is paid $1 apiece to write this argument against their own opinions, the other is paid $20 apiece. At the end of the experiment, the subjects are re-tested on their opinions of the matter. Whereas common sense would say that the $20 subjects – having been paid more to change their minds – would be more likely to change their opinions. Cognitive dissonance theory predicts that it will be the other group which will change the most. Dozens of experiments have confirmed the predictions of the theory.

The argument behind cognitive dissonance theory is quite simple. In the experiment just outlined, both groups of subjects have had to perform an act – writing an essay against their own opinions which they would not like to do under normal circumstances.

Arguing for what one does not believe is classed as insincerity or hypocrisy neither of which is highly valued in our society. Therefore, a dissonance situation is created.

The subject’s self-image as a sincere person is challenged by the objective fact of his having written the essay.

Dissonance, according to the theory, is an uncomfortable and unstable state for human beings, and must therefore be quickly resolved in one way or another. To resolve a dissonance, one factor or another contributing to it must be made to yield. Which factor depends on the situation, but, generally speaking, it will not be the person’s self-image.

That manages to be preserved through the most miraculous arguments. Now, in the experiments cited, the $20 subjects have an easy resolution of their dissonance:

Of course, I didn’t really believe those arguments. I just did it for the money.

Although taking money to make such arguments is not altogether the most admirable trait, it is much better than actually holding the beliefs in question.

But look at the difficult situation of the dollar group. Even for poor college students – and subjects in psychological experiments are almost always poor college students – one dollar is not a significant amount of money. Thus, the argument of the other group does not carry the ring of conviction for them, and the dissonance must be resolved elsewhere. For many, at least, the easiest resolution is to come to admit that there is really something to the other side of the argument after all, so that writing the essay was not hypocrisy, but simply an exercise in developing a fair and honest mind, one which is capable of seeing both sides of a question.

Another application of the theory of cognitive dissonance predicts what will happen when people have made some large commitment, such as the purchase of a car. If a man who has just purchased a Ford is given a bunch of auto advertisements to read, he spends the majority of his time reading about Fords. It was a Chevrolet he purchased, then the Chevrolet ads capture his attention. This is an example of anticipating the possibility of dissonance and avoiding information that might create it. For if he has just purchased a Ford, he doesn’t want to find out that Chevrolet is the better car, and the best way to do that is to avoid reading the Chevrolet ads. In the Ford ads, he is not likely to find anything that will convince him that he is anything but the wisest of consumers.

Now, what cognitive dissonance has to do with our programming conflict should be vividly clear. A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct – even if this means the oversight of errors which are monstrous to another eye. All programmers are familiar with the symptoms of this dissonance resolution – in others, of course. The programmer comes down the hall with his output listing and it is very thin. If he is unable to conceal the failure of his run, he makes some remark such as:

It must be a hardware problem.


There must be something strange in your data.


I haven’t touched that code in weeks.

There are thousands of variations to these objections, if you are interested in finding more, check out devexcuses or programmingexcuses. But the one thing we never seem to here is a simple

I goofed again

Of course, where the error is more subtle than a complete failure to get output – which can hardly be ignored – the resolution of the dissonance can be made even simpler by merely failing to see that there is an error. And let there be no mistake about it: the human eye has an almost infinite capacity for not seeing what it does not want to see. People who have specialized in debugging other people’s programs can verify this assertion with literally thousands of cases.

The human eye has an almost infinite capacity for not seeing what it does not want to see.

Programmers, if left to their own devices, will ignore the most glaring errors in their output – errors that anyone else can see in an instant. Thus, if we are going to attack the problem of making good programs, and if we are going to start at the fundamental level of meeting specifications, we are going to have to do something about the perfectly normal human tendency to believe that ones “own” program is correct in the face of hard physical evidence to the contrary.

Image Credits:

Photo by Ián Tormo on Unsplash

Eight Corporate Laws of Gravity

Eight Corporate Laws of Gravity

Gravity is an unfair limitation on our freedom. After all, we had no say in the matter at all; we didn’t ask to be this heavy.

Gravity is a natural law, and we can’t repel it. Yet every day, people are making themselves miserable with futile struggles against the natural laws of business and human behavior. When you fight gravity, you’re apt to end with a busted head.

Every job has its gravity, its natural laws: divisions of loyalty, compromises, unfairness—the rules that won’t be changed, whether you like them or not.

We always have a choice about whether to act on them, but we have no choice about whether these urges exist.

Following are a few corporate laws of gravity about which the corporate universe says to you,

“You have two choices here: like ’em or lump ’em. That’s just the way things are.”

1. There ain’t no justice.

Fairness is a human construct; it doesn’t apply to the machinations of the gods or the company.

A fundamental rule of business is that the bottom line, rather than the moral or aesthetic value of a particular idea, will dictate corporate decisions. Companies are for profit, and even the not-for-profit companies are more and more required to be efficient. The first and often last question asked about any new idea or change is, How much will it cost? You need to realize this, have gravity on your side and be ready with an answer. Better yet, have some idea about how your proposed change will make money or save money over a period of time. You should be a firm believer in the long-term view and idea that good ethics make good business. It is still up to you to demonstrate your contentions are correct rather than expecting people to accept your ideas because they are right.

Opportunities go not to the most qualified but to the people who promote themselves the best and are in the right place at the right time.

This may be unfair, but it is definitely not accidental. If you want to get anywhere, you have to learn how to promote yourself and to keep looking for the right place and time. There will be a lot of people who don’t play by the rules, and absolutely nothing happens to them. Try as you might, you may not be able to motivate anybody to curtail his or her activities or see that anyone gets a well-deserved comeuppance. This presents you with a moral dilemma: Does the fact that somebody else got away with illegal or immoral behavior mean that you have the right to do it too? Does the lack of enforcement make it somehow less immoral?

2. Nothing ever happens the way it’s supposed to.

Count on the fact that your job will change. You will always have to do things that aren’t in your job description just to be allowed to do the things that are. All instructions that you will ever be given will leave out at least one or two crucial items. Many of the most important questions will never be answered.

3. People will not do what they should do.

The rules that you follow are not necessarily those that the universe follows. People will do what they are sufficiently rewarded to do. This is where virtue being its own reward comes in. Or they will do what is easiest. A corollary to this is, tasks that are not checked will not be done. Most people will leave most things until the last minute. If there is no time limit, then the task will await judgment day for completion.

4. People will consider their own feelings and best interests before they consider yours.

This is true even of close friends and family. Never assume malicious intent when ignorance is sufficient to explain. People will come to you for favors but will not be as ready to do favors for you when you come to them as you were to do favors for them when they came to you.

People will tell you their problems but will never be available to listen to yours. If you tell somebody at work something in confidence and it’s of any importance, it will get out. If you are abrasive and aggressive, nobody will ever come and tell you. That’s because they’re afraid of you. If you want to form an alliance, make a group cohesive or start a friendship, you will have to do all the work.

It will seem that you’re the one who always has to do all the phone calling, planning or grunt stuff. If you feel that way, it means you’re doing it right. If you’re on a committee, you’ll have to do most of the work, but you’ll have to divide the credit.

5. Wherever there are people, there will be politics.

That’s really what this book is about. The Dinosaur Brain thinking is the source of politics. You might as well know the rules because you will have to live by them.

6. There will never be time of smooth sailing.

As soon as one crisis is over, another will move in to take its place. Nature abhors a vacuum. There will never be a good, quiet time to make a change. If you’re waiting for all your work to be done before you take a vacation or do long- term planning, you’ll probably wait forever. This is the problem that workaholics have. It’s not, as popularly believed, that they like to work all the time; they’re just waiting until the work in front of them is done before they stop.

7. The government was not created to make your job easier or more efficient.

8. All the information will never be in.

You’ll never know in advance whether a decision is right or wrong. Most often you have to choose one of the roads and make it the right choice by your actions after the decision is made.

Image Credits

  • Photo by Claire Anderson on Unsplash
  • Photo by Simson Petrol on Unsplash
  • Photo by Mitch Lensink on Unsplash
  • Photo by Michael Henry on Unsplash
  • Photo by Jorge Alcala on Unsplash
  • Photo by Markus Spiske on Unsplash
  • Photo by Isai Ramos on Unsplash
  • Photo by Arnaud Mesureur on Unsplash
  • Photo by NASA on Unsplash

Why experience and intuition can ruin decision making?

Why experience and intuition can ruin decision making?

There is more than one way. There is always more than one way.

There is more than one way. There is always more than one way. This simple credo can be a practical beacon throughout our professional life, leading us to consider alternatives in how software might be organized and how people might be organized. But recognizing alternatives also carries a burden, the burden of making decisions. Developing better software means making choices among alternatives and, better still, finding that creative synthesis that integrates the best of several approaches and thereby exceeds them all. Well-organized teams that base decision making and problem solving on consensus have the best shot at making quality decisions and building such a creative synthesis, but they need to know how to avoid certain traps common to groups. The secrets of consensus-based teamwork are worth exploring.

The ability to make decisions to be one of the most essential of basic life skills. There is no way to learn how except by doing it!

The ability to make decisions to be one of the most essential of basic life skills. There is no way to learn how except by doing it, which means that successful families and companies make sure there is plenty of opportunity to practice the real thing. By mid-career, the typical professional programmer has solved countless problems and along the way has probably made many thousands of decisions. Naturally, we expect professionals to become good at it. But most of these decisions will have been made individually, by the programmer on her or his own, and problem solving and decision making in groups are different animals altogether.

Risks of Mediocrity

In the early ages, much study and concern were focused on supposed defects of group problem solving and decision making, particularly the effects of the so-called risky shift and the counter-tendency of groups to pull toward a mediocre mean. In those conservative days, even democratically minded managers worried more about the risky-shift than about creeping mediocrity.

According to the research, collective decisions often seemed to be skewed toward more risky alternatives than would be selected by members deciding independently. If this model applied to programming, we would expect groups to produce software that used more exotic data structures or more unconventional algorithms or more obscure language features. However, other research on group dynamics seemed to show that groups had a leveling effect on problem solving and decision making that reduced results to a kind of lowest common denominator of individual contributions and abilities. Either way, the lone decision maker seemed to have an edge.

Collective decisions often seemed to be skewed toward more risky alternatives than would be selected by members deciding independently.

The social and organizational climate in which a group works is what really shapes the ability to perform up to potential. For best results, the corporate culture and group leadership must actively encourage and support innovation and collaboration. In a sense, some teams did perform well, meeting the real expectations of bosses and enterprise policy makers, which were based more on covering the backside than achieving results.

Leading Lightly

In consensus design and decision making, the role of the group leader is crucial, not only in establishing the overall climate for collaboration but also in the detailed way in which leadership is exercised. Consensus design and decision making is at its best when the solution derives from the talents of all team members and reflects the experience, creativity, and critical thinking of all, not just an average of their contributions, but a genuine synthesis that combines their best. When group leaders, however talented and brilliant, push their own agenda, the quality of teamwork goes down. The effect of group leadership can be as insidious as it is subtle. Even just expressing an opinion at the wrong time can bias a group and lead to a poorer outcome. Research has shown that merely having leaders delay tossing in their own ideas until after all or most group members have presented theirs will improve the group solutions. That means that a leader who merely speaks too soon is probably degrading the quality of team-work. Confident leaders, sure that they are right or know best, may cause the most difficulty.

Consensus design and decision making is at its best when the solution derives from the talents of all team members and reflects the experience, creativity, and critical thinking of all.

Techies at heart

Most project leaders and mid-level managers in software development are really techies at heart. Nearly every one of them was promoted up from programming, systems analysis, and software engineering. They got where they are by being good at software development. For many, it is hard to let go of the keyboard, letting someone else actually do the work and make the technical choices.

Most of us as managers are prone to one particular failing: a tendency to manage people as though they were modular components. It’s obvious enough where this tendency comes from. Consider the preparation we had for the task of management: We were judged to be good management material because we performed well as doers, as technicians and developers. That often involved organizing our resources into modular pieces, such as software routines, circuits, or other units of work. The modules we constructed were made to exhibit a black-box characteristic, so that their internal idiosyncrasies could be safely ignored. They were designed to be used with a standard interface.

We were judged to be good management material because we performed well as doers, as technicians and developers.

After years of reliance on these modular methods, small wonder that as newly promoted managers, we try to manage our human resources the same way. Unfortunately, it doesn’t work very well.

The Discussion Leader

We now know that one of the most important factors in achieving first-rate problem solving through consensus is having neutral leadership. The position of discussion leader is so powerful that whoever leads or facilitates meetings and discussions must be assiduously neutral about the outcome in order that the best of what the group has to offer can emerge.

Such a leader is everyone’s friend and nobody’s advocate. Such a leader draws out the contributions of all without favoring any. Such a leader helps the group to build its own technical consensus without biasing the outcome or pushing a private agenda.

Ironically, what this means is that project managers and official team leaders are probably the worst choice for leading any discussions or meetings directed at technical problem solving and decision making. They have too much at stake. In a sense, they probably also know too much. The stronger they are as leaders, the more likely they are to actually dampen the free-spirited exploration of alternatives and the building of technical consensus that lead to the best results.

It’s a popular vision that leaders are diligent, thoughtful decision makers. They gather all the relevant facts, weigh them, and come up with the logical, rational decision. But in fact, that idealized process is basically never followed, even by expert, high-pressure decision makers.

Instead, we make decisions and solve problems based on faulty memory and our emotional state at the time, ignoring crucial facts and fixating on irrelevant details because of where and when they occur or whether they are brightly colored.

Some managers take a completely hands-off approach and try to stay out of the technical problem solving altogether; however, this is not ideal for their teams, who are deprived of the manager’s experience and expertise, or for the managers, who miss out on much of the fun. The best of them will turn over meetings and discussions to a neutral facilitator, then practice staying in the background, learning how to contribute without dominating. Some may never learn how to do this, but many actually enjoy being able to be “one of the bunch” again, taking part in technical discussions on equal footing with the rest of the team.


  • Peopleware by Larry Constantine
  • Peopleware by Tom DeMarco and Tim Lister
  • Pragmatic Learning & Thinking: Refactor Your Wetware by Andy Hunt

Image Credits

  • Photo by Caleb Jones on Unsplash
  • Photo by Clem Onojeghuo on Unsplash
  • Photo by Josh Calabrese on Unsplash
  • josh-calabrese-236920-unsplash
  • Photo by Dylan Gillis on Unsplash
  • Photo by rawpixel on Unsplash
Articles Javascript

A Refreshing Guide to Object.freeze in Javascript by Dr.Victor Fries

A Refreshing Guide to Object.freeze in Javascript by Dr.Victor Fries

What killed the dinosaurs? The Ice Age!

In JavaScript, objects are used to store keyed collections of various data and more complex entities. Objects penetrate almost every aspect of the JavaScript language.

The object might be accessed as global or passed as an argument. Functions that have access to the object can modify the object, whether intentionally or accidentally. To prevent modification of our objects, one of the techniques is to use Object.freeze().

Freezing an object can be useful for representing a logically immutable data structure, especially if changing the properties of the object could lead to bad behavior elsewhere in your application.

Allow me to break the ice: My name is Object.freeze(). Learn it well, for it’s the chilling sound of your doom.

The Object.freeze() method freezes an object: basically it prevents four things from an object:

The method returns the passed object.

Let’s kick some ice!

Tonight’s forecast… a freeze is coming!

Nothing can be added to or removed from the properties set of a frozen object. Any attempt to do so will fail, either silently or by throwing a TypeError exception (most commonly, but not exclusively, when in strict mode).

For data properties of a frozen object, values cannot be changed, the writable and configurable attributes are set to false. Accessor properties (getters and setters) work the same (and still give the illusion that you are changing the value). Note that values that are objects can still be modified, unless they are also frozen. As an object, an array can be frozen whereafter its elements cannot be altered. No elements can be added or removed from it as well.

The function returns the passed object. It does not create a frozen copy.

Tonight, hell freezes over! (Freezing Objects)

I’m putting array on ice (Freezing Arrays)

The object being frozen is immutable. However, it is not necessarily constant. The following example shows that a frozen object is not constant (freeze is shallow).

To be a constant object, the entire reference graph (direct and indirect references to other objects) must reference only immutable frozen objects. The object being frozen is said to be immutable because the entire object state (values and references to other objects) within the whole object is fixed. Note that strings, numbers, and booleans are always immutable and that Functions and Arrays are objects.

Freeze in hell, Batman! (The Shallow Freeze)

The result of calling Object.freeze(object) only applies to the immediate properties of objectitself and will prevent future property addition, removal or value re-assignment operations only on object. If the value of those properties are objects themselves, those objects are not frozen and may be the target of property addition, removal or value re-assignment operations.

Everything freezes! (The Deep Freeze)

In this universe, there’s only one absolute… everything freezes!

To make an object immutable, recursively freeze each property which is of type object (deep freeze). Use the pattern on a case-by-case basis based on your design when you know the object contains no cycles in the reference graph, otherwise an endless loop will be triggered. An enhancement to deepFreeze() would be to have an internal function that receives a path (e.g. an Array) argument so you can suppress calling deepFreeze() recursively when an object is in the process of being made immutable. You still run a risk of freezing an object that shouldn’t be frozen, such as window.

Object.freeze vs const

const and Object.freeze are two completely different things.

The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, solely that the variable identifier can not be reassigned.

const applies to bindings (“variables”). It creates an immutable binding, i.e. you cannot assign a new value to the binding. Object.freeze works on values, and more specifically, object values. It makes an object immutable, i.e. you cannot change its properties.

In ES5 Object.freeze doesn’t work on primitives, which would probably be more commonly declared using const than objects. You can freeze primitives in ES6, but then you also have support for const. On the other hand const used to declare objects doesn’t “freeze” them, you just can’t redeclare the whole object, but you can modify its keys freely. On the other hand you can redeclare frozen objects.

Object.freeze vs Object.seal

Objects sealed with Object.seal() can have their existing properties changed. Existing properties in objects frozen with Object.freeze() are made immutable.

The following related functions prevent the modification of object attributes.

Function Object is made non-extensible configurable is set to false for each property writable is set to false for each property
Object.preventExtensions Yes No No
Object.seal Yes Yes No
Object.freeze Yes Yes Yes

Winter has come at last

Yes! If I must suffer… Humanity will suffer with me! I shall repay them for sentencing me to a life without human comfort. I will blanket the city in endless winter! First… Gotham. And then… The world!

Hope, you enjoyed the article and learned something new about Object.freeze() in Javascript. Please show us your love by sharing the article and let us know your views in the comments.