Some Peace and Quiet

It's taken some time, but I've shrugged off much of my childhood shyness.  This change came in part from gaining experience--after all, confidence should follow competence--and in part from the fact that the older you get, the less you give a shit about what anyone thinks.  I had started to feel so at ease in social situations that I was beginning to think that I might actually be a closet extrovert, or perhaps an "ambivert."  That was until I took an introversion quiz.  After answering "yes" to every question ("People tell me that I'm a good listener"; "I enjoy solitude"; "I fear change"), there seems to be no doubt about it.

Hi, I'm Zach.  I'm an introvert.

Being introverted shouldn't feel like something you have to confess, but sometimes it does.  I could relate to the stories Susan Cain tells in her book Quiet and her TED talk, in which she felt shunned at camp if she picked up a book rather than socializing all the time.  She argues that our culture has an "extrovert ideal," where playing well with others is more valuable than having good ideas.  This is a problem because 1/3 to 1/2 of all people are introverts.


It's important to distinguish between shyness and introversion.  Shyness is anxiety.  Even extroverts can be shy--apparently Barbara Streisand is a shy extrovert.  Extroverts and introverts mainly differ in how they react to social stimuli.  Introverts tend to prefer deep conversations and then need time alone afterwards.  Extroverts are stimulated by being the center of attention.  This doesn't mean that introverts aren't social; they're just differently social.

How you recharge your batteries is important for how you should structure your work and personal life.  For example, I try to get to work early to have space to think without interruption.  After any highly social event, like company picnics, I reward myself with time to read or write.  Cain says introverts should have "restorative niches," such as jogs, couches, or bathroom stalls.

Cain rightly emphasizes that many leaders are introverts.  She points to Gandhi, Rosa Parks, and Bill Gates, as well as a study showing that extroverts are better at managing passive employees while introverts are better at managing people who are supposed to think for themselves.  Maybe we needed extrovert leaders in a world of salespeople and factory workers, but now, in a knowledge economy, we need introverts who can listen before they act.

Personally, I hope that we'll soon see the end of open office plans and "visionary" executives.  Why should I listen to anyone who isn't ready to listen to me?

Science and the Nature of Code

"I'll believe it when I see it." -- Ernst Mach

Being a programmer is a lot like being a scientist.

In any program of sufficient complexity--which is really any code that is in use--it quickly becomes impossible to understand it all.  Sure, you might grasp the big picture, but you can't predict how it will behave in every situation, or how it will work when refactored.  Code is always a bit of a mystery.

At the same time, code is reality.  It doesn't matter what people think a program does, what it was specified to do, what it was designed to do, or what it was proven to do.  What matters is what it actually does. 

Natural scientists come up with testable hypotheses that explain observable phenomena so that they can make accurate predictions about the future.  These hypotheses will be modified as a result of future experience.  This is the scientific method, and it doesn't apply to natural phenomena alone. 

Programmers typically start thinking scientifically when something is broken.  We observe something we have not observed before, come up with an explanation, test it, make modifications (to the code or environment), and test again.

Unlike the natural world, it may be easier to understand the essential nature of a program since you created it.  In fact, one of the first things we do when debugging is to look at the code.  Looking at code is not enough, however.  You have to actually see what it does.  The problem is that there is not enough time in the universe to exhaustively determine how code will behave.  Furthermore, test cases cover all the situations you can think of.  What about the ones nobody could think of?

For these reasons and more, we use QA environments.  This is our laboratory; it's the place where we test hypotheses.  Unfortunately, QA environments are never perfect.  Even if they are copies of production, they suffer from one fatal flaw: they aren't production.

Scientists face a very similar problem.  Since they can't see the source code, they can only rely on experimentation.  The problem is that their QA environment isn't the same as the real world either.  A large hadron collider, for example, creates highly contrived situations.

Drawing the analogy between natural scientists and programmers is useful for a few reasons.  First, taking the attitude of a scientist helps to distance ourselves from 'our' code.  It can be easy to get defensive about code we've written.  If you treat code as something to be understood, however, it suddenly has a life of its own.  It's not anyone's baby.  It just is.

Second, the analogy to science helps to highlight some of the ways we can respond to problems.  Some programmers start to theorize all kinds of possible explanations for an outage.  Was it neutrinos or was the firewall rewriting packet headers?  Others come up with more functional explanations.  What if we just restart the server?  These are both valid approaches, but they must both gather evidence in order to show that their hypotheses are valid.

These different approaches also show, third, we need laboratories where we can test hypotheses, no matter how wild.  That's why your QA environment should match your production environment as closely as possible, perhaps even down to the length of the network cables.  It's bad when problems are not caught in QA.  It's worse when you can't even explain why something works in one environment and not another.  Testing isn't just about proving that a solution meets its requirements; it's more generally about evaluating hypotheses.

Finally, I think it's important to think about the scientific method because many programmers are not good at thinking in this way.  It takes experience, and we tend not to get that kind of experience in schools--even science majors don't do much experimentation, unless mocking up lab results to match the Right Answer counts.  A computer science degree is basically a degree in abstract analysis, not too different from a mathematics degree.  In the real world, programmers need to flex their scientific muscles too.

How to Talk to Humans

I have a natural aversion to buzzwords like 'leadership,' but I've come to realize that it's just another word for 'problem-solving'.  In a recent training, I was taught that leadership is primarily about dealing with emotions, both yours and your co-workers.  After all, it's hard to solve problems if you can't work well with others, and this involves messy emotional stuff.

Thinking that my ability to deal with emotions might be due to being dead inside rather than being empathic, I decided to read How to Talk So Kids Will Listen and Listen So Kids Will Talk, another Jeff Atwood recommendation.  I don't even have kids, but this seemed like a better alternative to books like How to Win Friends and Influence People.

What's really great about HtTSKWL&LSKWT is that shows why it's so important to give recognition to the emotions people experience.  Imagine, the authors suggest, you have a bad day because your boss chews you out in front of your co-workers for not completing an assignment on time.  Later, you run into a friend and tell her what happened.  What are your reactions to her possible responses?

1. Denial of feelings:  "There's no reason to be upset.  It's not a big deal."
2. Philosophy:  "Shit happens.  Deal with it."
3. Advice:  "You know what you should do?  You go to your boss's office and tell her about it tomorrow."
4. Questions:  "What did you do to make her so mad?  Wasn't there some reason?"
5. Defense of the other person:  "I can understand why your boss would be so upset.  You're lucky you didn't get into more trouble."
6. Pity:  "Oh, that's so terrible.  I feel so sorry for you."
7. Amateur psychoanalysis:  "Bosses are stand-ins for parents.  You're not getting back at mommy by handing in your work late."

What these responses have in common is that they all deny the reality of an emotion.  They try to get past it.  But that reality is still there for the person feeling it.  When you deny an emotion, you deny a person's reality.

You'll probably agree that the only good response is something like the following.  It shows that your friend recognizes the emotion you're feeling.

8. Empathy:  "That must have been rough--to have been called out in front of all those people.  You must have been really upset!"

In order to provide an empathic response, you need to listen with attention, acknowledge the feeling, and give a name to the emotion.  Perhaps later, you can provide advice, but don't be too quick to do this.  If you start trying to problem-solve before you recognize someone's emotions, they will probably feel like you haven't listened to them.

Another important thing I realized when reading this book is that the emotion isn't the person.  No one wants to have negative emotions, but it can't be helped.  Emotions just happen.  I think of them as a separate entity entirely, or a different system from the well-reasoned, conscious person we all want to be.

Once I started trying to recognize other people's emotions, I noticed that they felt like I was listening better.  In fact, I was.  It's not just a bunch of psycho-babble, akin to 'I feel that you feel that I feel, etc.'  I actually started to empathize better with what others were feeling.  When you say, 'It must have been hard to be chewed out by your boss,' it's hard not to imagine how you'd feel in the same situation.  Moreover, I started being able to label my own emotions better.  I even once had an epiphany, 'Oh, I'm feeling stressed out!'

System 1 and System 2

Not this.

Everybody has two minds--one rational and one emotional.  (I didn't say two brains, so don't start thinking of that Steve Martin movie.)  Brains are physical systems, made of cells and fed by oxygen carried by blood.  Minds are decision-making systems.  We have two of them guiding our actions, often in contradictory ways.

Some people explain this idea by talking about the amygdala, which is part of the so-called 'lizard brain.'  The amygdala lights up on fMRI scans when people are put in emotionally-charged situations. But I think this ties us too much to the brain and raises questions about whether or not iguanas feel ennui.  It also makes 'lizard-like' behavior sound bad, when in fact it is essential.

Instead, I like Dan Kahneman's distinction between what he calls system 1 and system 2.

System 1 is fast, automatic, frequent, emotional, stereotypic, and subconscious 
System 2 is slow, effortful, infrequent, logical, calculating, and conscious

Everyone has done things that, given time for consideration, they wouldn't have done.  (Maybe just last night!)  The instinctual System 1 often trumps the ponderous System 2.  Casino owners and financial gurus, for example, play on the hopes and fears of System 1.  I know a guy who works at a casino and knows full well that you can't beat the dealer, yet he consistently blows his paycheck gambling.

So what are you supposed to do?  You might think we should try to squash System 1, but there are good reasons we evolved in this way.  We simply don't have time to think through every single choice we face.  We have to rely on habitual responses formed by experience and evolution.  If you're about to get hit by a bus when you're crossing the street, you want System 1 to make you to jump out of the way.  You can't estimate the bus's velocity, calculate the time to collision, and make an informed decision.  We are constantly faced with situations like this where we have to act quickly.

Like this.

Still, there are times when Systems 1 and 2 give us contradictory answers.  System 1 wants a new pair of shoes, but System 2 knows you can't afford it.  Kahneman goes at length to explain the kinds of biases System 1 has.  He hopes that, through understanding, System 2 can compensate for System 1's weaknesses.  But I am skeptical that we can do much to correct for System 1.  I know plenty of people who know they're behaving badly, such as by reacting extremely to any news, but they're incapable of acting any differently.  We're System 1 beings 90% of the time, after all.

I think it's easier to curb System 1 when you see other people acting in System-1-dominated ways.  For example, if a co-worker is flipping out about a client, don't feed into their response.  Reacting in kind will only escalate the situation.  Remember that their current actions are not their considered actions.

I often notice System 1 responses when people are asked to do things, especially at work.  The reaction might be either positive or negative, but neither is very helpful.  It's in my nature to say, "Sure, I can do that," without thinking about how or when I could.  I might not consider a deadline coming up, so I might leave someone hanging.  On the other hand, some people tend to say, "No, I have no time," also without thinking much about it.  They can't be busy until the end of time, but because they feel busy now, they respond negatively.  For this reason, I try to ask "Ok, when could you do that?" whether they say yes or no.  This question requires a System 2 response.

Now, obviously your brain is not divided into two parts, or any number of distinct entities, but the two-system tool is helpful.  At least, it helps me get along with other people a whole lot better.

(By the way, you might think it's odd that Kahneman could win a Nobel prize for such an obvious distinction, but economists got a little too enamored with System 2 in the mid 20th century.  Also, do not read Kahneman's ridiculously long book.  The distinction is not that hard to understand.  His NYT article is all you need.)

Learned Optimism

Trust me (I'm a doctor)--it's not a self-help book. I don't like anything that even smells like a self-help book. But I've been interested in psychology for a long time and recently heard of a relatively new strand called positive psychology. My psychologist friends tell me that its strongest proponent is Martin Seligman, a professor at the University of Pennsylvania who became famous for disproving strict behaviorism by showing that dogs could learn to be helpless. If dogs (and people) can learn to be helpless, why can't they learn to be healthy?

Positive psychology has three roots: 1) the unfortunate fact that most psychology focuses on deviance rather than prevention, 2) studies showing that how we think impacts our lives in many ways, and 3) therapeutic evidence proving we can change how we think, and for the better. In brief, Seligman and other positive psychologists want to fix how we think before we have problems.

According to Seligman, everyone understands events along three dimensions: how representative or pervasive they are, how permanent their effects will be, and how personally responsible we are for them. If something goes wrong for a total pessimist, he will say "Everything is going wrong for me. Things will never change. And it's all my fault." If something goes wrong for a total optimist, she will tell herself, "This one thing is bad right now. It won't always be like this. And many people and circumstances are at fault." Seligman has shown that optimistic people tend to be happier and more successful than pessimists. People prone to depression and people who are depressed tend to have pessimistic explanations of events.

Becoming more optimistic and avoiding depression involves learning how to argue with yourself. You have to interrupt the pessimistic explanatory patterns that may have become natural to you and use more optimistic ones. When you say to yourself, "It's all my fault; I'm a bad person," you catch yourself and say, "I'm just having a bad day" or "The person who yelled at me is just having a bad day."

This book was fascinating to me, because, as a card-carrying philosopher, I see the pessimistic explanations as bad reasoning. Pessimists use false generalizations to understand particular events. To look at one misfortune as representative of a supposedly failed life is simply a logical fallacy. Learning to be an optimist, then, is learning to be more rational.

However, optimists can fall prey to the exact same fallacy. When something good comes their way, they tell themselves, "My life is great. It will always be this way. And it's all my doing." This rose-colored vision has pitfalls of its own, and Seligman is careful to say that what we need above all is balance in our thinking. The pessimistic explanatory style should be used when you're thinking about something risky, like financial planning, career moves, or performing surgery on others. The optimistic style should be used for explaining everyday events, especially other people's behavior.

I think programmers tend to be optimists, since they are usually confident about their own abilities and quick to point to other causes when things don't go well. I often hear explanations like, "Our delivery is late because the customer changed the requirements," or "The code is terrible, but I didn't design it," or "It works on my machine--I can't imagine why it doesn't work anywhere else." It's easy to place the blame on the complex systems we collectively build, because, in the end, no one can really be said to be at fault. We can always be sure, however, that our code is good, since we complete projects and don't get fired much, as we're in high demand.

The problem with optimism is that confidence can breed arrogance and that systems-thinking can breed quiescence. Arrogance is a problem because it makes you hard to work with. It causes you to underestimate how long a project will take. It can also lead you to miss changes in the field. It's easy to coast for a while as a programmer, until you suddenly find that no one uses your technology of choice any longer. One way to fight arrogance is to force yourself to learn new technologies. You'll quickly realize how dumb you really are.

The main way to fight quiescence, unfortunately, is to change corporate culture. Google and other companies have experimented with giving programmers a fixed amount of time to do whatever they want. Programmers typically fix things that have been driving them crazy or build in-house tools to do what they do more easily. If you don't work at Google, you have to be the change you want to see. If you want to work on a system with good code and with people who take responsibility for it, take the initiative yourself. Programmers don't like to be shown up. Once one person starts, it will be hard for others not to join in.

Links:
-Take the Learned Optimism Test