Monthly Archives: September 2014

Psychology of Computer Programming: Conquering the Imposter Syndrome

Recently I came across a lot of posts about psychological problems related to computer programming. As I read them, I realized those were the same problems I had. The more I read, the more I searched for solutions. This post is a travelogue of my discoveries. Just to warn you, there are a lot of links in the text ahead, and you don’t need to click on every one to understand the text (beware of tab explosion). If you were to open any links at all, first I would recommend “How to make mistakes”, a short essay by Daniel Dennett.

The problem

Two things are going on that are literally driving programmers crazy. One is something known as the “imposter syndrome.” That’s when you’re pretty sure that all the other coders you work with are smarter, more talented and more skilled than you are. You live in fear that people will discover that you are really faking your smarts or skills or accomplishments. The trap of imposter’s syndrome is that programmers think they need to work harder to become good enough. That means spending more time coding — every waking minute — and taking on an increasing number of projects. That feeling is called the “Real Programmer” syndrome as named by a post that went crazy on Reddit last week. The Real Programmer lives only to code. – The Stress Of Being A Computer Programmer Is Literally Driving Many Of Them Crazy

He said: “Deep down know I’m ok. Programming since 13, graduated top of CS degree, got into Microsoft – but I feel like I’m an imposter.” I told him, straight up: You Are Not Alone. – I’m a phony. Are you?

From the outside, it would appear I was on the textbook path of programming. Started making websites at 15. Took programming and web design classes in my tech-oriented high school. Was accepted by my first choice school and majored in Computer Engineering. Had great internships at a tech giant. Wrote code that was used by millions of people. Graduated with distinction. Cofounded a software startup. And yet despite doing everything right, I didn’t think of myself as a good programmer. Impostor Syndrome instilled in me a deep fear of failing. I was afraid to speak up or ask questions for fear of saying something stupid, and people would find out I didn’t really know my stuff. – Overcoming Impostor Syndrome

Not long ago one of our programmers just lost it and he lost it good. He walked into the manager’s office and began screaming strange things. If I didn’t know him as well as I did I would have thought that he was on some kind of drug. But what had really happened was nothing short of a complete mental breakdown. – I Knew a Programmer that Went Completely Insane

What is a Real Programmer, you might ask? A Real Programmer is someone who loves programming! They love it so much that it’s what they spend all their time doing. In fact, a Real Programmer loves programming so much that they’re happy just to have the chance to do it. Paying them is just a formality because the Real Programmer doesn’t really consider it “work”. (…) It permeates the industry’s culture. You hear it from fellow programmers, managers, and investors. If you want to succeed as a programmer you have to at least look like a Real Programmer even if you’re not one at heart. So you get people working evenings and weekends just for appearances and they start to burnout. – IT Professional absolutely nails the “Real Programmer” mindset that is so pervasive in IT workplaces

Yet, like plenty of other fellow programmers, I feel completely worthless. It does not come a day where the impostor syndrome makes me feel that all I have managed to achieve is the result of simple luck. – I don’t want to be a Real Programmer

Branching out into other fields, having hobbies other than programming can be a tremendous benefit to your day job. You don’t need to burn a bazillion hours writing code. Burn that time writing, or reading, or arguing with someone over coffee (or your favorite scotch!). Burn that time running, or lifting, or both. Don’t burn yourself out to be a better programmer. Do what you love, and love many things. You will be better for it. – How to be a sane programmer

The type of thinking about the need to work long hours is dangerous because it is deceiving and can end up killing you. The drive for perfection is unfortunately a journey to insanity. Plain and simple, constantly tweaking something without delivering is a developer’s pit of despair. When I first arrived at New Relic I felt, like most do (at least that’s what I tell myself to help me sleep at night), that I was drinking from a fire-hose. I was intimidated by all of the amazing talent that is here, surrounded by experts in their fields, polyglots and so on. – Nerd Life Balance Part 2: Behaviors That Destroy the Balance

Solutions

(the next two sections are taken from Google I/O 2009 – The Myth of the Genius Programmer)

There is no genius programmer

“Can you guys please give Subversion on Google Code the ability to hide specific branches?” “Can you guys make it possible to create open source projects that start out hidden to the world, then get ‘revealed’ when they’re ready?” “Hi, I want to rewrite all my code from scratch, can you please wipe all the history?”

So what do these all have in common? There’s a lot of insecurity going on, right? This is a common feeling that we all have. We’re actually getting these responses last year at I/O. People were coming up to me and saying these sort of things. So it got us thinking “Well, what’s going on with psychology here? What’s going on in people’s heads? Why do they want to hide their code so much? What’s really at the bottom of this?”

“A pervasive elitism hovers in the background of collaborative software development: everyone secretly wants to be seen as a genius.”

This is rooted out of a general desire to not look stupid. Everybody, I think, wants to look like a smart developer. I know I certainly do, to some extent. There’s a lot of different reasons behind why people do this, and we’re going to start with something seemingly unrelated. Why do people buy products endorsed by celebrities? Michelle Obama wore this dress to the Inauguration. Boom, suddenly, it sold out. Michael Jordan wears Nike shoes. Everyone wants to buy Nikes because they love Jordan or basketball. What’s really going on here? Do you actually believe that if you buy Air Jordans, you are going to be as good as Michael Jordan? There’s some nugget of human psychology going on here, where it’s in our instinct to find celebrities, find people to idolize and want to be like those people, and we sort of latch on to whatever simple behaviors or materialistic pieces that remind us of this celebrity or this behavior. That’s true in the world of programming as well. We have Linus Torvalds, to some extent, Bill Gates even. Guido here at Google — you know, I mean, he wrote Python himself, right? Not quite true, you know? Did Linus write Linux all by himself? Right. We have Kernighan and Pike and Kernighan and Ritchie. I mean, these guys don’t always deserve all the credit. They certainly deserve some of the credit. They’re the leaders, or they started something, but they’re mythologized. So the personas that they become are bigger than life, and, to some extent, rooted in a little nugget of truth or fact and a whole lot of myth. When we say “the myth of the genius programmer,” we’re talking about the myth of, “Hey, here’s a genius, and genius goes off in a cave and writes this brilliant thing and then reveals it to the world and, oh, my gosh, this person’s famous forever.” Reality is, that’s not really how it works at all. There are in fact, geniuses… they are so incredibly rare that it’s almost a meaningless term. That myth just isn’t true. So, the ultimate geek fantasy is to go off into your cave and work and type in code and then shock the world with your brilliant new invention. It’s a desire to be seen as a genius by your peers. But there’s a flip side to that too. It’s not just about, “I want to be a genius and shock the world.” It’s also, “I’m insecure.” And what I mean by that is, “I also don’t want people to see my mistakes. “All right, maybe I won’t be a genius. Maybe I won’t shock the world with my brilliance, but at least I don’t want them to see my trail of failures and mistakes, and I’m gonna cover my tracks. They want to be seen as being clever. Clever people don’t make mistakes. Right, exactly. So the result is people wind up working in a cave. A classic example of this is: how long will you drive around before asking for directions? It’s hard to admit that you’ve made mistakes sometimes, especially publicly. So that’s why we showed these quotes in the beginning with people saying “Can you erase my history? Can you hide my project until it’s perfect?”

Fail fast

Think about the way you interact with your compiler. You have a really tight feedback. You write a function, you compile it, make sure it at least compiles. Maybe you write a UniTest if you’re doing great. But nobody sits down and writes thousands and thousands of lines of code and then runs their compiler for the first time. It just doesn’t happen.

I think a big issue also around failure is just natural human fear. You know, I can relate to this personally. I started learning banjo a few years ago, playing in bluegrass jams. And they would occasionally try to call on me to do banjo solos, which is really, really hard to learn, and I just wouldn’t do it. Someone took me aside and he said “You realize that 50% of learning to solo is just not caring how good you sound and just losing the fear.” It was totally true. I was like, “All right, these are my friends. If I sound terrible, who cares?” And sure enough he was absolutely right. I started playing really bad solos, but it got better and better, and I kept learning, and that was a huge step. So if you can just make that mental shift and say “It’s all right. I’m gonna fail, and it’s not a big deal.” No fear. That’s fine. You move on. You learn. Executive makes a bad business decision, and the company loses $10 million for the company. The next morning, comes into work. His secretary says “The CEO wants to see you in his office.” And the guy hangs his head down. He’s like “This is it. I’m gonna get fired.” Walks into the CEO’s office, and he’s like “So I guess you want my resignation.” The CEO looks at him and says, “Resignation? “I just spent $10 million training you. Why would I fire you?” I lived in Italy for three years. I moved there, and I had been studying Italian, and I was really proud to use my Italian. I went into a cafe, and I ordered a sandwich, and they give me this massive sandwich, and I wanted a knife to cut it with. So I thought I’d be cool and use my Italian, and I promptly asked them for a toothbrush to cut my sandwich. The guy just looked at me. And I’m like, “Toothbrush.” And he’s like, “No.” But I never made that mistake again. Speaking languages in a foreign country is very intimidating. You’re just so scared of looking like a fool, but you don’t learn otherwise. Well, it’s the easiest way to learn. That sort of hot-white fear you get going up your neck because you asked for something embarrassing. It’s not just about embracing failure, but it’s also failing fast. Iterating as quickly as we can. This is something we actually talk about a lot at Google, was don’t just fail, fail quickly and pick up and try something different as fast as you can. And that’s why we’ve got this Google Labs now where people are experimenting with different projects. And if they fail, that’s fine. They’ll just put something up or change it the next day and try it again. The faster you can fail and the faster you can iterate, the faster you will learn and get better. If you practice, it makes your iteration-failure cycle faster. And it’s less scary to fail, because you’ll tend to have smaller failures. This way, the failures tend to get smaller over time, and the successes tend to get larger, and that’s a trend you’ll see, especially if you’re learning as you fail fast.

(the next two sections are taken from EMF2012 – Programming is terrible)

False dichotomy of “good” and “bad” programmers

Many blogs claim to elcuidate a dichotomy of programmers – good and bad. Upon careful inspection, most of them turn out to actually dictate the following types:

A. Programmers who are like me.
B. Programmers who are not like me.

The assertion is that if you copy their personality (like a cargo cult), you too can be a successful programmer. Sometimes it is more veiled:

A. Programmers who use my favourite language
B. Programmers who do not use my favourite language

Or:

A. Programmers who share my political beliefs
B. Programmers who do not share my political beliefs

Why do we do this? It’s easy and gets blog hits. Everyone loves a simple answer to a complex problem. Especially when the two choices are emotionally charged. Better still, when the good programmers have magical super powers. You’ll hear terms like rockstar, ninja, founder, entrepreneur, all used in the same pre-pubecsent machoism that our industrying is drowning in. Unfortunately, it’s total bollocks. The ‘some programmers are crazily more productive than others’ comes from a study, on batch processing vs interactive programming, in 1960. On twelve people. In a half hour session. We’ve been repeating this myth endlessly. it’s destructive. it’s either repeated by idiots who believe they have nothing to learn from others, or repeated by learners to explain why they shouldn’t try to learn.

So, are there two types of programmers? Probably not, but if I was to try, i’d say:

A. Programmers who know they will make mistakes
B. Programmers who think they will not make mistakes

It’s OK to write ugly code

Write code as if it were mistaken, and you will have to change it, again and again. because you will. Fail fast and repeatedly. It is easier to get something right by getting wrong a couple of times. It is easier to get it wrong a couple of times if you don’t write so much code from the outset. Try and think a little more about how the code will be called than how it works. It is far easier to change implementation over interface. Don’t be an artist. Don’t labour over the ‘right’ way to do things, but don’t paint yourself into a corner. Write code that is easy to replace, rather than extend. Bear in mind: It is OK to write ugly code. As long as the things using it don’t have to write uglier code to use it. As you get further in programming, you will understand the biggest problems are social, not technical.

Mistakes are expected

The other day, I came to the conclusion that the act of writing software is actually antagonistic all on its own. Arcane languages, cryptic errors, mostly missing (or at best, scattered) documentation – it’s like someone is deliberately trying to screw with you, sitting in some Truman Show-like control room pointing and laughing behind the scenes. At some level, it’s masochistic, but we do it because it gives us an incredible opportunity to shape our world.

How to Make Mistakes

Making mistakes is the key to making progress. There are times, of course, when it is important not to make any mistakes–ask any surgeon or airline pilot. But it is less widely appreciated that there are also times when making mistakes is the secret of success. What I have in mind is not just the familiar wisdom of nothing ventured, nothing gained. While that maxim encourages a healthy attitude towards risk, it doesn’t point to the positive benefits of not just risking mistakes, but actually of making them. Instead of shunning mistakes, I claim, you should cultivate the habit of making them. Instead of turning away in denial when you make a mistake, you should become a connoisseur of your own mistakes, turning them over in your mind as if they were works of art, which in a way they are. You should seek out opportunities to make grand mistakes, just so you can then recover from them.

There are no things every developer needs to know

For example, take this: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) Yes, but what about those developers who don’t need to know a thing about character sets, like people who do numerical analysis, machine learning, or work with graphics, or work in a hundred other areas which don’t deal with character sets? It’s better to know something about unicode than not to know, but it simply is not the case every developer needs to know about unicode. The real reason people write title’s like that is because they generate traffic. There are generally two reasons to learn something: either it’s useful to you for the problem you are solving right now, or you are interested in it just for the sake of it. The problem with learning for any other reason is: the brain forgets things. If you are learning a thing with an idea “maybe I will need this someday” the probability you are going to forget it is high. Then, I hear a lot of talk about functional programming, vi, emacs, arch linux, etc. There’s also a theory that says knowing functional programming is going to make you a better programmer. It’s not clear if that theory is true, and evidence in favor of it is purely anecdotal. It may be the case that better programmers are more drawn to learning about functional programming (so, in technical language: it’s just selection bias and signalling) At least for me, learning functional programming did not make me a better programmer. Learning how to fail fast – did.

Perfectionism will kill you

If you are having problems with perfectionism, ask yourself the following:

  1. Is this really important or not? How important will it be in a year? In ten years? If it’s not that important, dont’ act like it is – because it’s not. Perfectionism is a tendency to overcommit, when what you really should be doing is optimizing the level of your commitment.
  2. Is there anything good in work that’s not done perfectly? Most things can’t be divided into absolute categories. For example, is the floor of your room perfectly clean? It’s not, there is always a degree of cleanliness, and the threshold for cleaning your room is not “zero dust”, if it were, then you would be cleaning your room all the time. What is the threshold after which the thing you are working on is good enough? Do not maximize in situations in which you should satisfice. It’s important to know the difference.
  3. Is perfectionism something which could be achieved? Let’s say someone offers you a bet: they’ll pay you 10 dollars if the six-sided dice rolls anything but 6, and you will pay them 10 dollars if it rolls a 6. And you lose. Does it make any sense to say “I shouldn’t have played that game”. Well, technically, you should have – it was the best decision to make with limited information you had, you didn’t know the future. In the same sense, a lottery player who, after seeing the winning combination, says “I should have played that combination” is wrong – in fact, he shouldn’t have played the lottery at all because expected gains are negative. There is no sense in saying the result should be better than it is if that would imply you being omniscient and omnipotent.

Inaction hurts more than action

Consider this scenario.You own shares in Company A. During the past year you considered switching to stock in Company B but decided against it. You now find that you would have been better off by $1200 if you had switched to the stock of Company B. You also owned shares in Company C. During the past year you switched to stock in Company D. You now find out that you’d have been better off by $1200 if you kept your stock in Company C.Which error causes you more regret? Studies show that about nine out of ten people expect to feel more regret when they foolishly switch stocks than when they foolishly fail to switch stocks, because most people think they will regret foolish actions more than foolish inactions. But studies also show that nineout of ten people are wrong. Indeed, in the long run, people of every age and in every walk of life seem to regret not having done things much more than they regret things they did, which is why the most popular regrets include not going to college, not grasping profitable business opportunities, and not spending enough time with family and friends. – Daniel Gilbert, Stumbling on Happiness

Learning how to program

This is one of those things that I always try to communicate, especially to students who are just starting out in computer science is that software, even though it’s fun to write code alone, you know, late at night in your basement, whatever, actually writing software that’s successful– it’s an inherently collaborative activity. And it actually forces you to deal with people and talk with people, and that’s why we encourage people to get involved in Open Source, because it’s sort of like, “Okay, well, maybe you’re still in college, but here’s your chance to actually work with people and work on a team and see what it’s gonna be like. I mean, one of the things I always ask people is, “Can you name a piece of software “that’s really successful, “really widely used by a lot of people, and was written by one person?” Fitzpatrick: And before anybody yells out Metafont, that’s not widely used, okay? But anyway, so this is a trap, okay? Of this sort of wanting to be a genius. – Ben Collins-Sussman

Some useful links you can go to (but you don’t need to, as indeed I didn’t use them all, it’s just a list my friends and I came up with):

“We now know a thousand ways not to build a light bulb” – Thomas Edison

“An expert is a man who has made all the mistakes which can be made, in a narrow field.” – Niels Bohr

Advertisements