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.


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 !

6 months later

I quit and found a much more interesting environment, with a much better pay, and more interesting challenges. I wouldn't go back for anything.


16 Answers 16


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?"
  • 20
    "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". Yeah, the cost saving of having you work for free! If it saves £100k+ a year you should have sold it for £50k!
    – John
    Commented Mar 31, 2010 at 15:28
  • If I thought I could have gotten away with it without being sued I would have done!
    – Andy Shellam
    Commented Mar 31, 2010 at 15:49
  • 3
    @John You should present it to the IT manager, explain the cost saving, let them have it for free... and a few months later ask for a big pay rise citing the cost savings as an example of your worth.
    – MarkJ
    Commented Jul 25, 2013 at 10:44

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.

  • 5
    lot to be said for that. Leave now and don't get stuck. Commented Mar 31, 2010 at 13:28
  • 7
    This is hardly an answer.
    – Ricket
    Commented Mar 31, 2010 at 13:29
  • 5
    If I change now, what am I'm going to say on my next interview ? "I quit because they lived back in the 60's" => I will probably make me look as someone who gives up before even trying. Maybe I will quit in the future, but think I must at least try for some time.
    – ereOn
    Commented Mar 31, 2010 at 13:38
  • 15
    You're young. Its perfectly acceptable to say that the company was not a good fit for what you wanted to do and that you made a mistake. Commented Mar 31, 2010 at 13:42
  • 3
    The company has had years to implement changes you are suggesting, but they haven't. That's a sign that they have chronically under-maintained their development shop. It's a good sign that even if your changes deliver all the "good stuff" without any hitches, you'll just get to work with new tools in a branch of the company that will still get neglected. If you do decide to stick it out, do what you can to make your life easier, but remember that every change is a headache in such an environment; they're used to what they have. Management should have driven this, years ago.
    – Edwin Buck
    Commented Mar 31, 2010 at 14:05

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.

  • 3
    Ugh. Spending your own money, what a mug. Unless you think you'll get a salary boost from increased productivity, what exactly are you gaining?
    – John
    Commented Mar 31, 2010 at 15:29
  • 2
    @John - more satisfaction and comfort whilst at work. If all I've got is Notepad and the company won't allow me to buy anything else, I'll buy a copy of UltraEdit myself and use that instead, because it makes my life easier.
    – Andy Shellam
    Commented Mar 31, 2010 at 15:52
  • Easier how? Unless they recognise you are getting more done, why bother?
    – John
    Commented Mar 31, 2010 at 16:27
  • @John I use this simple logic more productivity => more time to learn => more marketable skills => (a) better engineer (for me) (b) better money (c) better projects Commented Mar 31, 2010 at 19:56
  • 1
    @john. The other answer is that my tools and mastery over them is what I sell. It certainly was in my consultancy days. A couple of hundred dollars in buying a tool is no different to buying books. Commented Mar 31, 2010 at 19:58

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

  • Thank you very much. You couldn't have described what I feel more accurately ;) I'll do my best but that will be hard, I am a very maniac person.
    – ereOn
    Commented Apr 1, 2010 at 6:46

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

  • 1
    Great story and lesson! +1 :)
    – Ricket
    Commented Jul 1, 2010 at 17:53

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.


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

  • 4
    Unless they've given you a work laptop to work on, where you have the source code anyway, and they expect you to take it home with you...
    – Paddy
    Commented Mar 31, 2010 at 14:02
  • Perhaps, although I'd hesitate to do so. Crises often lead to blame and recriminations. And if the person (usually the IT or Development manager) who should be blamed for not protecting the company's assets (source code) can deflect attention from this fact with "why did this person take home historical copies of the company's source code?", he/she probably will. HR doesn't understand source control, but does understand theft of intellectual property. Of course, the Dev Mgr could always say "I screwed up and this kid saved us" ...
    – Anon
    Commented Mar 31, 2010 at 14:33
  • @Anon, in the country I live in, we have the most protective laws for employees. It is really hard to fire someone, even when he does something wrong. If you loose confidential data on a laptop that was given to you, it is still very unlikely that you get fired. Can seem weird, but that explains also why so much people don't care about doing their job well...
    – ereOn
    Commented Jul 1, 2010 at 18:19

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.


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.


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.


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 ;)


Read Getting Things Done When You're Only a Grunt by Joel Spolsky.

...sometimes you don't have the power to create change in your organization by executive fiat. Obviously, if you're just a grunt programmer at the bottom of the totem pole, you can't exactly order people to start creating schedules or bug databases. And in fact even if you're a manager, you've probably discovered that managing developers is a lot like herding cats, only not as fun. Merely saying "make it so" doesn't make it so.

It can be frustrating when you're working in an organization that scores low on The Joel Test. No matter how good your code is, your coworkers write such bad code that you're embarassed to be associated with the project. Or management is making bad decisions about what code to write, so you're forced to waste your talent debugging the AS/400 version of a retirement-planning game for kids.

...dealing with life on a bad team can be infuriating. But there are strategies for improving your team from the bottom, and I'd like to share a few of them...

  • 1
    This post is really nice, but it is a lot harder to do it than one might thinks when reading...
    – Uooo
    Commented Jul 25, 2013 at 6:53

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

  • At our level, money is not something to take into consideration. We are even told NOT to look the prices. I'll replace that with "the time-gain argument". ;)
    – ereOn
    Commented Mar 31, 2010 at 14:38

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.