Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I just landed my dream job - working in a big (famous) company as a frontend web developer. I've never even worked in a proper dev team before - the last 4 years since I started learning web dev I've been working on my own just building sites and apps for small business clients I found.

I want to make the best possible start in my new job but it's not going as easily as I thought it might - there's very little induction or training - its a bit like being thrown in at the deep end, and to make matters worse most of the other developers in the office whilst being friendly and supportive, are speaking a language I don't understand very well. When they do speak english they use a lot of technical terms / jargon / names of products / systems etc that I've never heard of.

I want to make a good impression and don't want to show myself up by asking too many dumb questions.

What advice would all of you seasoned veterans of development teams suggest?


migration rejected from stackoverflow.com Jun 4 at 14:24

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by Thomas Owens Jun 4 at 14:24

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

Google often and frequently. ;-) –  stealthyninja Jun 11 '11 at 21:57
@stealthyninja, that's almost "google early, google often" –  dan_waterworth Jun 12 '11 at 12:38
At least they didn't throw you off a cliff to see if you could fly. –  JeffO Jun 12 '11 at 18:28

7 Answers 7

up vote 46 down vote accepted

Ask the dumb questions, and keep asking them. Nobody expects a new hire to know what is going on. If anything, they will respect you for it - they certainly won't mind it; most programmers love being able to show off to a newb. What everyone hates is someone that just goes blank and sits there.

However, do not ask the same question twice. Keep a log book, and write down what you are told. People will quickly get irritated if you ask things like "What's the URL for the Subversion repository?" time after time.

Exactly whath I would have said. Learn Learn Learn and have no shame about it. –  Richard DesLonde Jun 12 '11 at 4:30
Dude, I've been working in my company for quite a while. I am well respected and have been promoted project leader. I constantly ask for the same credentials or URLs over and over again. Nobody seems to care. –  Falcon Jun 12 '11 at 10:24
@Falcon, you might not know that your peers treat you as a forgetful senior, who is just too old to be in a good memory. –  Pavel Shved Jun 12 '11 at 12:55
@falcon: Not to be rude, but that's just annoying and disruptive. I hope you are kidding. Asking questions to learn is fine, but not because you are too lazy to find out information for yourself, or to write it down. –  Richard DesLonde Jun 13 '11 at 2:10
Well, since I'm totally unqualified to judge which is the best answer I'm going to accept the consensus here and accept this one as the best one - I must say though that everyone's answers are very much appreciated and are helping me feel more confident about asking lots of questions. Thanks to you all. –  Xoundboy Jun 13 '11 at 8:03
  • Communication is the key. Software development is a team sport. Speak up. Ask questions.
  • Don't break the build.
  • Learn how to use the source code management system perfectly.
  • Know your IDE and other tools inside and out.
Well, you have certainly terrified him. How much you have helped him, I'm not clear. –  nbt Jun 11 '11 at 22:26
@Neil: True. But after all, humbleness is a prerequisite to programming ;) –  back2dos Jun 12 '11 at 6:30
I agree that this does feel a bit intimidating but I guess it's the reality of the job and I'm a realist so +1 for this comment –  Xoundboy Jun 13 '11 at 8:07
I think I'd give that same advice, but with the last bullet first. –  Dan Ray Dec 29 '11 at 18:44
Six months late, but I'll edit it for you. I agree. –  duffymo Dec 29 '11 at 18:46

Congratulations. Just work hard, listen carefully and ask questions -- you should be alright. Don't forget to have fun!

+1. This is the answer. Everything else here is just coments on this. –  MarkJ Jun 12 '11 at 18:12
+1 for saying "Congratulations" and "Don't forget to have fun!" This is the most reassuring answer. –  Xoundboy Jun 13 '11 at 8:10

Ask your manager to allocate a mentor for you. Someone who's been with the company for some time and can answer all of the questions that you have. If they can't answer them, then they'll at least know who to point you to. Having a mentor is one of the most important things that you can have when you first join a company (especially a large one).

If, for some reason, the company doesn't offer mentors, then find one or two main contact people who have been with the company for a while. Ask every question that you need answered (as Neil pointed out above). However, don't frequently pester them as it generally takes an engineer roughly 15 minutes to get back on task every time they're interrupted. Instead, compose an e-mail throughout the day and send it to your contact at the end with all of your questions in bullet point format.

I don't really like the "mentor" approach, but I think you should pay special attention to what Demian says about "15 minutes to get back on task". If your question is going to take more than a minute to answer, it's going to interrupt someone's workflow...so make sure they aren't in a "heads down, heavy working" mode before asking. –  James P. Wright Jun 12 '11 at 2:29
Mentors are invaluable to anyone's professional development, at any point in their career. –  Demian Brecht Jun 12 '11 at 2:49
+1 for mentors. Never had the chance to have one. But had the chance of mentoring somebody else. It also taught me a lot of things :) –  back2dos Jun 12 '11 at 6:27
Yep, when you first start a new job, everyone there is in the category "people who have been here longer than me." You need to quickly identify the "people who been here a long time" category - they're the ones who can either answer your questions, or tell you who can. –  Carson63000 Jun 12 '11 at 22:30
+1 I'm going to ask for a mentor when I meet my boss next time. –  Xoundboy Jun 13 '11 at 8:08

On any good team, they expect a new guy to ask questions. The only person we don't want to ask us questions is the guy who already asked that same question 3 times.

Ask questions, listen closely, ask followup questions or better yet, restate their answer in your own words ("So you are saying it's like this...") and learn.
There isn't even anything wrong with asking a question again a day later ("Hey, remember when I asked that question yesterday? Could you explain this piece again please?").

If you find yourself having to ask the same questions over and over, either they aren't explaining well (in which case you should be googling) or you are possibly on the wrong career path.

Most developers I know not only like answering questions, they like explaining why that is the answer.
"Use protected there" is not good enough, they WANT to talk about WHY you should use protected vs private in that case.

Those kinds of questions are actually the beginnings of conversations, and that is a perfect way to integrate into a team.

Thanks for your good advice - I'll be careful not to repeat my questions. –  Xoundboy Jun 13 '11 at 8:35
+1: The guys I really hate are the ones who don't ask questions, hack away for two weeks, and emerge with a pile of WTF. –  kevin cline Dec 29 '11 at 19:54

Remember that there's a lot more to programming than just throwing down code in an IDE. A good senior programmer is going to have a toolbox full of programs that they're very comfortable with and can leverage to great effect. At the very least, this is probably going to include a text editor, a diff/merge tool, one or more database clients, a source code control interface, maybe a specialized find-in-files tool, and others.

Everyone's got their own combination of tools they prefer to use. I'd suggest observing which ones your senior developers have elected. Pick their brains and find out why. Not everyone's given it a lot of thought, but you're likely to find some of your coworkers have spent a lot of time considering their environment and can tell you exactly why they use gvim for their editing when most of the team is on Notepad++, or why they think WinMerge is the perfect tool for deploying hot of the press code to the test server. People inherently like talking about themselves, and you can learn a ton getting an expert to describe his environment.

From there, spend some time practicing with those programs yourself. Learn how they work and what they can be used for. Spend some time dabbling with the advanced features. You certainly won't become an expert in everything on day one (or year one), but at least become familiar with what each tool can do, so when you encounter a situation where it would help, you recognize it and know where to start.

From there, never stop learning, and never stop experimenting. Always be on the lookout for better tools, or better ways to use the ones you're already familiar with. Over time, you'll pick up programs that work well for you and become permanent members of your toolbox, and you'll have some highly recommended to you that just don't fit with the way you think. That's great. Keep at it, and in a couple decades, you'll have you're own hand chosen set of tools that you're very effective with, and you'll be the one being asked by the eager young developer trying to get started.

Hi, thanks - I'll bear this in mind. –  Xoundboy Jun 13 '11 at 8:27

Your goals now are to understand what it's like to work in a group, what the terminology is, and how to think about software development.

Read books like (and this will show my age), "Rapid Development", "Writing Solid Code", "Debugging the Development Process", and so on. Those are rather dated now, but the concepts haven't changed. These talk about the nuts and bolts of project management styles, writing software, and group interactions.

For a more modern list of books, look at http://third-bit.com/blog/archives/4235.html .

For something you can start reading right away (though open-source software related): http://producingoss.com/ . There's also some excellent video recordings available, like http://www.youtube.com/watch?v=aAb7hSCtvGw (that one is on API development).

+1 Thanks very much - this is great info - I hope I'll have time to do some reading after hours....my 2 year old son usually stops me doing too much of that though. But I'll definitely be checking out these links properly when I get chance. –  Xoundboy Jun 13 '11 at 8:33

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