I've been at my first job for about 2 months and I've started to notice that there is a delicate balance between workload and helping new-hires. Since there is a lot of pressure from management to fix bugs and resolve as many customer issues as possible everyone on the team seems to be very focused on their backlog of work instead of helping the new-hires get up to speed. The new-hires can ask questions and occasionally we'll get a developer to sit down and help us but often we'll get an obscure answer that only a veteran of the product would understand because they are too busy with their task.

I understand the the new-hire must also maintain a balance. Sometimes it will take a new-hire 3 days to investigate and fix something where a veteran could have done it in 20 minutes. New-hires need to show effort toward learning the product and the codebase.

With out simply reducing the workload of the veterans, how can you balance between helping new-hires and continuing to work on your backlog at a reasonable rate?

  • 1
    The question seems posed from an old hire point of view, but you worked there for only 2 months: are you asking for suggestions to pass on to your supervisors (weird) or you're in a company that is hiring so much you're now one of the old ones? – ZJR Aug 24 '11 at 14:59
  • 2
    I'm a new-hire with the company but I've had 1.5 years worth of co-op experience so I've been a new-hire several times at different companies. I wanted to show that I understand viewpoints of both the veteran and the new-hire and was asking for techniques that work well for both people – Spacebob Aug 24 '11 at 15:32
  • 1
    I see this recently when all the new hires were put on maintainance for current customers and most of the current programmers that knew the code base were “pimped” out to a new customer that was willing to pay large sums of money for consulting to extend the product. – Ian Aug 24 '11 at 15:33
  • 2
    I feel like this is slightly relevant. programmers.stackexchange.com/questions/100725/… – user606723 Aug 24 '11 at 19:04

I'm assuming you're asking this from the "New Hire" point of view. I've been in this situation many times. Sometimes you feel bad asking so many questions, but there's really no way you could come to the solution sometimes with such a lack of domain knowledge, etc.

The most important thing to remember is this. Don't go asking questions when you "assume" you won't be able to find the answer yourself. Give things a shot, poke around first, examine the code, try changing some things and see what happens - see if you can get something to work first. If you really can't, ask your question. However, when you ask your question, go to them with examples of what you've already tried. None of them want to feel like you are asking them to do your work for you.

Say, "Hey, I'm trying to do this, and I've tried this, this, and this already, do you have any ideas?" That will help them spend less time on you, and they will be more inclined to do it.

  • 8
    If you are going to ask questions, try to write a few down and ask them in one sitting (i.e. once every day or week). It can be annoying for your experienced colleagues to be interrupted from their work every half an hour. – Tom van Enckevort Aug 24 '11 at 13:35
  • My question really pertains to what do you do if its hard to get an answer from a colleague after you've done the investigation? It looks like at that point its an issue that I need to bring up to the manager – Spacebob Aug 24 '11 at 13:40
  • @Spacebob - try and ask a different colleague? If they are all like that - keep to yourself and when your boss asks you why something isn't done, say, I've been trying - but it's taking me a while b/c no one wants to help (obviously in a nicer way than that though). – slandau Aug 24 '11 at 13:41
  • @Spacebob, At some point you do have to stop wasting time on a dead end and ask a coworker. My advice- try asking someone who is also newish. They are often much more willing to help, and they might not know the answer, but would be interested in helping you find it. Sometimes what you need isn't more experience, it's a different set of eyes. – user606723 Aug 24 '11 at 19:07

At our company we assign for every new-hire someone to take care of him for the first few months. With this formal assignment we ensure the newbie only will consume one person and the person who is "coaching" the new hire has the responsability over his development, so it isn't a burden, just a temporary responsability. For the new guy is good because he learns faster and for the guy who is already there is an investment: in less time he will get someone to help him.

  • We have that system too. There is a transition period when you need to start asking your other teammate for help. I'm talking about when new-hires get assigned work that the coach might not be an expert on and another team member will be the go-to guy/gal. – Spacebob Aug 24 '11 at 13:07
  • I like how that's phrased "consume one person" – Rook Aug 24 '11 at 13:13
  • Why are new hires on Team A being assigned to a mentor from Team B? – Ramhound Aug 24 '11 at 16:36

The best advice I can give you is to make an appointment. Everyone has some downtime during the day, but if you just drop in randomly you're very unlikely to hit it. Say something like, "I have some questions about X, can I set up some time today to go over it with you?" They might decide to give you time right then, or later in the day, or maybe refer you to someone who might be able to answer your question better or faster. Either way, you're going to get more focused attention. If they give you an appointment later in the day, use the intervening time to try to figure the answer out on your own, or at least to refine the question. Even if I postpone someone's question for only 15 minutes, more often than not they figure it out on their own.

Just be aware that for most of us, your questions are important to us, they just usually aren't urgent. Try not to take offense at the difference.


Some of the more experienced coders actually enjoy mentoring younger developers, and make it a priority to do so. I do, whenever I have the opportunity. Perhaps you can find someone like that at your company by asking a different colleague each time you need help, then gauging their enthusiasm in answering you.

There are two ways you might need help: if it's a problem with the language or your tools, you can often find the answers either online or by purchasing technical books and reading them on your own time. While you would be reasonable in feeling that it's the company's responsibility to train you, very few company's invest much in training anymore. If you want to grow as a developer you need to invest time and money in training yourself when you're not on the job.

If your question is about your company's product, like how something works in the source code, it is more likely that you will just have to ask one of your colleagues for help. Alternatively, create a branch of your product's code in your revision control system, name the branch something like "learning_new_code" and just experiment with it.

Finally, project managers and departmental managers are there to help with problems like yours. If you feel you have no recourse but to get time from your more experienced colleagues, but they are unable to give it to you, it may be because they have deadlines to meet. Perhaps your manager will extend their deadlines in order to allow them more time to bringing you up to speed.

  • 3
    "Perhaps your manager will extend their deadlines in order to allow them more time to bringing you up to speed." - I am afraid that is not going to happen in a real life project... if the managers aren't going to move deadlines despite existing developers being under severe schedule pressure, how likely it is that they will do it for the sake of a newcomer not getting enough attention? – Péter Török Aug 24 '11 at 13:34

I am fortunate that I currently work somewhere this isn't an issue. I've gotten a healthy dose of mentoring here, and I'm very pleased with it.

  1. Every day one developer at my company is the "util" developer, on a rotating basis. The Util developer is the first line of contact when support needs to escalate something. Frequently, Util is just passing a problem off to someone else. But it is one specific developer and support knows to go to this person. I did some "ride-alongs" at first (they didn't put me in the schedule for a little while) to see how some problems were dealt with. This got me exposed to portions of code. When they started scheduling my regular util days there was someone "on call" at first to add additional assistance.

  2. We pair. You need to schedule pair time, pretty much, but everyone here is willing to do it. Further more, everyone knows what the schedule is and thanks to the next point has an idea of how progress is going for each individual. So if there's a problem, it gets proper attention.

  3. Every day we do a standup meeting at 11:45. This is 15-20 minutes. Every developer/QA person speaks. It's basically a way to say "this is what I am doing and this is where I am stuck", and if you are stuck you generally get pointed in some alternate direction (if it's a known issue/ an issue with code someone is very familiar with) or pair time is set up. Occasionally an additional meeting is scheduled.

  4. I've had to dive into completely alien code numerous times here (as with any job). Someone has always been sure to make themselves available to answer questions, if not right away.

I'll echo others: schedule meeting time to ask questions where possible. Id that still isn't helpful. . . well I don't want to get extreme here. But I don't consider that an ideal workplace. Is it possible people are still warming up to you/getting a handle on your abilities/etc?

I suspect the extra time spent when I came on board was easily justified because once people felt I was up to speed that obviously meant less work for them. More time spent short term saved a lot of time long term, and everyone understood that where I work. I'm very fortunate in my current position.


Often this is more an issue of focus than of time. Schedule 30-45 minute meetings with your team lead or mentor (before or after lunch is always my preference - my flow is already breaking then) a couple of times a week and save up your questions for then.

Most developers (or, at least, the ones most likely to be helpful in the meeting) will be fine with this.

If there's a very specific detail that's blocking your progress, use email.

Not the answer you're looking for? Browse other questions tagged or ask your own question.