The Silver Lining of Impostor Syndrome

[Let me start this piece with a caveat: This is not a #slatepitches-style article arguing that Impostor Syndrome is a good thing or that people with it are better off keeping it. It has profound negative effects and plays very neatly into the self-defeating internal narratives that major depression can give you. Depressives in particular don’t need another excuse to tell themselves they suck; most of us are really good at that already. Read this first if you need to learn about Impostor Syndrome, the harm it can do, and how to start overcoming it.]

At the last DCPHP meeting, Sean Prunka talked about Impostor Syndrome during his talk on dealing with distractions. At the end, I asked the group how many suffered from it, and the vast majority of hands went up. So clearly, a lot of the type of programmers who read blogs and go to user group meetings are the type who also think they’re a misstep away from being “found out” as not really deserving of the position/title/place they hold.

It got me thinking about why really good programmers paradoxically suffer from the feeling that they are the really crappy ones and have gotten where they are by sheer luck. Knowing that many programmers who give talks nonetheless feel like frauds gave me some new things to listen for, and I think I’ve distilled some good habits that shouldn’t go away with the crippling and unrealistic self-doubt as you fight these feelings within yourself.

There is some evidence that depressives perceive things (apart from themselves and their own worth) more clearly than those who don’t suffer from the disease. (The theory is called Depressive Realism.)  Similarly, self-doubt can give programmers some good habits of mind along with the bad habits that make it a problem. Here are some I think are related to my impostor syndrome:

Pessimistic estimation: If you assume you don’t know what you’re doing, you tend not to assume everything will go well as you attempt any task. In my case, it’s made me a better estimator, because I’m able to identify rosy assumptions and allow for the very real possibility that those assumptions will be wrong. It could be my memory of how much pain working with a given module causes and not assuming that this time it will be different. It could be assuming that the client won’t come through with the required design in time, and I won’t be able to just “make it happen” by the deadline. It could be realizing I haven’t completely mastered a given technology and using it will require research to address a specific problem. All of these things enable me to be a pretty good estimator because I naturally assume that things won’t just “go my way.”

Research first, coding second: With a nod to Donald Rumsfeld, Impostor Syndrome makes you keenly aware of the known unknowns as well as wary of the unknown unknowns. Being aware of the limitations of my knowledge encourages me to research a problem before tackling it. A common junior developer mistake is to take a half-understood requirement and immediately begin building a new framework to solve an entire class of problems like the one they’re given instead of simply searching to see that there’s an existing plugin that can solve the problem in minutes. Another frequent problem is assuming a component will solve your problem based on the general description without looking into the specifics of its implementation. Some of this is experience, but I’ve seen senior developers fall prey to cheery assumptions. Knowing I don’t know a new component inside and out makes me look into it more deeply before committing to using it to solve a problem.

Continuing education: One reason I suspect many hands went up in the room at a programming meetup was that we are a self-selected bunch. Those of us who don’t think we know everything are motivated to learn more. Even as you realize you’re a better programmer than you give yourself credit for, don’t lose the drive to chip away at your ignorance. Programming is as much of a craft as it is a science, and crafts take continual mastery.

Teaching and mentoring: Having felt adrift in a sea of acronyms and reading conversations where it felt like everybody in the room had singlehandedly built Facebook equivalents except me gives me a lot of empathy for the new or developing programmer. It’s really intimidating at first, and that’s one of the reasons I’ve become excited about what we do at php[architect] and what the community has done through its mentoring program. mojoLive was an attempt to encourage people to continually develop their skills, and I support PHP Women because they help lots of people deal with the learning curve and Impostor Syndrome. So my career has become as much about enabling other people to do great things. Perhaps self-doubt has kept me from tackling some of those problems, but it has given me the push to help others to develop their own career. I think feeling that dread at learning yet another technology has inspired many in the community to share their findings with others to spare them the pain. To Impostor Syndrome sufferers it can be more than just the pain of coaxing aging neurons to form new connections; it’s also the pain of “can I do this yet again or did I just get lucky last time?” each time we approach something new. That empathy helps push us to give a hand so the next person doesn’t suffer. We also appreciate those who have spared us the pain in the past.

That crippling self-doubt is more of a hindrance than a help, and Impostor Syndrome is something to be fought. But appreciating the good things it has driven me to do has helped me realize I have actually learned things along the way…and that I’m not an impostor at a programming conference.

You Don’t Know Your Requirements, Your Users Do

One mistake a lot of organizations get drawn into is focusing on the organization’s requirements on a website. No, really.

It seems like a strange sentiment, because why else would you build a website or application? The problem is that when you circulate requirements for the website, people focus on their own jobs and what would best represent how they think about their job. What they often don’t do is focus on the organization’s goals.

Your goals and your requirements aren’t synonymous by any means. Requirements are often just a wishlist of features collected piecemeal by people who take a moment to think about what they might want a website to do before going back to their main job.

The problem is, unless you’re building a site for use by your employees, they aren’t really the users of the site. The people the organization is trying to reach are the ultimate users of the site, and its their requirements that should drive the features of your website or application, not yours.

Instead, you should start with a list of your goals generally as an organization, and then the goals you have for the website. Those goals are the ones that usually triggered the decision to invest in a site or application in the first place, such as increased engagement with volunteers, reaching out to a broader base of smaller donors that aren’t feasible by traditional means, or convincing a key demographic that they should support a policy.

The goals for the website should logically support one or more goals of the organization. Goals are the “why”, and requirements are often the “how.” The tricky part is that each person in your organization also has a job that supports your organization’s goals. (Well, they should, right?) The tricky part is that the requirements they have to do their job better don’t usually map very well to what the ultimate users of your site will need to support your organization’s goals. So simply collecting their requirements and turning them into an RFP is a recipe for a site that makes everybody internally satisfied, but goes over with a big thud with the people you’re trying to reach.

This is another reason it’s a good idea to approach web developers with problems rather than solutions. The problem you have is that you have goals and you need to use the web to help you meet them. It’s the web developer’s job to help you figure out how to do that. Your staff should certainly be involved, but they have jobs of their own and shouldn’t be specifying your website for you.

This approach can also prevent some political problems, as specific requirements related to jobs can be conflicting, and wish lists are inevitably larger than budgets. Getting everybody’s input on goals and feedback on proposed solutions is easier than dealing with hurt feelings when a cherished feature doesn’t make the cut.

There are several techniques for getting to the heart of what users need, and they get to the heart of better ways to work with web developers. But by remembering the end users are the ones who hold the key to getting the right requirements for your site, you’ll set yourself up for success, and potentially avoid some internal conflicts.