Asking a lot of questions is important when you’re just starting a new job. It’s 1 of those things that cannot be emphasized enough. You didn’t get hired because there may be something for you to do sometime later. You got hired because that company needs help right then, and the idea is that you’re up and contributing in short order. But you’re just a newbie dumped into the middle of working on some piece of software that’s probably already large and involved, not to mention learning all about your new employer, and getting a sense of the new way of doing things there. There’s a very good chance your first instinct would be to find someone who knows everything that’s going on and ask “Herp derp?” Unfortunately, “Herp Derp” is a pretty useless question. Besides, very wide-open questions like that lead to basically you getting blasted with a firehose of information, overloading you and making it borderline impossible to remember everything you’re being taught. I don’t have the algorithm that optimizes the amount you can learn and the time it takes you to learn it. Having recently come through an initial round of firehosing, here a few things I’ve noticed.
Company-related issues (organization history, who the other people with desks all around you are, where the kitchen and bathrooms are, where your boss’s office is, where your desk is, etc.) are covered right off the bat, either during the interviewing process or as soon as you walk into the building on your first day. The good news is, that gets out of the way quickly. The bad news is, none of those questions (except for maybe “Where’s the bathroom?”) is really all that pressing.
Since company-related questions are pretty much covered without you having to do anything, it’s time to focus on other issues. Unfortunately, there’s no real way to avoid firehosings during your first few days on the job, so the best thing to do is to try to avoid deep dives and instead do everything you can to keep the discussions focused on the big picture. Specifically, I recommend putting your emphasis on your wh your customers are, what they’re trying to do, and top-level application design. This breadth-first over depth-first approach helps keep you from getting overwhelmed with minutia that will run together and blur after about 30 minutes. Focusing on a big-picture, specifics-light approach will help you understand the industry/industries you’re trying to support, the major design decisions that went into the application, and give you a good starting point for just about anything you’ll be working on in the near future. Seeing as how you’re writing software to do something for other people, or at least help other people do something, understanding your customers is not only important, it should be the basis of all the work you’re doing. Get into the habit of asking “What are our users trying to do?” early and often, it’ll lead to better software later.
Next up, it would probably behoove you to learn who at your office is an expert in what. If you have questions about anything you’re working on, it would be helpful to know who exactly you should be asking. After that, get a sense of what the development process is like (You didn’t think they’d just let you type code and never deal with things like checking it in, did you?). Do the check-ins have to be in any sort of format? Where do you keep track of your work and time spent working? Are people automatically notified when something moves into their bucket or do you have to tell them? Are there peer reviews or are you going straight to QA? Getting these questions answered should give you enough to start poking away at simple tasks on your own without having to have a bunch of “Now what?” sessions.
Got that? Good, because it’s still not time to sit down with someone and have them give you the down and dirty on the code just yet. Development environments do not come pre-configured on your new work machine. Ideally there’s some sort of written instructions for this sort of thing, but even if there is, this is where weird things are most likely to happen to you. You’ll probably be a thorn in some of the other developers sides at this point, dealing with all the many possible things that can (many of which actually will) go wrong with setting up a development environment, especially if you haven’t done it before. If the documentation at any stage of this process is lacking (it probably is, there’s not a whole lot of occasion to have to build development environments from these documents), please do humanity, and future new employees, a favor and update them with whatever is supposed to happen.
Finally through all that? I hope so, because it’s finally time to get into the code! If your new employer doesn’t have coding standards about commenting in your code, feel free to document the code you’re working in as you work on it so you can remember what it’s supposed to be doing. This is where a firehose of software details becomes its most useful, assuming its about whatever you’re working on at the time. Since you’ve gotten past your initial orientation and education on your new company, you’ll also be able to sit back and take all of this information in. Soak it up and enjoy the ride, because with any luck, it’s the start of a beautiful career for you.