The Novice's Dilemma

Imagine. It's your first day of your first ever job. As you drive into the office you're reflecting on what it took to get to this point. What felt like hundreds of ignored applications, only maybe a dozen interviews, and if you were lucky a handful of offers before you finally got hired. Weeks have gone by since you so much as glanced at the job description, and your memories of the interview seem at once too specific and too general to be of use to you in preparing you for what to expect in your first day. If you do remember either of those things then you might be wondering what an algorithmic solution to the game Lights Out even had to do with one of the job responsibilities being something like using Perl to scrape data out of ancient file formats.

"Oh shit," you mutter as you return to the present and realize you missed the turn the GPS dictated in its steady synthetic monotony. Fortunately you left a few minutes early for precisely this, still arriving with time to spare. You walk in to the building and say to the receptionist, "Hi, it's my first day. I was supposed to meet with Mr. Joe Smith?"
"I'll let him know you're here," she chimes, reaching for the phone. It doesn't take long for the first manager of your professional career to arrive, Joe Smith.

An amiable guy in his mid-forties, you remember being impressed with how positive Mr. Smith helped keep your interview. In the span of about an hour, he's help get you logged into your accounts and given a brief, albeit dense, summary of what your group does; and of course introduced you to your immediate colleagues. Mr. Smith leaves you to finish setting up and assures you to ask any questions if you need to. At some point in the day you get assigned your first task and given the same encouragement: feel free to ask someone if you need help. A few hours go by, and you've been able to make significant strides through the task before it finally happens, you don't understand how to do something you need in order to continue working. You think that it's simple enough that if you spend fifteen minutes on it you can figure it out, but simultaneously you're thinking that if it's simple enough then someone can probably show you how to do it in a single minute. And so now you have to make a choice...

Unfortunately, on any sufficiently complicated problem there are lots of questions to be asked, and most projects are entire lists of these tasks. Consequently, just understanding the existing landscape is typically a more difficult problem than making an incremental improvement. In combination this ultimately leads to what I will now term the "Novice's Dilemma". A novice will need to spend a significant amount of their time trying to learn the basics of a problem domain, or even just a particular environment. But because their learning is not in isolation of some sort of evaluation -- from their coworkers, their supervisor, or even them self -- there's some stress that will ultimately impede how quickly they do learn and how much they can contribute.

If you ask too many questions, you worry others will think you're incompetent. If you take too long to accomplish your work, you worry others will think you're slow. So you're forced to walk the tight rope of not asking too many questions while simultaneously making sure to ask enough to make reasonable progress. At various points you have to weigh how long you think you'll struggle on something with whether or not someone knows how to help you and if you'll be wasting their time to ask for help. Of course, prior experience matters a great deal here. In this story, there's very little expectation that someone fresh out of school would know enough to forgo asking questions. However, an average worker moving into a new position is expected to come with certain minimum skills and has to tread more carefully.

In the moment, it doesn't seem obvious that there are strategies that can help here. I certainly have been in these circumstances at various times, worrying that I can't ask a question for fear of external judgment while grappling with a complicated subject. So I wanted to share some tricks for achieving balance.

Batch your questions. This might seem relatively obvious, but there's really something to be said for writing down your questions as you have them without worrying about answering them. The first thing I've found is that sometimes I'll postpone asking a question and forget it altogether. While that may mean it wasn't important enough to know anyway, it can also delay coming to a complete picture of your project. Second, many questions don't need to be answered to continue making progress. They may provide important context, but it can be easier to keep your forward momentum and work without that context. Third, as you work you sometimes come to the answer to one of these questions and so you get a better feeling for what kinds of questions don't need to be asked. Or, for instance, the answer to one question informs the answer to another question. Finally, if you batch your questions and record the answers to them, you'll actually be producing valuable documentation which you could give to another new person when they start. (Be careful that you don't provide reams of information to someone without some editing though -- I don't think many would appreciate receiving an 800-page thick tome on their first day!)

Timebox your problems. If you're sufficiently disciplined (which I can admit, I typically am not myself) and you are timeboxing how long you will work on something, then you can say that you won't allow yourself to struggle on something for longer than 10% of your available time for the task, especially if you know someone can help you out. Doing this bounds both the number of questions you'll ask and how long you'll spend solving the problem. Even simple decisions like, "I'll only work on something for fifteen minutes before asking someone," can work wonders in this capacity.

Broadcast the struggle. There will be times when you simply don't understand something and can't think of anyone in particular who would. In situations like this, though nerve-wracking to do, it's better to tell everyone who will listen what you're having trouble with. People generally want to help and if you're problem is that hard no one will judge you for it since often times they won't be able to easily solve it themselves (or expended many long frustrating hours on something similar once). Asynchronous, parallel channels like IRC, Slack, forums, or e-mail can be godsends in this regard. And if you're working in an Agile environment, the daily stand-up is a key place where you can and should feel free to practice this.

It's not about you. Not so much a trick, but a reminder that your coworkers are not usually trying to make you fail, no matter how abrasive their personalities might be. Quite often they're trying to get through the day and get their work done same as you are. If they don't want to answer your questions anymore, it's their responsibility to set those boundaries and tell you to figure it out on your own or go ask someone else. And if no one seems to want or be able to help you then that organization might not be the right place for you and you shouldn't worry about moving on.