REALLY Caring for Your Introvert

Joel Spolsky

After rereading my last post, I realized that it didn’t really paint introverts in the best light. It makes introverts seem selfish. That’s actually a good thing because that’s how introversion tends to look to extraverts. But that’s not really accurate.

Here’s the funny thing about personality: disputes tend to happen between people when they have opposite ways to do the same thing. Whereas extraverts respect people by integrating their thoughts into the whole, introverts respect people by leaving them alone. They view trying to merge peoples’ thoughts into one big whole as an attempt to “water them down”. Thus, introverts will constantly try to differentiate themselves from the common point of view.

That said, introverts would do well to heed Derek Sivers’s advice that sometimes Persistence is Polite. People aren’t usually as put off by an introvert’s “intrusion” as they imagine them to be.

Thus far, I’ve only focused on applying the concept of introversion and extraversion to how we make decisions. But they also affect perception.

Let’s look at Joel Spolsky. If you look at Spolsky’s famous “Don’t rewrite your software” blog post, you can see that Joel is obviously extraverted when it comes to making decisions. It might be easier to see this if you realize that psychologists refer to extraverted attitudes as “objective” and introverted ones as “subjective”. In other words, extraverts tend to look for the “one true” plan or way of seeing things while introverts will be focused on trying to find a plan or truth that works for them. You can see Spolsky’s extraversion in decision-making when he says things like:

They did it by making the single worst strategic mistake that any software company can make

out site or

The old mantra build one to throw away is dangerous when applied to large scale commercial applications.


But throwing away the whole program is a dangerous folly

Heck, even the title of the blog post (“Things you should never do”) is extraverted. These are all couched in very logical language, but taken together you can see an overarching theme: “There’s one true way to write software, and the only way to figure it out is for everyone to add their little piece of the truth. Here’s mine.”

However if you look, it’s clear that Spolsky also has an introverted side. Consider the following phrases:

The reason is that they think the old code is a mess.


The consensus seems to be that the old Netscape code base was really bad. Well, it might have been bad, but, you know what? It worked pretty darn well on an awful lot of real world computer systems.


“Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.”

You can see that Spolsky has an introverted way of perceiving the world that complements his extraverted decision-making. The hallmark of the introverted attitude is the desire to separate oneself from others. The overarching theme of these phrases is “they see the world like this, but I see the world like this”, which is introverted. That the others are wrong is just a side effect.

Again, even though I’ve pointed out Spolsky’s introverted side and extraverted side, remember that this is still oversimplified. I’ve pointed out what I see as his primary ways of looking at things, but you can see others in the rest of his text.

So how can an extravert get along with an introvert?

  1. Agree to disagree. Extraverts tend to dislike ending a conversation without everyone coming to a consensus. Unless the matter is completely trivial, introverts dislike ending a conversation without having differentiated themselves from the other person somehow. If possible, try to find a happy medium. End the conversation by pointing out things you both agree on (carefully: make sure to couch this with phrases like “It sounds to me like you agree with me on x, y, and z”), but acknowledge that there are areas where you both disagree and that’s ok.
  2. Realize that when an introvert is quiet, that doesn’t mean they don’t respect you. If you need feedback from them, try to do so in a way that is respectful to them. For instance, say something like “Hey, whenever you have a moment can we discuss x?”
  3. Don’t go too far in accepting their worldview. Some people (both introverted and extraverted) might try to take advantage of your desire to connect with other people. Always be skeptical of someone whose judgement of you is dependent upon you giving them (or not giving them) something they want.

The Rolling Stones were wrong

The people that I work with must sometimes see me as selfish. And who can blame them? If an idea doesn’t excite me, I’m not on board with it. Don’t get me wrong. I understand that sometimes you have to do things you don’t want to do. And when one of those moments hits you, you just have to roll up your sleeves and do what needs to be done.

…but it’s surprising how rare those moments really are. I mean really, which do you find yourself saying more:

  1. “Man. I really want X, but I just can’t do that. There simply isn’t any way to avoid doing Y instead.”
  2. “I really need to get X done, but I keep procrastinating. I need to get my act together.”

buy it Judging by my highly scientific approach of recalling blog postings I’ve seen in the recent past and comments I’ve seen on Hacker News, I’d say that problem #2 is the far more prevalent problem. Now sometimes you do run into a situation where you have to deal with something bad to get something that overrides that badness. But at the end of the day, I don’t run into many moments where I just have to do something I don’t want to do. It just doesn’t happen that often.

Some of you probably still see this attitude as selfish, but I don’t think it is. You do need to focus on others in addition to yourself. But happiness isn’t a zero-sum game. Happiness is more like an infectious disease. A person who is excited will also make others excited. They’ll be giving their team their all. Likewise, a person who just isn’t happy can drag others down.

But in either situation, how often do you run into a person who is successful at something they’re not happy doing?

How to come up with good abstractions

The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. -Dijkstra

Abstraction is something that every programmer uses, but few appreciate. In fact, there’s an architecture antipattern that discusses this. You can agree or disagree with the idea that 1 in 5 programmers understand abstraction, but it is my experience that few developers truly appreciate abstraction and can make good use of it. This is somewhat sad. While abstraction comes naturally to few programmers, it is something that every programmer can learn with some amount of effort.

So with that said, here are my (sometimes conflicting) guidelines for coming up with good abstractions.

  1. Trust your gut. Abstraction is more of an art than a science. If there were an objective, scientific method of coming up with good abstractions, programming would be a lot easier. Therefore, you need to forget everything your professors told you about not trusting your intuition. The goal of any abstraction is to make something easier to understand. Guess what abstractions are easiest to understand? The ones that are the most intuitive. Of these guidelines, this is the most important. When you’re in a situation where two guidelines conflict go with your first instinct.
  2. All abstractions leak. It’s worth reading Joel’s piece on leaky abstractions. This is an important thing to keep in mind. The most beautiful abstractions are the ones that are successful in spite of this. Unix is full of good examples. For instance, is anyone really naive enough to be convinced that everything really can be treated exactly the same as an honest-to-god file that resides on the hard disk? Sure, everything has the same interface as a file. But in all but the most trivial of cases, you’re going to need to know what the underlying thing you’re interfacing with is. For instance, with a socket, you may need to worry about if the socket is half-closed, totally closed, or open. If it’s a pipe, you need to realize that something on the other end might close the connection. And yet in spite of the leakiness, the “everything is a file” abstraction is probably the most important thing Unix ever did.
  3. Don’t trust black boxes. Whether it’s your abstraction or someone else’s, there’s a real danger of thinking of something as a magical black box that doesn’t need to be understood. This is dangerous because of guideline #2. When something doesn’t work right, you want to be prepared.
  4. …but don’t be too transparent. Of course, there’s a danger of going too far in the opposite direction. A completely transparent abstraction is useless; it’s not really an abstraction. A good abstraction should be translucent. You shouldn’t have to know all of the details all the time, but you should be able to figure them out easily.
  5. Elegance before comprehensiveness. Since we’ve already established in #2 that no abstraction works in all circumstances, you should abandon the idea of an all-encompassing abstraction. It’s better to have a small set of abstractions upon which higher-level abstractions can be built than to try and come up with one all-encompassing layer of abstraction.
  6. Abstraction doesn’t make your code simpler. Many peoples’ complaint against abstraction is that it makes your code more complex. In fact, they’re often correct. When you have the choice between abstraction and simplicity, always choose simplicity. Unfortunately simplicity isn’t always an option. Think of it this way: if you become sick, would you rather take medication that will cure the disease or treat the symptoms? Obviously, we’d rather make the disease go away if at all possible. But not all diseases are curable. In this case, the only thing you can do is treat the symptoms. This is essentially what abstractions do. They don’t make complex code simple. They do make complex code easier to wrap your head around though.

In the end, I can come up with nifty guidelines like this all day. But in the end, it’s most important to remember rule #1: trust your gut. Chances are that you’ll be better off than if you followed a checklist of guidelines.

What are some good abstractions that follow these guidelines? What are some that break them?

Choosing sides

Because you don’t need to own the universe. Just see it.  To have the privilege of seeing the whole of time and space… that’s ownership enough. -The 10th doctor

Very few quotes have summarized the fundamental differences between the left brain and the right brain as succinctly as the above quote. And yet, even though the difference can be summarized pretty nicely in a few sentences, there are a lot of misconceptions about the differences between the left brain and the right brain. The thing that makes these misconceptions so hard to break is that they’re just like most other forms of pop psychology: just accurate enough to be tricky.

Google would be jealous

Before I can get into those misconceptions (and what reality is), there’s something you need to understand about the brain. We tend to think of the brain as a biological microprocessor, but that’s not quite accurate. You see, a microprocessor has pre-defined subsystems with very well-defined tasks. The brain is much more sophisticated than that. A better analogy is to think of the brain as a biological cluster of computers (or probably more accurately, a biological cloud). Although you do have subclusters that handle specific segments of functionality, there’s no reason why they have to be dedicated to that task.

As it turns out, the brain is amazingly adaptable. In fact, your brain can and does spread tasks out to parts that we don’t generally associate with handling those tasks.

If it sounds like your brain is chaotic, it’s because it is. The different parts can even work at odds with each other some times. To deal with this, your ego tends to favor certain parts of the brain more than others. Generally, you favor a specific hemisphere over the other. In fact, you even favor a specific portion of a specific hemisphere. But that’s the subject of another blog post.

The left brain is logical, the right brain is creative

As it turns out, the information that I gave in the last section was quite a revelation to neurologists within the last couple of decades. Up until that point in time, they thought that the brain had a strict division of labor. It was thought that the left part of the brain handled logic while the right part of the brain was creative. If you wanted to be more creative, you needed to develop the right brain. If you want to be more logical, you need to develop the left brain. As a right-brained thinker, I’m living proof that the right brain is every bit as capable of logic as the left brain. It just tends to be a different kind of logic.

As it turns out, the two hemispheres can do mostly the same things. In fact, what we refer to as the “left brain” might not physically even be the left hemisphere (if you’re a lefty, there’s about a 70% chance of this!). The point is, there isn’t any reason why the left brain can’t do the things the right brain does and vice versa. However, these two hemispheres do tend to “specialize”. See, the brain is capable of rewiring itself. This is part of the process of learning. As one hemisphere does one task, it rewires itself so it can do that task better in the future. Thus, you do see differences emerge between the two hemispheres. These differences are developmental rather than biological though.

So what IS the difference?

If you’ve ever taken a personality test, you got back a four-letter code ending in J (for judging) or P (for perceiving). Most of the ideas that these tests are based on come from CG Jung. Jung said that judgers like to plan ahead of time and perceivers dislike to have their future mapped out ahead of time. The technology didn’t exist at the time for Jung to realize this, but he was essentially describing the difference between the left brain and the right brain (albeit with a somewhat primitive understanding).

Let’s go back to the Doctor Who quote I presented at the beginning of this post. In this scene, the Doctor (a perceiver) was talking to the Master (a judger). You see, the Master had a goal: complete domination of the universe. The Doctor never really has any explicit goals that he sets ahead of time. He sort of just bumbles around the universe until he runs into trouble. This illustrates the major differences between the left and right brain, but there are still others.

The forest or the trees?

Left-brained thinkers think very linearly. They tend to divide the topics up into individual parts and consider them one by one before considering the big picture. They may be seen as “not being able to see the forest for the trees”, but that isn’t strictly true. It’s more that they just haven’t moved from considering the parts to considering the whole.

Right-brainers might be seen as being “big-picture” oriented, but this isn’t necessarily true either. Distinguishing parts from the whole is a distinctly left-brained way of thinking. The right brain is probably better thought of as being “whole-picture” oriented. While right-brained people might start from the standpoint of the overall picture, you’ll notice that there are certain details that they just won’t let go of.

Experience vs instruction

Left-brained thinkers tend to do very well in school as our educational model is very much aligned with how they think. The model of listening to a lecture and reading an assignment fits very well into their mode of thinking. Left-brainers don’t really need experience to go about their tasks. But they do need instruction. They can follow instructions very well, but they don’t do very well when instructions are poorly defined or when the situation changes in such a way those instructions didn’t anticipate.

Right-brained thinkers do need experience. Until they’ve actually tried something once or twice, they have no frame of reference no matter how much instruction they get. In fact, they will usually feel as though instructions are boxing them in and limiting their options. However, (much to the chagrin of their left-brained counterparts) they are good at improvisation. They’re good at reacting quickly when plans become inadequate.


There’s a lot more to be said on this subject, but hopefully this should be a good outline of the differences between the left brain and the right brain.

Heroes and Villians, or electrons and duct tape don’t mix

One of Carl Jung’s great contributions to the field of psychology is the idea of the archetype.  There is a boatload of psychology books on this subject out there if you have a lot of free time to spend deciphering psychological jargon or just happen to also have a PhD in psychology (in which case this blog post wouldn’t be useful to you anyway).  Here’s the thing though:  you already know what an archetype is.  You just haven’t put a name to it.

Think of the characters that are in every story.  There’s always a hero and a villain.  They also have a supporting cast of other characters.  You have the parent (metaphorically speaking – they don’t have to be someone’s actual parent), a good natured mentor who protects people (think Obi-Wan from Star Wars).  Then there’s the senex:  the wise man who treats his proteges like crap because that’s the only way to learn (think of the sensei in any martial arts movie).  You’ve also got the Puer, the good natured, innocent child-like character (just about every role Adam Sandler plays).  And there’s also the trickster:  the child-like character who causes trouble (Kevin from Home Alone). These are all archetypes.

Not only do we see these characters in fiction, but we also see them in real life too.  Here’s where things get interesting though.  We all share these archetypes, but we put different people in each role. Your hero might be my senex.   Your puer might be my villain.

The reason?  We place people in the role of these archetypes based on ourselves, not other people.  You might feel that a part of your personality is particularly child-like and associate it with the puer when you see it in other people.  Seeing through this illusion can be difficult.  However, it’s usually very liberating to see through this.  While others are always looking for heroes and villains and such, you get a chance to see people as they actually are.

It’s no coincidence that each of these archetypes has a “good” and “bad” version, either.  The “good” version is usually more conscious. The “bad” version usually comes from the unconscious.

It might be easiest to see this with an example. Compare Joel Spolsky’s blog post about Duct Tape programmers to Michael Lopp’s essay on Free Electron programmers.

Ostensibly, these programmers are both really productive. But the similarity ends there. Spolsky’s Duct Tape programmer is someone who doesn’t go with the latest fad. They’d rather just get things done than spend their time worrying about what’s fashionable. They also don’t spend too much time worrying about making their code perfect because they want to ship. Lopp’s Free Electron programmer on the other hand “defines the bleeding edge”. They can get things done, but you have to be careful. They’ll rewrite your database layer from scratch for that .1 release.

What’s most interesting is that they both refer to the same person (unless Lopp means someone else when he mentions Netscape’s Free Electron — UPDATE: apparently he did, jwz claims to not be able to ride a unicycle). Now Lopp actually worked with Zawinski so his version might be more accurate, but I suspect that both are projecting themselves onto him at some level.

In other words, these kinds of writings tell us more about the author than they tell us about what makes a programmer good. This is what we do when we talk about our Hero: emphasize its strengths while we gloss over its weaknesses. This makes sense if you realize that the Hero essentially represents our ego. Any attack to the Hero is an attack on the ego.