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.

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.
–
JobFeb 6 '11 at 4:19

4

@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? :)
–
MackeFeb 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
–
JobFeb 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.
–
MackeFeb 6 '11 at 19:42

2

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".
–
RigMar 9 '12 at 14:58

9 Answers
9

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.

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. :)
–
jmort253Feb 6 '11 at 5:34

11

@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).
–
user1249Feb 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.
–
jmort253Feb 6 '11 at 19:32

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.

+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 DurrantJun 2 '14 at 11:51

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.
–
MrDatabaseFeb 6 '11 at 3:19

4

@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

3

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.
–
MrDatabaseFeb 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. LoweFeb 6 '11 at 3:48

1

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.
–
jmort253Feb 6 '11 at 5:41

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

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

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 KingFeb 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.
–
JobFeb 6 '11 at 15:34

Nowhere in your post do you mention how others around are treated. You keep repeating that you "feel" you're being "singled out" because you're "a woman".

I think you're being treated like a junior programmer regardless of your gender and you should be thankful for that, because that's what equality means. I also feel you're making a huge fuss over minor, 5-minute-long code aesthetic changes that you're being asked to do now instead of putting them on a to-do list and never getting around to them.

Nowhere in your post did you mention you were ordered to do these things on the weekend. It might be perfectly fine to check in the fixes on Monday morning.

Your team lead might be a little pedantic for my tastes, but from your post I don't see anything wrong with his or her requests.

Please stop playing the gender card for nothing. I feel this is undignified and undermines the concept of gender equality.

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!

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.

It is hard to say anything useful as someone who neither saw your code nor knows something about your projects schedule. But, if your lead behaves responsibly and does a good job, he knows, that others weren't really blocked and the sprint won't be late. So, do not worry about that. Perhaps you overrate the impact on your commit. Otherwise: if your project is time critical and passes all tests, it would be too picky to reject code, which could be fixed after the release in a blink of an eye.

So, if your lead made the decision to reject your commit, as a professional he should know, what he was doing.

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

As a Junior it is hard to find ones way into a companies codebase.

Best: there are documented coding standards - and you will hopefully learn to get grips on them.

Usually: there are undocumented coding standards - and you have to learn via trial and error or should I say commit and _reject? This is oftentimes painful (as in your case). This is sometimes dangerous in terms of code quality and could lead to cargo cult programming, where one not only mimics variable naming, but copies and pastes structures and patterns from the code base in good faith, it has to be done like that. Do not do that! Do not even mimic existing variable naming.

Stick to Clean Code. It is good practice and gives you an easy to defend position. If it is readable, testable and maintainable code, you mostly have won any discussion.

And this leads to another (the last) advice: Follow the boy scout rule!

Always leave the codebase in a better state, than it was. Even if the surrounding code you are working with is nasty, make yours clean - and if you have time fix the surroundings.

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.

This doesn't seem "draconian"; consistency is an important component in maintainability, maintainability is an important component in quality, and quality software has a much greater chance of shipping on time and at less cost than 'compromise code'. It might be encouraging that something like 80% of software companies are eager to compromise quality and suffer the consequences, so there doesn't seem to be any shortage of "non-draconian" employment opportunities. :)
–
weberc2Mar 20 at 19:08

I wouldn't want to work in an environment where basic conventions are not enforced. If a project gives up on defending its coding guidelines, it's doomed to become unmaintainable in the long run. Especially variable naming is not a petty thing: No matter how much existing code called a certain matrix A, I would never accept a commit that calls another matrix B for consistency. Of course, I don't know what the OP meant by "mimicking [...] names used elsewhere" precisely, however, given the quality of some code I've seen, it might be along these lines.
–
cmasterJun 6 at 21:28