One thing that will happen a lot in your first job programming (it’s certainly happened in mine) is that you will ask questions.
Asking questions is super important; in most cases, your employer would rather you take a few minutes of someone else’s time than waste hours of your own time. Also, the earlier in your employment you ask a questions, the more forgivable it is that you didn’t already know the answer. There will be posts in the future about when and how to ask questions, but I want to start it off with a very concrete, probable scenario and how to handle it. (By the way, in my first performance review, I was told that I do a good job asking questions, which I believe says something positive about my employer and about the contents of this post.)
Here’s the scenario: I am working on some code on a website, changing the business rules about validating the input on some page or other. I’m excited, because they’re actually paying me to write code all day! So I get some code written, spin up a local instance of the web server, click the button in my browser, and boom! A mile-long stack trace, most of which is in DLLs I didn’t work on, topped with some super helpful error like the famously unhelpful NullReferenceException.
So what to do? I will spend a few minutes reading code, checking for really obvious things. (See my earlier post about interrupting wheel spinning) After a bit, I conclude that I need a hand. So I send a very simple message to another programmer on the team: “I was just launching this website when [name of some library] threw a NullReferenceException. What would you check first?”
When I first started my current job, I got a lot of practice asking questions, and that one is definitely my favorite. Here are some of the reasons:
- It has a definite, narrow scope. The other developer will not have to drop everything and read code for an hour to answer it. He or she can answer with some really simple things, like “I don’t’ know, ask Steve” or “Is your config file in the right directory?”
- The other developer will not waste time deciding how to answer the question because it contains the procedure for answering itself: “Imagine that you saw this error, what’s the first thing you would do?” He or she will likely know the answer, or at least that that he doesn’t know the answer, instantly.
- Point (1) and (2) combine into the question’s most important attribute: It is respectful of the other developer’s time. Interrupting and distracting programmers is expensive to your company and frustrating to the other programmers.
(Total aside: Interrupting programmers wantonly is bad. I’ve heard the manager who interrupts programmers to check how the code is going compared to a gardener who pulls up flowers to check how their roots are growing. Gardeners do not recommend this practice.)
So, the next time you get a super unhelpful error message, and are in danger of losing piles and piles of time reading plumbing code trying to find the source of the exception, consider asking someone “what would you check first?” (Bonus points if you manage to ask while they are away from keyboard, so that you can be certain you didn’t pull up any flowers. )
Till next week, happy learning!