My team works on a big legacy-code project and most of the team has worked here, on this team, for over ten years. It seems that most of the team have only worked on this project and rarely if ever read books or get up to date on current technologies and standards. I do have one senior colleague who starts his day in later after most of us have been here for several hours, when he is around there is no problem, he says of course and often improves my idea.

Before this job I worked at places that were more advanced, with developers that were more in contact with other developers, and were more up to date on the latest advancements. I am not a very fast developer and I sometimes forget things, but I know about code quality, patterns, testing, etc.

When I run into issues and try to discuss them with any of the team besides the senior I get responses like "you are a programmer you have to know what you do." But to me it seems that the problem is not using the proper standards when coding. When I started I had a hard time getting to know the code (> 800000 lines), I had to ask for help a lot, and I am afraid that somehow affected my credibility. I am a junior and I know that I have much to learn, and I want to learn from the seniors, but at some things my knowledge is more up to date. How can I get them to seriously consider my suggestions. In what way should I bring it up. What practical strategies and what psychological approach would work here?

How can I get my colleagues to seriously consider my suggestions on these areas I think I am knowledgeable in?

  • 3
    @TraLa - I have updated your question for readability and to remove some of the context that is not really needed and makes this question too focused on your specifics rather than the general problem which can help others. I hope this works for you – IDrinkandIKnowThings Mar 27 '14 at 20:39
  • 3
    A system with 800000 lines of code will not substantially change anymore, and forcing different standards on it will give you 795000 lines of ancient code and 5000 of ancient slightly improved code. How much energy are you willing to spend on achieving that? – RemcoGerlich Mar 27 '14 at 21:31
  • Because a rebuild is no option(product is polished by 10 years customer feedback), we do have to get on with what we have to be able to keep up to date. There is an external advisor that helps with stratigic refactoring. He also introduced metrix. On new parts and some strategic places we add tests. (We also have automated test and manual testers) And I am the one that makes a lot of those, so that is why I sometimes suggest changes, to make testing easier. – TraLa Mar 27 '14 at 22:16

The best way to get credibility is produce working code that goes to production before the deadline. So you will need to work within their limitations until you havea track record. Until you have a reputation for producing, it is very difficult to get people to buy off on your idea. Once you have that reputation then you have to work on a reputation for making good suggestions. So carefully pick the first few and evaluate them on not only how good the idea is but on how likely people will be to accept them. You can't get to the hard things until you are able to show some wins, so make them easy wins.

That isn't the only thing though, you have a couple of other issues that need to be addressed. First as the only woman, you may be facing a credibility gap just from that alone and as a junior you may be facing a credibility gap. Junior will go away in time and with accomplishments, so I wouldn't worry about that. As woman in an otherwise all male shop, you may well have to be better than they are to get taken seriously and you need to hone your skills at presenting your ideas. You need to be aware of how firmly you talk.

Just from what you wrote I got the impression of someone with very little confidence. You have to sell ideas from a position of confidence. You need to stand tall and since you are short, stand when others are sitting. You need to look out for using a questioning tone in your statements (where your voice goes up at the end of a sentence) that indicates you are unsure of what you said and automatically gives you less credibility. Many women do this and are totally unaware of how it sounds to others. You need to make sure that you have a stong non-verbal presence. No slumping or not looking people in the eye. You need to push yourself forward and not hang back. So no creeping quietly into a room trying not to be noticed.

It's hard to be the first woman in a group, I know, I did it at a time when women didn't often work in professional positions. You will have to learn assertiveness. You need to defend your ideas, not shut down if someone disagrees. You need to be able to come back and tell them that you considered what they want to do and why you decided on the other approach as well.

You are also going to need allies which can be hard to get when you are different from the others. And in a legacy shop there will be more resistance to change. So pick out a couple of people who seem to be respected (like the senior you talked about) and who seem more open to new ideas and make friends with them and get them to support your ideas. Sometimes it makes all the difference in the world if you can get one guy to stick up for you when you make a suggestion. You might even consider that while you are junior, you might ask these people to present your ideas and watch carefully how they go about getting them acepted. This can teach you what works best in the organization. You might even get one of them to directly mentor you on how to do this.


It's a horrible thing to say but the fact that the developers are stuck in a time warp is a perfect fit for the fact that the code they are working on is legacy code.

I am not sure how that code can be retro-fitted with the up-to-date software engineering methodology that you practice but if you can pull this particular rabbit out of your hat, you're a magician andd my hat's off to you :)

The team is set in its ways - I think that's the only way to interpret your statement that "Most of them hardly made other code, they hardly read books or get up to date. " - but if they see you producing code that's clearly more solid, more reliable faster and with less effort than they are putting in and with less pain than any pain they are feeling, that's what will give you the leverage you need to be well on your way to breaking down their resistance to innovation and relearning that imitation (from them) is the sincerest form of flattery (to you) :) Again, no guarantee though - we are dealing with people and people will react in any way they want.

Your narrative is acting as a reminder to me that in every place that I worked where I was successful, I, as the new person and outsider, brought to the insiders some new insight on how things are done - that's why some employee churn by itself is not a bad thing :) It also led to getting myself promoted faster and closer to whatever level of incompetence (that's the Peter's principle) is mine, as the firm's insiders found that I was in possession of tools and techniques that they didn't have and they definitely wanted to pick my brains :)

  • "the leverage you need to be well on your way to breaking down their resistance". I think that's an idealistic approach at best. – Kvothe Mar 27 '14 at 21:07
  • Kvothe: ... "idealistic" in what respect? I thought that I had lost my idealism long ago :) Having said that, note my caveat: "no guarantee" If the OP can make her own life easier, that still counts as a victory, at least to me :) I gave up on saving the world and saving people from themselves long ago. I can show people the right way to do things and if they don't want to adopt it, I usually don't make an issue out of it - I am usually not in a position where I can mandate change. I am no martyr, and I know that I am not going to win when even showing the best results makes no impression :) – Vietnhi Phuvan Mar 27 '14 at 21:21
  • The employees described in OP's first paragraph worry me. They might perceive OP's changes as personal attacks and I'm afraid that may create a toxic workplace. Did something like that ever happen to you? – Kvothe Mar 27 '14 at 21:34
  • Kvothe: You live in a world where a colleague can lash out at you for your saying "Hello" to him :) If I get attacked under the circumstance you describe, I drop the subject immediately - Once escalation starts, ear tubes close up and we end up with nothing but a dialogue of the deaf, dialogue conducted at maximum decibel volume, of course :) I have almost never been in the situation you describe not only because I have been lucky but because I have been very careful not to be in that situation, and I hope that my combination of prudence and a little bit of luck will hold :) – Vietnhi Phuvan Mar 27 '14 at 23:06

First off, if you work for a company that still mainly supports and runs legacy code you need to be prepared for mainly legacy employees. I have the same issue at my job, old code,old people, old ideas. In the end of the day you often just have to nod your head and agree with the dinosaurs. You are, by modern standards correct but the old dogs will never learn new tricks.

The general trend I have seen recently is many companies are moving their legacy platforms over onto modern web based or mobile platforms. It may be worth your time to start talking about big things like that, who knows you could end up as a project leader on their next big modern platform.

I hate to be rude about it but in todays day and age legacy code is a black hole not worth getting dragged into. My company (and I fight about this all the time) still supports our legacy system even though we have a more modern web approach. There are still some legacy clients that just wont switch. The system has no primary keys in the bizarrely deployed local database, still runs in netscape, and uses 256 colors. We are cutting it lose soon...

People will still take you seriously if you ask questions, they may even like that you are taking an interest in the platform and the older style. The key is to not insult their old ways while trying to suggest new things. This an be tough especially when telling them your new thing may do something different than their code. Don't be afraid to ask questions legacy systems are complex and confusing.

Not the answer you're looking for? Browse other questions tagged .