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, no registration required.

I've been a solo .NET programmer for a small startup for the last 8 years. I've put together some pretty decent software, and I always strived to better myself and conform to best practices, including source control (SVN/TFS). I worked very closely with a team of engineers of other disciplines, but when it came down to the software I was the only one programming. I love the craft of programming and love learning new things to sharpen my tools.

In 2 weeks I will be starting a new job in a team of 20 .NET developers. My position will be mid-level, and I will be working under some programmers with incredibly impressive backgrounds. Again, the team aspect of development will be new to me, so I'm looking for some general "new guy" tips that will help me be as effective and easy to get along with as possible from the get-go.

Anything goes, including high level tips, and small day-to-day things about communication.

share|improve this question

put on hold as off-topic by Jim G., MichaelT, GlenH7, psr, Robert Harvey Jul 7 at 20:31

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Jim G., MichaelT, GlenH7, psr, Robert Harvey
If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

6 Answers

Mostly common sense but my advice would be:

Spend as much of the first week with people rather than the tech. Don't waste the first day customising your desktop or anything else that will isolate you from the team. Get to know as many peers as possible as quickly as possible.

Try to figure out who the work horses are and who the bums are quickly too. Avoid the bums as much as possible, every team has them and you don't want to be classed as one.

Attend any social events in the first few weeks, even if just a beer after work or lunch.

Listen and write things down, ask peers to repeat descriptions of procedures will anoy them.

Spend the first 3-6 months getting familiar, unless specifically asked on a specific problem, do not recomend changes to procedures/architecture/etc. They will work differently to you, and some elements may be poor - but there will be reasons for it and they are rarely due to negligence or ignorance.

I doubt the programming side will actually be a problem.

share|improve this answer
1  
Beer at lunch? You must be European :P Most people would think I'm some sort of alcoholic if I did that here in Pacific Coast US. –  Crazy Eddie Jun 21 '11 at 16:39
    
@Crazy Eddie: I'm Canadian, and my company pays for the beer and has it brought in to the office every Friday... –  Steve Evers Jun 21 '11 at 16:45
    
@SnOrfus - I've experienced both extremes in Canada actually. I think the "allowable beer" is in decline. –  Scott Whitlock Jun 21 '11 at 16:55
    
"some elements may be poor - but there will be reasons for it and they are rarely due to negligence or ignorance." You had me until this statement. It has been my professional experience that certain things being done poorly due to ignorance is pretty common. If it wasn't done out of ignorance then it was done out of time constraints. –  maple_shaft Jun 21 '11 at 17:55
    
@Snorfus - If you found a company in the US that did that, it'd probably be the only one :P I think CEO's and other high and mighty types might do some drinking over lunch, but most places actually have it in the handbook, "No bringing alcohol to work," if not more stringent. Although our place has that and those of us that brew the stuff have brought taste samples for trade; we just don't actually drink them at work. –  Crazy Eddie Jun 21 '11 at 17:58
show 5 more comments
  • Learn! Meeting new programmers is a great way to learn new tricks. Watching them type will learn you a few editor tricks and looking at their code will give you new ideas.

  • Don't bother your colleagues every five minutes but if you're really stuck don't hesitate to ask for help. Too many programmers are stuck on a program for two days where asking your neighbor would have solved it in an hour.

  • Code wars are religious wars. The syntax might be somewhat different over there (do you add brackets to singe line statements?) but it's rarely worth fighting over.

  • Socialize. If they're doing a drink every week be sure to join it. This can be as simple as eating together.

share|improve this answer
add comment

Playing Devil's Advocate and I'm going to say make sure your teammates are competent. Nothing is worse than working on a team where nobody except you does anything the "correct" way, because you're always outnumbered in people who want to do things wrong.

You mention working under developers with impressive background, so that sounds promising and in that case I encourage you to learn what you can, but never forget what you already know for the sake of "herd mentality". If everyone else does something wrong and you do it right, don't compromise yourself.

share|improve this answer
    
+1 for good advice and the quotes around "correct". –  sange Jun 21 '11 at 17:46
    
Honestly I didn't want to add quotes around it, because I firmly believe there is a right and a wrong way to write software, but I didn't feel like rehashing that old argument :) –  Wayne M Jun 21 '11 at 18:29
add comment

In addition to Jonno, I would say:

Be prepared for changes. Every team works different. Good SW teams have coding rules. Be prepared to accept them, even if initially they seem weird.

Be prepared for a lot more communication. When you work on your own, a lot of detail information is in your head. As soon as you work in a team, these details (at least some of them) have to be shared and communicated and time is required for this.

share|improve this answer
add comment

Listen more than you talk.

Ask more questions than you attempt to answer (unless the questions are directed at you). The "old timers" on the team will know how much progress you are making in learning the code by the questions you ask. They probably have a mental list of questions they are expecting.

Write your code to match the prevailing style. This applies to where you put spaces, curly braces, capital letters, length of variable names, average size of methods, density of comments, and everything else that shouldn't matter. If you have a really good reason for doing things differently, then ask one of the old-timers why the team has the given style. You may learn some interesting things about the team history and personalities. Which brings me to the next point.

Learn the team lore. Most likely none of the lore is written down anywhere, but it's common knowledge on the team. The team lore includes the history of how the project got to it's current state, mistakes made in the past, successes made in the past, lessons learned along the way. It's referred to in brief statments like "sounds like the frobnitz bug again." When you see/hear team members agree with a cryptic comment someone makes, there's probably team lore involved. Ask someone.

Don't critize code until you know the personalities and history involved. You don't know who you might be offending.

share|improve this answer
add comment

Ask questions and listen to the answers. Think about the answers to previous questions before you ask the next one so that you can try to anticipate an answer.

Strive to do the very best work you possibly can. Get used to asking yourself what someone else on the team will think of your code if they have to make a change to it next month.

If you see a problem that needs to be addressed, do your best to have a reasonable solution ready to offer before voicing concern over the problem. Take ownership of implementing a solution when you point out a problem.

share|improve this answer
add comment

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