Take the 2-minute tour ×

As a CS undergraduate, the people around me are either learning or are paid to teach me, but as a software developer, the people around me have tasks of their own. They aren't paid to teach me, and conversely, I am paid to contribute.

When I first started working as a software developer co-op, I was introduced to a huge code base written in a language I had never used before. I had plenty of questions, but didn't want to bother my co-workers with all of them - it wasted their time and hurt my pride. Instead, I spent a lot of time bouncing between IDE and browser, trying to make sense of what had already been written and differentiate between expected behavior and symptoms of bugs.

I'd ask my co-workers when I felt that the root of my lack of understanding was an in-house concept that I wouldn't find on the internet, but aside from that, I tried to confine my questions to lunch hours. Naturally, there were occasions where I wasted time trying to understand something in code on the internet that had, at its heart, an in-house concept, but overall, I felt I was productive enough during my first semester, contributing about as much as one could expect and gaining a pretty decent understanding of large parts of the product.

I was wondering what senior developers felt about that mindset. Should new developers ask more questions to get to speed faster, or should they do their own research for themselves?

I see benefits to both mindsets, and anticipate a large variety of responses, but I figure new developers might appreciate your answers without thinking to ask this question.

share|improve this question

migrated from stackoverflow.com Feb 16 '11 at 17:42

This question came from our site for professional and enthusiast programmers.

Surely this depends on the question! –  Alex Feinman Feb 16 '11 at 19:02
add comment

9 Answers

up vote 28 down vote accepted

Ask questions, you should be given a "buddy" who knows the system you are working on who can answer questions you have.

Don't waste too long researching on your own, but at least spend 10-15 minutes on it, on your own. If after that time you don't have an answer, ask.

If you feel you are asking to often, write your questions down as you have them, and only interrupt every couple hours with your list.

Try to schedule an hour every day or two with your peer where you could do some pair coding. You type, and they just watch you and provide their insight as you go.

You mentioned it was a new language, get a book, do some reading/work on your own time to get up to speed.

Remember you are a team, they want you up to speed so they can give you some of their work. But, they also have work to get done, so can't be interrupted every few minutes.

Edit: and it doesn't hurt to ask a coworker how they want to be interrupted. Some have no problem being interrupted continuously, and it doesn't affect their work. Other people will hate you for it.

share|improve this answer
Only thing I can think of to add is to not just ask people how frequently they can handle interruptions, but also if they prefer email, IM, or in-person (I've never heard of anyone who prefers phone interruptions). –  Ethel Evans Feb 16 '11 at 18:18
@Ethel Evans, good point! –  CaffGeek Feb 16 '11 at 18:23
Great answer, you should not be ashamed/embarrassed to ask questions on a new job when you have to dive into a large pre-existing code base. Also, I agree with Ethel Evans point... establishing a preferred contact method is much appreciated. I hate phone calls and voice mails but emails/instant messages I find less intrusive and easier to respond to. –  Chris Feb 16 '11 at 18:40
add comment

I don't know. I guess it would be up to the senior developer. I much rather run somebody through a few simple concepts in a hour or so and have them do the job right than have them gopher around on the internet all day piecing together a understanding of the software. That method just leaves more room for speed bumps and other delays in the project. Now the game changes if the software is well documented and you have access to it. I would then expect you to learn as much as you could from the documentation then ask questions if need be. It really boils down to the developer I suppose.

share|improve this answer
add comment

Be prepared to show that you have done some work on your own to try to answer the question and that what another developer may give you is a hint to the answer rather than the actual answer. I remember in grade school having teachers that were rather great at being able to ask a series of questions in such a way that the student did solve the problem on their own in the end once they have a general algorithm to get there.

Don't try to get someone else to do your work for you though either. While it can be nice sometimes to pass off work that seems really hard or tedious, that senior developer is asked may just expect the new guy to do the typing on some idea that may come up for someone.

share|improve this answer
add comment

Never be afraid to ask a question. If you honestly don't know, ask. Do not sit spinning your wheels b/c you don't know something. If a Google search won't give you an answer, don't be ashamed to go and ask someone.

Personally, I would rather be interrupted with a question than find out later that something was done incorrectly and have to fix it.

That being said, I know going and approaching people when you are new isn't the easiest thing to do. When a new hire starts at my work, and they are working under me, I make sure to visit them once a day for the first two weeks to see what questions they have for me. And you know what? They always have questions.

So, if you don't know the something, ask. On the flip side, if someone asks you a question and you don't know the answer, don't make something up. Point them in the direction of someone who does.

share|improve this answer
add comment

A rule we have is "if your stuck for 10 minutes, ask someone".

Knowing how to ask for help is as important as any other skill you have. In most cases most people work in a team environment where you expend a cumulative pool time to solve problems.

If you are spending an hour to two hours to research a solution that others might have have already known is a waste of everyone's time. Your tasks will go over budget and the team will get behind. Spending 5 minutes talking about it (10 minutes schedule wise) will be worth it in the long run.

Sometimes your problem is that you have been looking at the same problem for too long and you need a fresh pair of eyes.

In most cases the part of a Sr dev role should be supporting to the Jr dev members on any projects. In most cases Jr dev members will be responsible for delivering the bulk of projects while the Sr dev's handle complex problems and overall architecture.

If we hire a new developer who is constantly behind on tasks yet never reaches out for help its likely he may be let go. There is nothing wrong with not knowing how to do something, its why communities like this exist.

share|improve this answer
add comment

I get nervous when new developers don’t ask questions. I think it depends on the type of question you are going to ask. One of the qualities I look for in junior developers is the ability to analyze and research problems independently. If they are unable to resolve an issue on their own I expect a question to be well structured and researched. An example of a bad question would be “Method xyz breaks when I call it. What should I do?” A better question would be “In the class abc I found that when I call method xyz it throws an “object not set to instance of an object” exception. I did some research on the internet and I think it’s a null issue. Can you help me?”

share|improve this answer
add comment

When you hire someone to work on a huge code base you often expect this person to take a few months to get into speed. Bouncing between the code and reference material is not only normal, but actually expected. This might take from half to a full year.

But, on the other hand, as Chad stated, you're on a team. If you get stuck and stop your progress, you should ask someone.

Why don't ask your team/project leader what's the best practice on this? I've seen project leaders that prefers to coach the newcomers themselves or other prefer to distribute the "question load" between the whole team.

Once again like Chad said, asking your whoever you wants to ask something the best way to ask is something wise to do. I myself prefer when people ask using the IM, since I can delay answering/walking to the person desk for a few moments and finish my current thoughts.

share|improve this answer
add comment

Documentation helps tremendously.

From my experiences starting out in my current job and now where I am a year later I have come to realize that a large share of questions can be done away with if the project has good documentation.

In my case there was none. But for anyone coming after me there will be plenty of material for them to read and come up to speed on the project.

And barring your seniors providing good documentation then talking with them will be the fastest way to come up to speed and get everyone moving in the right direction.

share|improve this answer
add comment

To be honest, I would have never become as good as I am today if I weren't answering questions on StackOverflow and on the job. True mastery comes in teaching.

Now, your co-workers may not be as open minded as I am, but as long as you are not overly disruptive of their routine, you're doing yourself--and them--a favor by asking questions.

share|improve this answer
add comment

Your Answer


