I started working at a company that is primarily C# oriented. We have a few people who like Java and JRuby, but a majority of programmers here like C#. I was hired because I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs.

I have recently started on a project building a web application with a focus on getting a lot of stuff done in a short amount of time. The software lead has dictated that I use mvc4 instead of rails. That might be OK, except I don't know mvc4, I don't know C# and I am the only one responsible for creating the web application server and front-end UI.

Wouldn't it make sense to use a framework that I already know extremely well (Rails) instead of using mvc4? The reasoning behind the decision was that the tech lead doesn't know Jruby/rails and there would be no way to reuse the code.

Counter arguments:

  • He won't be contributing to the code and is, frankly, not needed on
    this project. So, it doesn't really matter if he knows JRuby/rails or not.

  • We actually can reuse the code since we have a lot of java apps that JRuby can pull code from and vice-versa. In fact, he has dedicated some resources to convert a Java library to C#, instead of just running the Java library on the JRuby on Rails app. All because he doesn't like Java or JRuby

I have built many web applications, but using something unfamiliar is causing some spin-up and I am unable to build an awesome application in as short of a time as I'm used to. This would be fine; learning new technologies is important in this field. The problem is, for this project we need to get a lot done fast.

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

  • 45
    "Defying orders" on something like this may be a career limiting move. Commented Oct 16, 2013 at 19:07
  • 7
    possible duplicate of How can I convince my boss that ANSI C is inadequate for our new project? Commented Oct 16, 2013 at 19:13
  • 39
    Companies like to standardize on tools because it reduces costs both from a App purchasing standpoint but also in managing company resources. License management is actually quite time-consuming. Additionally, if everyone used their own language/tools of choice then being able to shuffle people between jobs becomes far more difficult. Finally, your complaints about your sw lead are identical to why you want to use your tool of choice. You aren't familiar with mvc4 or don't like it. The sw lead is the lead, so it is their call unless you can present an argument that can change their mind.
    – Dunk
    Commented Oct 16, 2013 at 19:19
  • 22
    This should all have been addressed during your job interview.
    – user16764
    Commented Oct 16, 2013 at 19:24
  • 30
    Are you a programmer or a Ruby programmer? Languages should be just like tools. Some have strengths or weaknesses, but its up to the craftsman to make the best use of them. The company has dictated a standard toolset for obvious reasons.
    – user69037
    Commented Oct 16, 2013 at 22:56

16 Answers 16


I'd say you have to talk to the team lead and say something like:

I know you guys are a .NET shop, but I was actually hired for my Java/JRubyRails skills. I can build this new application in X amount of time using those tools that I already know. I could learn C#/mvc4 like you want, but it will take >> X amount of time. What do you want?

This raises the issue of "skills-you-were-(assumedly)-hired-for" vs. "skills-you-need-now" and also shows that you're willing to learn the new skills, but that it will take longer to develop the new application as you are new to this tool-set. And you do want to show that you're willing to learn new skills. Not being open to learning new skills is a good way to ensure your employment ends when your skills are no longer needed.

As to your question at the end:

At what point should a developer be allowed to choose his tools? Is this dependent on the company? Does my company suck or is this considered normal? Do greener pastures exist? Am I looking at this the wrong way?

It usually depends on the company. If a company buys MS tools and standardizes everything on the VisualStudio platform and .NET framework, it could get very awkward if one developer insists on using Linux and C. That is normal. Exceptions might exist where the company is less fussy about the editors, such as letting developers choose Vi vs. Emacs, as long as the output is the same. I know some companies even let developers choose Windows vs. Linux, but the language they work in has very good support and runtimes for both OSs.

Why do companies do this? Consistency is one reason. It can be very difficult to debug things when the application is a patchwork of binaries built in the favourite languages/frameworks of various developers, built in different tools, and tested on very different systems. If all developers work on mostly similar set ups, those sorts of problems are resolved.

In your case, it sounds like you were hired to work in technology that is non-standard in this company. This seems strange to me, and you might want to talk to the person who hired you about why they wanted that.

  • 31
    "I can build this new application in X amount of time using those tools that I already know. I could learn C#/mvc4 like you want, but it will take >> X amount of time. What do you want?" - Great answer. Frame it in the form of a cost tradeoff. Commented Oct 16, 2013 at 20:22
  • Agreed. It's all about economics. Once you put an economic spin to your viewpoint, ANY lead who's real, will hear you out and reconsider their stance. Make the tradeoff explicit: Ex.: More time implies things will come later implies a deadline maybe missed implying a revenue hit. Sometimes, they need to shown the path to the goal of the 'trade off' in essence.
    – PhD
    Commented Oct 17, 2013 at 1:51
  • 6
    +1. The only way this answer doesn't satisfy me is that it slightly de-emphasizes the learning aspect. A developer who is keen to learn is a far more valuable asset than one who knows everything about one things and will not change.
    – Corey
    Commented Oct 17, 2013 at 4:16
  • 7
    +1 I would also emphasize the (implied) point that if the lead chooses to go with MVC anyways, OP is obligated to buckle-down and do the project in MVC.
    – Dan Lyons
    Commented Oct 17, 2013 at 18:19
  • "Some companies even let developers choose Windows vs. Linux" -- and you'll also often find Mac users too in the Ruby world. (My company is mostly a Ruby shop, but there are no restrictions on editor or OS -- and we have developers using Linux and Mac right now, currently no developers with Windows machines though).
    – Ben Lee
    Commented Oct 21, 2013 at 21:21

At what point should a developer be allowed to choose his tools?

When they don't impact your team.

Am I looking at this the wrong way?


Yes, you have a short deadline. Yes, you could get it done faster in Rails. But the company as a whole needs to deploy and maintain the application. If the company has a stable of good C# developers, then it will probably be cheaper (and yield better quality) to have a C# app to maintain.

Your DBAs and other admin staff are probably familiar with that stack and have processes in place to deploy and update that stack. Even if you can get the code done faster, it might take longer once you account for all of the overhead needed to get a professional web app up and running.

Remember, you're going to spend way more time maintaining your app than writing it. Optimize for that cost.

  • 19
    Great answer. 'Best' in this case may not mean optimizing for the quickest for initial development, specifically for the initial programmer. From the business perspective, the app likely will spend much more time in maintenance mode and supported by the entire team, so that's what should drive the framework decision.
    – Eric King
    Commented Oct 16, 2013 at 19:55
  • 4
    I think this is generally sound advice. I didn't select it as the answer because, in my particular case, a lot of the concerns don't apply. I will be responsible for setting up deployment and deploying the application. I definitely agree with the maintaining part, it is a valid concern. Who knows where I will be in a few years when someone needs to update the code.
    – Spencer
    Commented Oct 17, 2013 at 20:00
  • 2
    The probability is that you actually were NOT hired for your JRuby/Rails skills but you were hired for your experience in building Web Apps and what they're actually looking for is to utilize that in the context of MVC4 and C#. Commented Oct 22, 2013 at 18:45
  • While you make good points, it still doesn't make any sense to have the guy who doesn't have experience in that stack, and presumably no interest in it, to do it. Why not get one of the C# guys to do it? All they're gonna do is make this guy feel like he has no ownership of his projects, and make him feel burnt out, and lead to him leaving the company.
    – s73v3r
    Commented May 26, 2014 at 17:29
  • @s73v3r - I'd hope that the OP knew what he was getting into. Honestly, if you have a boatload of C# devs (and codebase) then that should be apparent to the Rails guy during the interview. If he took the job and then balks at actually doing what he was hired for...
    – Telastyn
    Commented May 26, 2014 at 17:32
  1. You were apparently hired because of your ability to adapt to "new" technologies. C# is no different, in that regard. Are you sure you don't want to take the opportunity to learn something new?

  2. ASP.NET MVC is very similar to Ruby on Rails, in many ways.

  3. You won't be at a snail's pace forever. If you already know ROR, ASP.NET MVC will be a cinch for you. The trick is learning C#.

  • 18
    +1, tying yourself to a single language/framework is silly. Take the chance to get paid for learning new things. And .NET has a lot of active and interesting development going on. Commented Oct 16, 2013 at 19:30
  • I agree that they're similar but there are significant differences that can add up to a lot of hours. Given a finite number of hours for the project, I think rails is the clear choice. I am not against learning new things as I mentioned in the question.
    – Spencer
    Commented Oct 16, 2013 at 19:34
  • Item #1 is not obvious - the OP says that they were hired because of their Java/JRuyb/Rails/nodejs experience: I was hired because I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs. The OP does not talk about their adaptability or that their adaptability is the reason they were hired. Commented Oct 16, 2013 at 19:39
  • 2
    +1, agreed, I've never understood arguments of the genre "I know perfectly well how to do A in language L1 but I'm completly unable to do it in language L2". Commented Oct 16, 2013 at 20:36
  • 2
    @Spencer: When you ask us for advice, and every person gives you the same advice, you should probably accept the advice. There's no point arguing against the answers when you admit, but asking the question, that you don't know what the right answer is. Commented Oct 16, 2013 at 22:08

Arguments for staying with Java/JRuby

Chances are, your boss wants you to produce. They hired you so that you could add value to the company. Ensure that they understand that by forcing you to use a framework that you aren't familiar with they will cause you to:

  1. Produce results at a slower rate
  2. Create lower quality code

Even the best programmers require warm up time with new languages/frameworks.

Arguments for Learning MVC4 and C#

Learning new languages is good. Investing in your skills as a programmer is only a risk if the language/platform you're learning is going to disappear in the near future, and with Microsoft chugging along, I don't think that that's an issue. C# and MVC both have had recent updates improving them both, with even more updates in the pipeline.

Making you, personally, a more well rounded developer will keep you from being put in this situation ever again. The best part? Your boss will be paying you to learn these things, meaning that you get paid to make yourself worth more money.

The Bottom Line

You may end up winning this fight, but you'll be left working with disgruntled colleagues. Just explain the pros and cons of each to your manager and then you'll both come out the other end happier.

  • 11
    +1, "meaning that you get paid to make yourself worth more money" bingo! Commented Oct 16, 2013 at 21:03
  • As this (and several of the answers) point out, there is a tradeoff between initial creation on your time and deployment/maintenance by everyone else. Make a decent (but respectful) effort to see if the Pointy-Hairs are willing to make that trade, but if not just respect their decision and enjoy getting paid to learn something new on company time.
    – brichins
    Commented Oct 16, 2013 at 21:26
  • @brichins: I think one of the big problems with this answer is that it actually doesn't point out what you say it does!
    – ruakh
    Commented Oct 17, 2013 at 3:22
  • @ruakh I was having trouble figuring out which answer to leave this comment on - you're right, this one doesn't address that specific tradeoff (although it does point out the workplace tension that could result). I probably should have also specifically said that the OP should be sure he's talked with all the decision makers (without going over anyone's head) so that if/when the project doesn't meet the deadline, he can politely convey "I told you up front that it probably would. Perhaps for the next project we can try Ruby instead?"
    – brichins
    Commented Oct 17, 2013 at 17:34

At what point should a developer be allowed to choose his tools?

When said developer is the software lead.

Certainly, you can (and should) make the case for using the different toolkit if you're concerned about productivity, but be prepared for an answer you won't like. There may be a damned good reason why your lead wants you to use a specific toolkit, be it compatibility with the current architecture, concerns about maintenance, licensing issues, etc.

BTW, the phrase

with a focus on getting a lot of stuff done in a short amount of time

is responsible for more heartburn and mayhem in the software industry than just about anything else.

  • 2
    +1 "When said developer is the software lead." Exactly. Sometimes, when you argue your point and your Lead disagrees with you, it's because your Lead has a better view of the big picture. This is one of those situations. Commented Oct 16, 2013 at 22:11
  • Disagree. That way you lead your subordinates to nothing else that followers who will forget how to make decisions and take responsibility for them. If you want that - fine. I think there are places where people will be more clever than you as the team lead. But yes, some people have a problem with that, and that's tragic.
    – JensG
    Commented Oct 17, 2013 at 20:02
  • I seriously laughed at your response to "is responsible for more heartburn and mayhem in the software industry than just about anything else."... thank you! Could've not phrased it better!
    – Alexus
    Commented Jun 23, 2015 at 20:36

I note that you don't say you were hired as a JRuby or Java programmer.

Here is why you said you were hired: "[B]ecause I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs."

In other words, they like your web experience and your willingness to learn new technologies.

Now they're asking you to use your web experience and to learn a new technology.

So the question is, are you going to do that, or not?


The Biggest Expense in Software is in the Maintenance of it

I read that the biggest expense (80%) is in the maintenance of software. The initial development is only 20% of the total cost of development.

I read a case about a developer who developed code and comments in his native language (not English) and when the other team members went to enhance and maintain the code, it was next to impossible because the language (not any programming language) was foreign to them.

Similarly, if you develop code in a programming language of your own choice, it would be difficult for other team members to maintain.

Solution: Pair Programming

Consider asking your employers to pair you with somebody else that does know the required programming language and you can work together. You can learn from each other, and if either of you leave the company, the other one would know the code.

Wikipedia Article on "Pair Programming": http://en.wikipedia.org/wiki/Pair_programming

  • 3
    If you write something that only you understand, then you will be stuck maintaining it forever.
    – jwernerny
    Commented Oct 18, 2013 at 12:21

Many companies simply prefer to stick with what they've always done or what's "safe". There's a reason Java and PHP are still very popular. At the moment, searching for "COBOL" on indeed.com returns 2144 listings...that should really speak for itself. The industry doesn't care about good code, it cares about code it can milk for as long as possible (this doesn't imply C# is bad, it really isn't).

Think it about this: the code is going to outlast you. There's a good chance that someone else is going to maintain your code and C# is a safer bet than Node.js and Rails. It wouldn't surprise me if in 5 or 6 years the number of Ruby programmers halved, after all the same happened to Perl and any other language that has been considered at some point the "it" web language. Javascript isn't likely to go away but we're already starting to see it being used as a sort of ASM (or even C) of the web - an intermediate language other languages can compile to so writing server-side code in it could very well become obsolete.

  • 4
    Whilst this is true, it's pretty poor recruitment practice for a C# shop to hire a Ruby developer who doesn't know C#, without making it absolutely clear that the job he is being hired for primarily involves C# development. Commented Oct 17, 2013 at 7:05

My main concern with developers choosing how to implement their goals, is that they normally assume only they will be editting the code. Look at it this way, 12 months later they may need changes; you aren't available (left the company or really busy on another task), and another developer has to churn your code. If its a C# shop, then using their toolset is good teamwork. New technologies should be investigated and implemented, but only when the lead thinks the time is right, as they have their eye on many goals not just one.


Turn it around, please. Imagine you were the one hiring a Ruby developer, and they insist on implementing their work in Asp.net/MVC.

What would you say to them? This is our stack, man. Learn to live with it.

The golden rule, here is, she who has the gold makes the rules.

  • 1
    But why would you hire someone who insists on using .NET for a Ruby role?
    – Bobson
    Commented Oct 17, 2013 at 2:16
  • 3
    @Bobson because they're a bright young programmer who appears to be able to tackle problems with a number of different technologies, solved the general programing problems satisfactorily, and they applied for the job.
    – user40980
    Commented Oct 17, 2013 at 3:28
  • 2
    @Bobson:So now you are arguing that companies shouldn't hire developers that don't have experience in the company's language of choice. Everybody else seems to argue the other direction, where they claim they can learn the new language really quickly so company's shouldn't pass on a good developer simply because they aren't an expert in a particular language....yet.
    – Dunk
    Commented Oct 17, 2013 at 14:30
  • 2
    "I was hired because I have a lot of experience building web applications and because I lean towards newer technologies like JRuby on Rails or nodejs." - this wasn't hired as a XYZ developer, this is "hired as a web developer with experience in newer technologies" (that the company may be interested in updating things to in the future).
    – user40980
    Commented Oct 17, 2013 at 17:47
  • 3
    @Bobson:When I am hired to a new company, not only do I know what I am bringing to the table, but I also know what project I will be working on and what they are expecting me to do on that project. If the OP couldn't be bothered to find this information out then shame on him. With that said, I think this is really a case of the company hiring someone they believe is a good developer with relevant domain knowledge to come in and help the team, with the expectation that picking up the mvc4 stuff is a minor hurdle. Maybe the company didn't explain that well, but the OP didn't do his part either.
    – Dunk
    Commented Oct 17, 2013 at 21:58

There are a number of conflicting goals and the problem is to find the best compromise. We have the deadline, we have an team lead that requests a certain toolset, and we have a developer inexperienced with that toolset but doomed to produce something within a (obviously short) timeframe.

It's important to understand, that the team lead has probably some good reasons why he demands exactly this toolset (one of which could be indeed to get you used to this toolset for some reason that you might not know yet). The best thing you can do at the first run is to find out, what these reasons exactly are.

Put into your position, I would try to talk to the team lead and try to explain the situation, as it is in your view, and the options and which outcome (incl. short-term and long-term economic effects) will be generated following each of these options. For example, another more experienced developer could be assigned to coach you, maybe with some pair programmng sessions or the like.

Unless your team lead is a complete moron, you should be able to find a consensus that makes sense with regard to the project and to the overall goals of the company.


Bah. Everybody is wrong.

Be a better dev than those one-platform people are and you'll have a lot more interesting options than they ever will. So, for now, DO learn MVC. And on your own time, learn more about the platforms that really interest you. Build your Node skills. Learn some Django. Pay attention to whatever Java or pre MVC .NET shenanigans you're exposed to and then run away but at least learn enough to be able to criticize and explain how much thought you've put into your barely concealed burning hate prejudice of those platforms. (okay, maybe I'm projecting there)

And now for the important advice. If you continue to hone your specialities while also diversifying your expertise in other areas, you'll eventually be in a place where you can find new work at any time of the year in less than two weeks in any given major city doing stuff that is mostly interesting at least half the time. When you find yourself in this place, don't put up with these jobs where they say they want this and by day two they have you doing THAT with no hope of a reprieve foreseeable in the long-term future. Just politely explain and apologize but no you really didn't want to do THAT and said as much at your interview and then !@#$ing quit and move on when a couple weeks roll by and they've inevitably done nothing to accommodate for the fact that they misrepresented the position to you and refuse to acknowledge that.

But trust me, finding a new gig is always way better than getting seriously irritated and unhappy for any amount of time lasting longer than 5 minutes. But of course, first you have to pay your dues so you can do that. Some people never will. That's why they want everything in the stuff that they know best. And of course other answers aren't really wrong. It does make sense for a .NET shop to go with .NET if they have to maintain the silly thing.

Of course, what doesn't make sense is why they'd diversify with a Rails/JS/UI dev and only have him do MVC apps. But for now. You may need to pick it up and pay your dues. And as I said in comments MVC's really not that bad. A really bad choice given all the options but certainly not the worst. It's pretty straightforward, doesn't throw 10,000 layers of abstraction on top of everything that's actually happening, and doesn't get itself so twisted with the client-side that you'd curse the names of the MS engineers responsible if anybody could be bothered to learn them.

So get to that place where you can leave when you want if you haven't already and you might even find you have a more skeptical eye of things you currently like. You might even find yourself disliking rails as much as I do. Not that there's anything wrong with Ruby (other than its interpreter of course).


Depending on your situation, it could be dangerous to assume you know why they hired you, and even more so to assume your manager knows that and agrees that hiring people with your skills is a good idea.

I would ask take the advice above and make a business case why you should go with JRuby over C#, maybe your argument and timelines means breaking from the old ways makes sense. I would not just assume it is okay or not, give the manager or lead the facts and let them make the decision, it is what they are being paid the big bucks for, plus its a bit of CYA.


In my honest opinion, one of the things that separates good developers from great is their ability to adapt to new technology. We are living in a fast-paced world where today's top technology will become obsolete tomorrow. Hence, a developer that is unwilling to adapt is of limited use to the company. This would be fine, if not for a little fact that finding and hiring good people is really really difficult to do and when a company finds their gem, they are planning for the long run.

I have seen companies hiring out of their technology scope and they do it for exact same reason. They want to get hands on great developers, even if that means waiting for them to adapt to new technology.

Now to your situation. As a new guy in the group, I would be very careful as to what I say and don't say to my superiors. Sure, you will get away with a lot based on the assumption that you are still in a process of adapting to your new environment. However, undermining authority and stubborn perseverance at your preferred technology will only make your superiors think they did a mistake hiring you and that you are not willing to leave your comfort zone.

What you will pick is up to you, but I would suggest you trying to learn new technology. It won't hurt, I promise.


I'm going to assume that you were honest up front during your interview about your lack of C# knowledge, because if you weren't then you might be in a very precarious position from a legal standpoint.

Good programmers know programming. Whilst nobody can obviously be well-versed on all languages and frameworks, there is considerable commonality amongst most of them. Unless you're being asked to work in a language that's massively different from what constitutes the mainstream these days (Lisp, for example), then a good programmer should be able to adapt.

Naturally there's a learning curve. If the employer hired you then they must be confident in your abilities to follow that curve in a reasonable amount of time (again, assuming you were honest up front regarding not knowing C#). The C# language borrows heavily from Java, and in more generally, most class-based programming languages are fundamentally quite similar (you mentioned node.js, which builds on top of ECMAScript, which is a prototype-based language, so you're obviously comfortable with other programming paradigms.

Good programmers should, in addition to being flexible, be eager to learn new things. In software development you're generally either learning or becoming irrelevant.

Of course your employer, assuming they knew you didn't know C#, has to meet you half-way. If you show eagerness to learn then they have to give you the time and resources to do so. Throwing you in at the deep end is unfair and needlessly stressful. You need to sit down and have a calm, rational discussion with your superior. If they want it in C# then they must be prepared to accept that you'll be on a learning curve whilst working on it and it would be unfair for them to impose tight deadlines on you. If the deadlines aren't flexible and if they are of high strategic importance, then they need to be prepared to allow you some latitude to get the job done within that deadline. If they need it to be in the more commonly-used language in their office, then you can perhaps request to implement it now in what you're familiar with to meet the deadline, and then as your next project re-implement it in C# as a learning exercise and to bring the software into compliance with internal requirements once it meets the external ones. Like I said, most of the more commonly-used languages today have a lot in common so it mostly come down to implementation details.

You do have to be prepared to accept sooner or later that you're working in a C# shop and therefore you do need to have C# under your belt.


Maybe they're not satisfied with the way everyone is using MVC in the .NET environment. There could be too much treating it like webforms. This is no different when someone with a procedural background starts out in OOP, put everything in one big class and goes on with business as usual.

This first project is not the ideal situation because they want this done so quickly. Get up to speed on .NET as much as possible and start cranking out features as fast as you can. You're not going to like the way you're doing things, just try to keep in mind you'll start to refactor this stuff and apply your skills in another language.

Hopefully, your way of using MVC4 (assuming everyone else there is not doing it quite right) in a more Ruby-Style will catch on and break everyone away from the Webforms mentality.

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