Tuesday, October 11, 2016

It's Not Impostor Syndrome If You Really Do Suck

I.

So you've just graduated from college / gotten a great internship / gotten your resume in good shape and practiced interviewing, and you got the job. Congratulations: you're a junior programmer! Welcome to one of the world's best value-for-money professions, with relatively low stress and high pay. You feel tremendous relief that you've finally passed the bar.

But a few months into your new job, something's not quite right.

You're spending a lot of your time on things that seem unimportant. Often it feels like you're banging your head against the wall. You have an assignment—it seemed very important and interesting when your boss explained it to you—but you seem to be stuck in a maze of twisty little passages all alike, not making much progress.

You're isolated. You're not talking to anyone about your work. You don't really want to talk to anyone about your work, and as days pass, you want to less and less. Why? If you talk to someone about your work, they'll realize you've been banging your head against the wall for weeks. They'll know.

For now, though, it's enough to make you miserable that you know: You're not getting anything done. Your goals don't make sense to you, you're not sure what direction to go in, and you don't really have the power to move the project in any particular direction. You get a few things done each day, but feel demoralized by their sparsity and their insignificance. And the longer this goes on, the less you want to ask for help or input of any kind.

What happened?



II.

Some people call this a symptom of impostor syndrome. I don't think so. To call it "impostor syndrome" implies that it arises out of a mistaken belief, when, in truth, it's not mistaken. You're not wrong to think that you're not getting things done, and that you're not very good at your job. Of course you're not—yet! You're very new to it, and being good at your job involves plenty of soft skills you didn't pick up before your first (or perhaps second, or even third) professional programming job.

For another thing, this isn't all because of you, either: Your supervisor isn't prompting you to ask questions, and isn't bothering to get more detail from you on what's going well and what isn't. They're not making sure you're not blocked, or spinning your wheels.

The trouble arises when you get into a cycle: you feel bad about not knowing what to do next, so you don't ask for help, so you try to do everything yourself; you don't have a lot of success, so you still feel bad and don't want to ask for help; next thing you know, it's been a month and you haven't spoken to another human being, except to tell your boss "Things are going okay," with a glossed-over description of your progress so far.

This is not healthy.



III.

So what can you do about it?

The number one thing to do is to ask questions, despite how you may feel about it. Let me repeat that. Ask questions. Ask questions. ASK QUESTIONS.

"But then they'll know!"


Yes. The sooner they know it, the better. The longer you wait, the dumber you'll seem.

It's best to get any misunderstandings and questions you have cleared up the moment you have them. When you're new to the team, you have more leeway: People understand that you just got here, and you may not know everything about How Things Are Done Around Here. And if you ask a question as soon as it occurs to you, with the backstory of how you encountered this problem readily available, it's a lot less weird than if you sit on it for a week first.

Most organizations have a lot of lore and useful information that's fallen through the cracks of documentation, but that someone down the hall will know about if you go and ask them in person. This is why it's vital not to rely solely on your organization's documentation (though, of course, you should do your best to inscribe any lore you find for the next hapless soul on the same journey). You will have to go asking around sometime, so you may as well get started now.

Moreover, you need to get used to asking questions that sound dumb. The faster you do this, the better you become. Over the long run, it's much better to be right than look right. Other people are pretty sensitive to what's actually true, and they'll notice when you're getting more done because of the knowledge you've gained asking questions.1

"But I don't want to waste my manager's / a very important engineer's time!"

Okay. Fine. Here's the rule, then: Spend fifteen minutes trying to solve it on your own, and if you're still stuck, go ask someone. Two days of you banging your head against the wall is not better than you using five minutes of a more senior person's time.

For that matter, how do you think they got to be so senior? Solving problems for numskulls like you in 5 minutes, that's how. Making you more effective is their job.

You'll get better at triaging what's probably in the docs and what you probably need to ask about later on. For right now, you need to bail water out of your sinking ship by asking all the questions that occur to you.



IV.

What if you encounter resistance?

You ask questions in the team chat, but no one seems to be paying attention. You email someone to ask a question, and they take a week to get back to you with a cryptic answer. You try to schedule meetings, to no avail.

What to do next depends on your situation.

1. No one is interested or has the time to answer your questions. This is a bad sign, but you have a few options before calling it quits.

First, talk to your boss. (Remember, making sure you have the resources you need is their job.) "Hey Boss, I'm having trouble getting my questions answered about X. Can you help me get some time from <PERSON> to talk about it?" Or: "Hey Boss, no one is responding on the team chat. Is there a better way for me to get in touch with people?" Or if you're desperate: "Hey Boss, I'm really not sure how to proceed with <PROJECT>. I tried to get in touch with <PERSON> but they never answered. What do you think I should do next?"

It's possible your boss will say one of the following unpromising things:
  • "<PERSON> doesn't know about X. You'll have to do the research on your own for this one." In this case, see option 2 below.
  • "I don't think <PERSON> has the time to talk to you about X. You'll need to go it alone." In this case, technically you're only as stuck as you are in option 2, but I'd still advise going on to "Giving up," below. Why? Because an organization where people don't have time to help each other is going to be a very hard place for you to grow. If your manager can't provide you with the support you need, get a different manager. They're not holding up their end of the deal.
In the ideal case, your boss will say something like:
  • "Of course, I'll email them and CC you."
  • "Let me work on finding the resources you need." (Followed by swift and decisive action.)
  • "I don't think you need to do the thing you're asking about. How about you move on to Y instead?"
  • "Here's some documentation and resources on that. Let me know if you have any questions; I'm happy to help."
  • Literally the explanations or answers that you need, directly.

2. There just isn't anyone around who knows how to answer your questions. This can happen if you're working on a research-like project, or if people who know the answers have left the company.

At this point, if you are spending a lot of time banging your head against the wall or making very slow progress towards your goal, I would advise you to seriously consider giving up and doing something else.

This is probably why I'm not getting a Ph.D.—I understand research involves a lot of this. You must consider whether the particular problem you're working on seems worth the pain of forging an entirely new path.

If it does seem worth it to you, there are a few strategies that might help:
  • Seek out a sounding board or other people to work with and talk to, even if they're not necessarily able to answer your questions. I find that working with others makes a difficult task tremendously more bearable. Just getting my head out of its own familiar patterns and loops is like a breath of fresh air. Ask your supervisor for more support ("Who would be a good person to bounce ideas about X off of?") if there isn't anyone around who can do this for you yet.
  • Spend more time strategizing, trying to be your own manager. What is a list of things you can try to work on your problem? What will you do if each of those things doesn't work? This also has the advantage of producing concrete plans, which you can show other people (such as your boss) and get feedback on.



V.

You may have noticed that both branches of that decision tree converged to "If this doesn't work, or it's too hard, give up."

At what point should you give up? When is a difficult situation too difficult?

When I was in situations like this one, I sometimes thought to myself, "If I were a better professional, I would be able to handle this problem. Therefore, I need to soldier through and prove to myself that I can do it."

But the latter does not follow from the former. Just because a better professional could handle this situation, does not mean you should try to. You may just make yourself miserable and not get anything done. For that matter, if you were a better professional, you would still benefit from more help and support from your colleagues; if you were good enough to survive the situation you're in now, perhaps you'd thrive in a better one.

Your most valuable asset as an early-career programmer is not the salary you're earning; it's the career capital you're gaining, learning new skills and building relationships with other programmers who are, ideally, much better than you. Think of it as a business decision: If you're not learning a ton of stuff, you're getting less for your investment of time than you should be.

Don't use "Could I, or should I, in theory, solve this problem?" as your barometer of whether to give up. Instead, ask yourself: "Is working on this project, in its current form, with my current rate of progress, worth it for me? Is this a better opportunity for me to learn and grow than any other opportunity I could reasonably find?"



VI.

Here's how I would summarize my list of solutions for this problem:

The truth will set you free. You may not be very good yet, but admitting that is the first step to getting better.


Ask questions and look stupid as soon as you possibly can; this will prevent you from looking stupider later on.

Don't be afraid to demand more help and support from other people. In an ideal world, where you're a perfect engineer, maybe you wouldn't need it - but in the world you're in now, you'll do a better job if you get it.

And don't be afraid to walk away if the management situation is more trouble than it's worth. If you can't get help, it's hard to get better, and getting better is what you need most at this point in your career.



Postscript: Success

What does it look like when you’ve succeeded at stepping up and asking for the support you need in your job?

Mainly what it looks like is having new, different, more complicated problems. When you’ve debugged one problem, you encounter more complex bugs that you couldn’t see before. But you’ll be making more progress, and feel better about your work.

Have you gotten past this hurdle in your career? What problems did you encounter afterward?








1I'm glossing over this a bit, but making sure your boss knows what you do is also an important skill. A subject that merits its own post.

No comments :

Post a Comment