I was recently hired in a big company (thousands of people, to give an idea of the size). They said they hired me because of my rigor and because I was, despite my youngness (i'm 25), experienced as a C/C++ programer.

Now that I'm in, I can see that the whole system is old and often uses obsolete technologies. There is no naming convention (files, functions, variables, ...), they don't use Version Control, don't use exceptions or polymorphism and it seems like almost everybody lost his passion (some of them are only 30 years old).

I'd like to suggest somes changes but i don't want to be "the new guy that wants to change everything just because he doesn't want to fit in". I tried to "fit in", but actually, It takes me one week to do what I would do in one afternoon, just because of the poor tools we're forced to use. A lot my collegues never look at the new "things" and techniques that people use nowadays. It's like they just given up. The situation is really frustrating.

Have you ever been in a similar situation and, if so, what advices would you give me ? Is there a subtle way of changing things without becoming the black sheep here ? Or should I just give up my passion and energy as well ?

Thank you.


Just in case (if anyone cares): following your precious advices I was able to suggest changes and am now in charge of the team that must create and deploy Subversion :D Thanks to all of you !

31 accepted

I was in a similar situation at my previous company, where I was at for 5 years. When I joined in 2004, they were:

  • still using Microsoft Access for their databases (even business critical ones)
  • using Visual Basic 6 or Access/Excel VBA for development
  • using a lot of third-parties instead of using development resource in-house (business managers led their own development projects and 90% of the time put contracts out to tender without IT's knowledge)
  • gasp no version control.

When I left last year, the company were:

  • using .NET and C# exclusively
  • had banished all Access development
  • using SVN for version control
  • had 2 beefy SQL Server boxes and were migrating existing Access databases to SQL
  • all development came through the in-house teams and only went out to tender if resource was limited

At the time I had not long turned 21, and the next youngest in the development team was 30. I didn't do it all myself. The IT manager had joined the company at the same time, and wanted to bring all development through IT.

SVN was my first achievement. I had a meeting with my line manager, and highlighted a couple of situations where code had been put live or changed that had caused problems, and highlighted the fact there was no accountability - he couldn't blame anyone, basically - and after this he started to listen.

I then put a presentation together to the team and explained the concept of version control, and demo'd a couple of situations where SVN could help us developers out. The younger ones took to it like a duck to water, the older ones not so much but they tried and didn't complain about those that did use it.

Another major achievement was bringing a complete system in-house - I spear-headed a project that saved the company 120k a year in licensing. I spent about 2 months of my spare time writing a new system, and presented it to the IT manager, and explained the cost saving. He then allowed me to present it to the business, and explained how we could implement whatever they liked into the system - no more being restricted to "off-the-shelf" systems.

4 weeks later my system was in pilot in 10 locations, and 6 months later it went live. A year later they cancelled the third-party contract, removed all traces of it from the network, and came to us for a large enhancement requirement to our in-house system.

My advice to you:

  • if you care about the company, stick it out. If others dislike your approach, let them take it up with you - it's all about compromise
  • Tailor suggestions to the person you're talking to - managers like to hear about how they can a) save money, b) accurately blame people when things wrong, but developers like to hear how they can a) save time, b) stick up for themselves, for example
  • if you're passionate about change (which it sounds like you are) then show people your enthusiasm and don't get disheartened when they're less than enthusiastic
  • Don't talk about making changes. Make them. When you start churning out fantastic work in less time than the more experienced guys, people will start asking "why?"

They said they hired me because of my rigor and because I was, despite my youngness (i'm 25), experienced as a C/C++ programer.

More likely because you're cheaper.

Have you ever been in a similar situation


what advices would you give me


Is there a subtle way of changing things without becoming the black sheep here ?

There may be. Introduce changes and demonstrate how they improve things for everyone. After you have done it a number of times, you may get appreciation from those who are not lost.

Or should I just give up my passion and energy as well ?

No way. You're young and you have to take full from opportunities. Don't waste years "somewhere". Look at this position and understand whether it will give you valuable experience to drive your career further. If you see opportunities, explore them. If there are none and it's just "a job", get out. The practice shows, those who lost their passion (or never had it) cannot re-acquire it. Look for a team of passionate people and join them.


Lead by example. Incrementally small change at time. Pull over a colleague and demo something to them. If they don't get it never mind try again another time.

It will take time. Just don't pull people way from their comfort zones too quickly.

Sad but that's why your here and they're not.

For example. Set up version control locally and show them how it can help. Then give them some resources (simple reading) that can back you up.

Another thing about tools. Sometimes you have to spend your own money buying better tools. I know its not 'the done thing' but as I talk to other trades I find many 'real' engineers fashion/buy their own toolsets to do their jobs better. I for one have always done this where I can see that I save my self from skills atrophy.


Find allies who also want to improve the company.

There's something to be said for bailing out now and leaving them to rot. However it will look awesome on your resume if you successfully champion version control and other improvements.

Use the Joel Test during your future interviews. Remember you're interviewing the company too.


My first advice is don't try to change too much too soon. First get a reputation as a good reliable developer who can get things done. Right now as the newbie, anything you suggest is suspicious; they don't know and respect you yet. Get that respect as your first step. Then is the time to start introducing changes.

Choose you ground carefully. Start with version control not new technologies. Because truly that's the most important change. You can even do that just with your code and then make sure that when you have to revert to a previous version or copmpare to find out what has changed, you let people know how easy it was in casual conversation.

Use your more current knowledge to be the person who shines and then people will start to ask how are you getting this done. When pcs first came into the workplace, I worked for a government audit agency. The seniors were all very much against having their own computers (becasue that was work for the secretaries). The juniors grabbed allteh first computers and started doing things the seniors couldn't do with Lotus 1-2-3 and Harvard Graphics and suddenly, the older people were interested because they young guys were getting the attention of very senior management.

Change to an organizational culture is not a technical issue, it's a political issue. Do some reading on managing office politics. You are going to need political support at a high level.


I'm an old man (51) and I've had this same problem at every job I've ever had. Maybe it just comes from always being the smartest guy in the room! :-) Seriously, though, when you know how to do it right and they don't, you often think, "Hey, I'll show everybody this new and improved technique and they'll all be impressed and want to jump in to using it." But in real life, 90% of the time, you show people a better way, and they come up with a long list of excuses for why the way they've been doing it all along is better. When you demonstrate that their reasons aren't valid, they come up with new, even lamer reasons. I've had plenty of times that I've been told that an improvement that would save hundreds of thousands of dollars a year is impractical and unusable because it would require us to rename ten files and that would just take too long, or because it would require us to update the documentation, or because it would violate a company policy (that happens to be a policy under the control of someone who is in the room and who could change it on the spot if he wanted to), etc. (All real examples.) Okay, pessimistic view, but also often reality.

Even if you really are a genius, you have to accept that no one else knows you're a genius until you prove it. I'm reminded of Kris, a friend of mine who started a new job after spending 10 years with one company. Shortly after starting the new job, he was at a meeting where they were discussing some technical problem and he started to offer his suggested solution. Then someone else interrupted and said, "Yeah, thanks. Bob, what do you think?" At first he was annoyed: He knew the right answer, but no one cared! Instead they went with the opinion of someone who knew a whole lot less then he did. But then he realized, hey, at my old job, I had built up a reputation as someone who knew what he was talking about, so when I talked, people listened. Here, I don't have a reputation yet, so no one cares what I think.

I've been at my present job 2 years and it's only in the last few months that mhy opinion has started to have any real weight. You have to be patient.

On the flip side, new people often have a million suggestions for improvements that really are impractical, because they don't yet know enough about the organization and so they don't know why things are being done the way they are. Sometimes people continue to do something the same way for 20 years because that's just the way it's always been done and nobody ever thought to look for a better way; but sometimes people continue to do something the same way for 20 years because experience has shown it to be a good way to do it and every time they try something different it's a disaster. So don't be too fast to conclude all these people are idiots. Find out why they're doing it the old way before you bring out your brilliant new suggestion. I've had plenty of times in my life when I've been embarassed because I come out saying that something the company is doing is stupid and all screwed up and I have a better way, and then someone explains some aspect of the operation that I didn't know about that makes this seemingly bad method necessary, and I have to sheepishly say, "Oh, I didn't know that. Nevermind my new idea, then."


Definitely start using the tools you wish you had locally (where you can - some companies also seem to control what you can install on your box with an oddly tight fist). Set up your favorite version control system and start using it. In any code you touch, make small changes that make the code cleaner, especially where you get to write any new code. If they hired you for your rigor and experience, that means they already respect you.

I recently read Hiring Ren and Stimpy, and found the Stimpy example was a great challenge. If you follow his lead, you'll end up asking (nicely) for all sorts of perspectives from your co-workers, setting you up to have knowledge that a passionless developer won't. You'll spend any spare time you have dreaming up ways to make improvements. If the company sees your work as valuable, you'll become invaluable. If they don't, you'll probably want to be job searching.


I encountered a similar situation at my current job. I was hired straight out of grad school to work on a team that is mostly engineers who have been here 15+ years. Making changes was not easy (I'm still pushing for some things to be done), but it is possible.

For example, my team was maintaining, updating, and using a 16-bit DOS test utility. The utility was a royal pain to update, because the app pushed the limits of the 16-bit linker to the point where if you added code, you had to remove something else in order for it to fit. When asked why we were wasting so much time and energy on 16-bit code, their reply was "because we need it to run in DOS so we can run it off of a bootable flash drive". I tried to convince them to port the utility to 32-bit Linux, but management didn't want to invest the time to do it (we already had too much work to do as it was). So, I went ahead and ported the utility in my down time (15 minutes here and there at lunch, on the weekends, or while I was waiting on other code to compile). Over the course of a couple of months, I had the utility completely ported, enhanced with all kinds of things that the original 16-bit app couldn't handle, and booting off of a Linux flash drive. People noticed when I started using it, and were commenting on how I could get stuff done faster and how my utility generated better debug output. Pretty soon, management heard about it. Once they saw the benefits (and most importantly, that the work was already done), they were no longer opposed to the idea.

The lesson I learned from this story is this: If you think you can improve something, talk to your manager about it. If they don't want to spend the resources on it, do it on your own and prove to them that your idea is valid and useful. It is much easier to say no to an idea that someone proposes than to something that you see in front of you that has obvious value.

Once your team/manager implements your idea and starts seeing the benefits of it, they will be much more likely to listen to your ideas in the future. I used the "street cred" I earned from my test tool re-write to convince my team that we needed to ditch our current, archaic version control system (that will remain anonymous to avoid embarrassment) and migrate to Subversion. I volunteered to lead the setup/migration effort to help ensure that management would approve it.

It's a "one step at a time" sort of thing. There is probably a ton of stuff you would like to change, but pick something small(ish) to start with. Demonstrate the quality of your ideas in a way that your team and manager can't say 'no' to. Just like your stackoverflow account, the more good ideas you have, the better your reputation will be and the easier it will be for your ideas to be accepted.


A lot of people have answered with suggestions to focus on one small thing at a time, and several have suggested version control. I'll go one step further: create repositories on your desktop machine, and work from those repositories. Update them regularly from whatever master repository the company uses. When (not if) there's a crisis because someone damaged the master, tell them that you can cut a new copy from your personal repository.

However, do not under any circumstances put company code on a machine that you personally own or take home. Because then you might find that, rather than being a hero, you're on the wrong side of the desk from a lawyer (at best) or law enforcement (at worst).


Could be an opportunity of a lifetime - changing the way a company works at 25. If they resist though and show animosity all the time it is not the place for you.

Remember, your interview was a two way process. You could have got a feel for how archaic and resistant to change they were.

Ps, I'm 25 too and know how you feel. You're probably a lot more eager to learn and to try new things than your colleagues. Anyway, must get back to this .NET4 work I'm introducing ;)


Quit. There are lots of jobs out there. It's not your job to fix some random company that happened to hire you. They like the way their are, otherwise they'd hire a new CTO or something.


Blend in.

As you said, you don't want to be the black sheep. However, since you (like myself) want to add some useful change:

Add value in the background.

Set up cronjobs to check people's code in to svn/hg/git.. Make your own tools, on your own time, which can demonstrably improve development efforts. In particular, you want to make improvements to the company that you can show your seniors in your own cubicle. And here's why:

Wow factor

If you can say "Hey Alice, you know how Bob just broke the build? I can revert his edit, and the build works again". And when your senior says holy shit, maybe you'll wake up enough passion in them that they'll push through, or at least encourage, your new practices.


Work with management; don't "go rogue". Work within process, and put things into terms people will understand, like "implementing svn will take us space on a server, two days to setup, and we'll need to back it up, but we'll gain x, y, z, which can save us a lot of money."


Coming from another junior developer... do you have great people skills? Do you have an excellent sense of self-restraint and an understanding of when it is and is not appropriate to propose an idea, and how to best sell that idea? Even if you do, you still might end up being "that guy" for telling other people how to do their jobs without proving your worth.

This is how I STILL build my credibility as a junior developer: I identify a kink / kludge / time waster. Then I fix it by automating it (batch files, powershell scripts, simple program, new freeware, whatever on the weekend) without bothering anyone else. I make sure to make it part of my ongoing technical self-education so I can think of it as "putting extra hours in to teach myself a new thing AND help the company".

If my fix is particularly nifty I share it, and say "Hey guys, I made this cool tool, it automates X Y and Z and does this other thing fast." Keep your name on it. Repeat. Credibility problem solved in a few months if you are in a high percentage of performers for your level, and people above you will be more open to your suggestions if you are ready to explain why your idea is good and how it can solve their problems.

Recently I have been able to propose new ideas to upper management that were accepted, mostly because I took the time to explain my reasoning, listen to their feedback, and had the credibility of my past work.

ADDENDUM: If your manager is questioning your behavior... do not do this stuff unless he feels your performance stays at least "top 25%", IE make sure your boss is happy with you before you start trying to come up with all kinds of clever fixes that push you higher into that top % or he will think you're wasting time. If you are throwing out new utilities and solutions while eliciting positive performance feedback yet he still insists on micromanaging you you may have a problem that is outside the scope of this topic.


Here is my advice.

I was in a similar situation, I should first say, my company is pretty small about 6 developers, I am the kind of programmer that likes to use the new technology, new tools and anything that will make my job easier and produce better quality software.

When I started, we were using Visual Studio 2005, when VS2008 has been out for quite sometime, but getting my boss to put up the money the upgrade all our developers was not easy, I had to slowly bring up the idea, as more of a "it would be nice if we could do this", but before I brought it to my boss, would make sure the other developers would be good on the idea, because they would be the ones using it and having an group of people in favor would look less like a one person decision.

I think instead of just pitching the idea to your boss, maybe slowly bring up any possible changes, because I feel if you suggest ideas that will change the company in a better way, also shows that you care about your job and shows that you plan on making a home there.

This would also depend on the work environment you are in and personality of your boss, if they are laid back and treat you like family and take advice, then suggest it, but if they treat you like a number, I would be very careful how you approach it.