### Author's Note

> A few years later; I've edited this to more accurately reflect how I feel about the situation. I'm putting more nuance into my answer because I'm learning more about nuance in these situations. It's easy to claim a 'black or white' answer, but we all know it isn't that simple. My answer now reflects that. 

From what you've described; the behavior you're experiencing doesn't appear to have anything to do with your gender. That isn't to say you aren't experiencing any gender related treatment (I hope you aren't), only that what you describe doesn't seem to be gender related.

When I was a team lead, I treated everyone equally. There's no room in tech for treating someone badly because of their gender. I don't know how to deal with it if it's happening to you.

It's important that you trust that your Team lead treats men and women equally. If there's evidence he isn't, then the old saying applies: Change your environment or change your environment.

By equally I mean that he treats everyone equally without deference to gender. If he is doing his job correctly, you shouldn't see him critique anyone else; and they shouldn't see him critiquing you. In front of others, it's very important for the team leader to show confidence, even if he just spent the last five minutes before correcting behavior in private. 

Now on to the issues you've raised:

You checked in code that didn't meet the standard he set out, so he rejected your branch. If I were in his shoes, I wouldn't have done the same thing in the same way, but I would make sure that my subordinates (odd word; because I don't think of a leader as 'superior' to the people they lead; but it accurately (not adequately) describes the situation) know what the right thing to do is. If they don't know what the standards are, that's my fault as a leader. It's up to me to correct it. In this case, you may have made a mistake, but the sheer fact that it happened means that you were either 1) not told what the right thing to do was or 2) was not appropriately mentored. Neither is your fault. 

One of the most important parts of being a programmer is realizing that the codebase you work on has to be maintainable by many different people. Any variable messups or other things that detract from being able to read the code **are not transparent to the customer**, because it takes longer to fix problems in code that's harder to read.

If your team has written coding guidelines, follow them. If they do not, then there should be some sort of community convention for your language (For .NET and C#, [Microsoft has a standard][1] that a lot of companies follow). 

Ask your Team Lead where the coding guidelines are so you can make sure that you follow them. Take two checkins to your meetings where two other developers didn't consistently follow the guidelines, so that when he says there aren't any, you can point out that others seem to be having problems with it too, and everyone would benefit from having those guidelines.

If he's treating you fairly, then he'll see this and this should be on the top of his list of things to do. If he isn't treating you fairly, then you have ammunition if it keeps happening. 

Saying "I'll get to it later" is bad. Later never happens. Take the time to do it right. There is no later in programming.

It's hard when you're a junior developer. You feel pressured to perform and there are a lot of people looking at you, and every mistake you make is tied to your name in source control forever. 




 [1]: http://msdn.microsoft.com/en-us/library/ms229042.aspx