What I mean by that is, how do you go about developing on a code base you share with developers who have been working on it for years and are very familiar with it?
I don't want to step on anyones toes, but I get not so subtle complaints about the way I do things, whether it be how I whitespace my code, or how frequently I checkin to SVN (too often). So while I can change those things easily — I want to be a better team developer in general.
I'm not sure what to do, other than ask, but maybe you guys have some thoughts I could put to practice.
UPDATE
There isn't any style guide to speak of — it's just people aren't used to sharing the codebase. Everyone has their own little siloed code-world.
This is a perl shop, but I'm sure these apply to any language
UPDATE 2
The CTO who later became CEO was a complete megalomaniac and was the primary source of these complaints. If you didn't do things exactly how he liked, whether it was using a Mac, or Emacs, or 4 tab spaces instead of 2, or dress a certain way, you were inferior. It was a horrific situation that I tried to correct, but the only correct answer for me was leaving.
I am convinced that this was an instance of bullying in a workplace, and subsequently, I'm more aware of what might be subtle bullying and inappropriate behavior in a work environment.
To any developer looking for answers to a situation like this, leave immediately. You can't teamwork your way out of a bad team situation.
Best Answer
Ask. That is, ask the folks you work with. Do your best to stick to the established style of the existing code. Ask especially if there's a document list of coding standards, and follow it. If there isn't one, write up a first draft based on what you observe in the code and then ask the other team members to critique it. You'll do the company (and new developers who come after you) a service by starting to document the accepted coding practices. The only risk is possibly getting caught in the middle if it turns out that the old-timers don't agree with each other on what is or isn't acceptable.
Also, don't be afraid to be yourself. You might be the new guy, but you're a member of the team, and your opinions are valid. If you can think of better ways to do something, suggest it. Respect the other team members and the established way of doing things, but don't let them push you around. The company wouldn't have hired you if it didn't value your input.
It'll help a lot if you can find someone on the team that seems friendly and particularly willing to answer questions. (If it's a good team, that should be everyone, but teams aren't always like that.) Your boss may have assigned someone to help get you started. Use that person as a resource. Write down questions as they occur to you, and then ask that helpful person to answer them from time to time.
As for checking in code "too often," why not create your own branch for your periodic commits, and then merge back to trunk when your code is ready? There's no harm to anyone else in doing that, and when your coworkers see you getting benefits from SVN that they'd like, they might follow your lead.