Take the 2-minute tour ×

I recently started as a junior developer. As well as being one of the least experienced people on the team, I'm also a woman, which comes with all sorts of its own challenges working in a male-dominated environment. I've been having problems lately because I feel like I am getting too much unwarranted pedantic criticism on my work. Let me give you an example of what happened recently.

Team lead was too busy to push in some branches I made, so he didn't get to them until the weekend. I checked my mail, not really meaning to do any work, and found that my two branches had been rejected on the basis of variable names, making error messages more descriptive, and moving some values to the config file.

I don't feel that rejecting my branch on this basis is useful. Lots of people were working over the weekend, and I had never said that I would be working. Effectively, some people were probably blocked because I didn't have time to make the changes and resubmit. We are working on a project that is very time-sensitive, and it seems to me that it's not helpful to outright reject code based on things that are transparent to the client. I may be wrong, but it seems like these kinds of things should be handled in patch type commits when I have time.

Now, I can see that in some environments, this would be the norm. However, the criticism doesn't seem equally distributed, which is what leads to my next problem. The basis of most of these problems was due to the fact that I was in a codebase that someone else had written and was trying to be minimally invasive. I was mimicking the variable names used elsewhere in the file. When I stated this, I was bluntly told, "Don't mimic others, just do what's right." This is perhaps the least useful thing I could have been told. If the code that is already checked in is unacceptable, how am I supposed to tell what is right and what is wrong? If the basis of the confusion was coming from the underlying code, I don't think it's my responsibility to spend hours refactoring a whole file that someone else wrote (and works perfectly well), potentially introducing new bugs etc.

I'm feeling really singled out and frustrated in this situation. I've gotten a lot better about following the standards that are expected, and I feel frustrated that, for example, when I refactor a piece of code to ADD error checking that was previously missing, I'm only told that I didn't make the errors verbose enough (and the branch was rejected on this basis). What if I had never added it to begin with? How did it get into the code to begin with if it was so wrong? This is why I feel so singled out: I constantly run into this existing problematic code, that I either mimic or refactor. When I mimic it, it's "wrong", and if I refactor it, I'm chided for not doing enough (and if I go all the way, introducing bugs, etc). Again, if this is such a problem, I don't understand how any code gets into the codebase, and why it becomes my responsibility when it was written by someone else, who apparently didn't have their code reviewed.

Anyway, how do I deal with this? Please remember that I said at the top that I'm a woman, and I'm sure these guys don't usually have to worry about decorum when they're reviewing other guys' code, but honestly that doesn't work for me, and it's causing me to be less productive. I'm worried that if I talk to my manager about it, he'll think I can't handled the environment, etc.

share|improve this question
I am a guy, junior (at this company), and I have felt a similar double-standard. The codebase often looks like crap, and yet I am expected to follow a much higher standard. Well, it turned out that crap got in there due to "death marches" that were made in the past. Also, apparently I look 5 years younger than I am. When my colleagues found out my real age, I became much smarter overnight. Humans are imperfect monkeys. It helps if you share lunch with them and laugh to their jokes, but do not overdo it. Guys interpret EVERYTHING as a flirt. –  Job Feb 6 '11 at 4:19
@Job: Well, if the code base is crap it should be better, hence your commits has to have a higher standard. Otherwise it'd become even more crappy, right? :) –  Macke Feb 6 '11 at 12:01
@Marcus, you are right, but what would be really helpful is if the rules were clearly stated, and the same rules applied to everyone. Also, there is something to be said about blending into the same code standards, as the asker mentioned. I have seen a junior guy being let go as a scapegoat. The management complained that engineers produced too many bugs. The engineers could not do a decent job because the management gives them fixed deadlines. So, when something goes wrong, there is always a junior guy with the most screw-ups to blame and let go. en.wikipedia.org/wiki/Dedovshchina –  Job Feb 6 '11 at 15:28
@Job: You're right too. ;) It depends on the circumstances. I'm just saying that it might not be that bad. And the scenario you talk about sounds awful... but in that case there's little you can do, except leave and join a place populated by sane people instead. –  Macke Feb 6 '11 at 19:42
One thing that stood out to me is "They are used to guys so they don't use decorum." I'd say you need to suck that up unless it's clearly an issue of discrimination. Would you go to a construction site and expect to be treated differently than the rest of the framers? Toughen up. If you work in a male dominated environment you need to be able to cope and adjust to the different social norms just as must as they do. Don't be so "sensitive". –  Rig Mar 9 '12 at 14:58

7 Answers 7

up vote 28 down vote accepted

There is a chance that you're being singled out as a woman, but it's also possible that you're just a junior developer and new to the job.

Error-checking and expressive messages are important. If you're going to add something to the code, make sure it's right and up to the team's standards. Similarly, if you're modifying someone else's code, try to improve it where possible -- don't go off rewriting the whole thing, but do try to leave it a little cleaner than you found it.

Is there a written version of the coding standards that your team follows? If not, it might be a good idea to write it all down. You can spearhead the effort by writing down the mistakes you make and forming them into a checklist that you can refer to before submitting your changes for review. As a side effect, you can use that written standard to appeal future rejections if they contradict it.

It sounds like there may be some lack of understanding between you and the team lead. It might be helpful for you to ask for a one-on-one meeting with him and discuss what you can do to improve. You can lead in with something like "I feel like I'm still missing a lot of nuances of what I should be doing. As a junior developer I want to grow and improve. Can you help me get there?" and see what happens.

share|improve this answer
Thanks for the reasonable response. –  user15859 Feb 6 '11 at 3:41
Anna's responses are generally very reasonable. +1. I think working where you work would drive me nuts. Doesn't your management care about meeting deadlines? If the code works, ship it. Clean it up later. Heck, you could even clean it up on Monday and push it through in the next release. This behavior by your manager would never fly at my place of work, and I'm glad I'm able to concentrate on meeting deadlines instead of politics. Hope your situation gets better and that you find a solution. :) –  jmort253 Feb 6 '11 at 5:34
@jmort253 Thanks. :) That said, "if the code works, ship it" can be a dangerous attitude to have. Working code isn't always good code (although it's certainly better than broken code) and code quality is important in the long term. Cleaning it up later almost never happens, since other deadlines appear and more pressing things come up. There's a term for this - "technical debt". –  Anna Lear Feb 6 '11 at 5:37
@Anna, agree on the importance of conformant code. I've read that non-conformant code is enough for Linus Thorvalds to reject a submitted patch for Linux on the spot (but I cannot locate it right now). –  user1249 Feb 6 '11 at 10:05
@Anna/Thorbjorn - Sometimes you just have to do what the customer wants though if there is a deadline. Your client won't be very understanding if he/she lost $15,000 worth of business revenue because you simply wanted to clean up capitalization errors. Unfortunately, trying to eliminate 100% of technical debt is not always possible. It would be similar to waiting 40 years to save up enough cash to buy your dream home instead of taking out a mortgage. Sure, you'd be free and clear, but you'd have spent your entire life dealing with shady landlords. –  jmort253 Feb 6 '11 at 19:32

It sounds like you may be taking this stuff a little too personally. Don't; this kind of thing happens all the time.

The reasons for rejecting your check-in (variable naming, comment quality, configuration location) seem pretty standard to me.

The timing of it was the decision of your team lead, and I wouldn't worry about it if I were you. If somebody is blocked over the weekend, the team lead could choose to allow the check-in and ask you to fix it afterwards. If he felt it appropriate to kick it back even though it might block some other devs, that's his responsibility.

As for the team lead telling you not to mimic others but to do what's right, it sounds like he's trying to give you some initiative to make the code base better. That's a good sign. He trusts you to use your judgement, so go ahead and do what you know is right. That doesn't mean that you have to go changing everybody else's code, but it does mean that you should take responsibility for the quality of code that you write.

share|improve this answer
+1 You are focusing on the relationships and emotions. The programmers you are working with sound very dry but they are just focuing on the code issues. This is pretty common in programming environments I'e worked in. I've seen this regardless of gender by the way. –  Michael Durrant Jun 2 at 11:51

It's entirely possible that you're being singled out because... you're a junior developer.

From your description, it sounds like you did not follow the standard as the team lead perceives it.

The solution is simple:

  • If that's the standard, follow it.
  • If you don't understand the standard, ask for clarification.
  • If your interpretation of the standard or instructions differs from the team lead's, ask for clarification

Don't make a battle out of it; if you try to make the team lead "wrong" then even if you win, you lose. Learn the appropriate lesson and continue to grow.

share|improve this answer
Trying to follow some "standard" to the "T" when one is dealing with dorks like she describes won't do much good. It'll be an endless argument over definitions and semantics. –  MrDatabase Feb 6 '11 at 3:19
@MrDatabase They don't sound much like dorks to me. A little picky, perhaps, but the devil's often in the details and once you start slipping your standards, your whole app can go downhill fast. –  Anna Lear Feb 6 '11 at 3:34
It's true that standards should be respected. However she clearly demonstrates that it's not really a standard (previous developers didn't adhere to it). Hence her coworkers imposing the "standard" on her (without saying something like "hey look... we know it seems inconsistent but we're really trying to improve our code base") is hypocritical and unhelpful. When coworkers act like this you need to take a different, smarter approach. –  MrDatabase Feb 6 '11 at 3:41
@user15859: if you are referring to my answer, that was not my intention at all. I believe I said exactly the same thing that Anna said in her answer. No offense was intended. The standards violations you mentioned are important for long-term maintenance, and any ambiguity in the scope of applying the standards must be resolved with you team lead. If you were lazy you wouldn't have posted here. If you were incompetent you wouldn't care so much. I do not believe you are either of those. –  Steven A. Lowe Feb 6 '11 at 3:48
I think she's referring to what Woot4Moot said as he used "laziness and imcompetent" as a phrase in his comment. I think your answer is fine as it does give the OP some recourse and room to take action based on her interpretation of what's really going on. –  jmort253 Feb 6 '11 at 5:41

Being a woman has nothing to do with the issues you're having.

When I was a team lead, I treated everyone the same, and unless we're in a Mad Men type of environment, it's important that you trust that your Team lead treats men and women equally. If there's evidence he isn't, then that's something you need to take to management.

By equally I mean that he equally jumps down other people's throat when they don't do what's right. You may not see it. Others may not see it when he chews you out. They're not supposed to.

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 would have done the same thing.

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 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.

share|improve this answer
I'll second the comment about "I'll get to it later". If I had a nickel for every time I've heard that, well, I wouldn't be here typing in this comment. :-) –  Eric King Feb 6 '11 at 3:36
For .Net there is style cop. Turn it on, so that code would not build until StyleCop is happy. This removes human subjectivity is work-force bullying. You see, technology can help you decide whether Michael Phelps was #1 or #2. In figure skating, however ... figureskating.about.com/od/famousskaters/tp/scandals.htm Being a team lead should not be about power-tripping. There should not be [dis-]favorites in a team. One must be careful to make sure that such impression does not get formed. One good way to do so is to turn on rules which would check the code and give you an unbiased answer. –  Job Feb 6 '11 at 15:34

An addition to the other answers:

As a Lead Developer, I'm usually more picky with the junior devs because they are much more malleable than people that has been working for a few years. (My ppl skills aren't that good... yet.)

It's very hard to change someone who has been working (and earning decent salary) for a while and is satisfied with his/her level of code (even though the quality could be improved). Those guys don't care if you try to guide them into becoming better/great programmers. They're happy working in the code-factory.

New guys, like yourself, OTOH, usually yearn for guidance and knowing what's right and not. Also, they are able to absorb feeback and change their ways to the better. They are not set in ther ways.

If you take these advice to heart and make them a part of your everyday life, you'll find that in no time you will be writing code that's superior to much of the existing code base.

So ...

.. it could be that you're getting more feedback just because you have the potential to make something of it. :)

share|improve this answer
This raises a lot of good points. –  sevenseacat Feb 6 '11 at 14:26

Take a little time to learn the various nuances of your coworkers' personalities. In my experience you can avoid irrational, unnecessary, inconsistent or just plain worthless criticism if you work around your coworkers quirks.

For example some coworkers may be hungover on Mondays. They may be very irritable and overly eager to reject certain code branches or commits. If you have to work with someone like this try to avoid committing code on Mondays.

On the other hand a hungover coworker may be too blase to care about the verbosity of error messages... so Monday morning may be the perfect time to commit your code :-p

The personality quirks in the office or workplace are literally endless. Hopefully you can learn who to avoid and when to avoid them. Also don't be too hard on yourself :-) You can always quit and find another job!

share|improve this answer
Find the job before you quit, a lot of hiring managers won't even interview if you aren't employed. –  Woot4Moo Feb 6 '11 at 3:12

I've never worked in an environment where code is rejected on the basis that certain conventions aren't followed. If I were in your shoes, I would be tempted to look for employment in a place where I'm more empowered to make the right decisions and where the customer is the primary focus, not the code.

I'm not saying clean code and standards aren't important, but the customer and the product timeline shouldn't suffer because of a spelling error in something that no non-technical person, customer, or executive is ever going to see.

With that said, it sounds like you might be working in an environment where expectations aren't clear, or you don't fully understand the requirements, for whatever reason.

Regardless of the situation, it's up to you to take control and ask clarifying questions. Be proactive, if you're not already. Your team members and team lead will likely respect you more for asking questions to clarify the rules for checking in. You could also ask for an "after-action review" where you and your team lead discuss what you should have done instead and how you can tell the difference as far as when to take certain actions and when not to.

I'd suggest giving it time, since you are new, to see if you can get past any hurdles and resolve these issues with experience, communication, and learning the standards. However, if after several months the situation hasn't changed and the environment is still plagued by ambiguity, it may be time to seek employment in another company.

Not every organization is this draconian, and you may find other working environments more suited to your personality, style, and communication requirements.

share|improve this answer

Your Answer


