Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Wanted: Experienced Delphi programmer to maintain ginormous legacy application and assist in migration to C#

Later on, as the new hire settles into his role... "Oh, that C# migration? Yeah, we'd love to do that. But management is dead-set against it. Good thing you love Pascal, eh?"

I've noticed quite a lot of this where I live (Scotland) and I'm not sure how common this is across IT: a company is using a legacy technology and they know that most developers will avoid them to keep mainstream technology on their resumes. So, they will put out a advertisement saying they are looking to move their product to some hip new tech (C#, Ruby, FORTRAN 99) and require someone who has exposure to both - but the migration is just a carrot on a stick, perpetually hung in front of the hungry developer as he spends each day maintaining the legacy app.

I've experienced this myself, and heard far too many similar stories to the point where it seems like common practice. I've learned over time that every company has legacy problems of some sort, but I fail to see why they can't be honest about it. It should be common sense to any developer that the technology in place is there to support the business and not the other way round. Unless the technology is hurting the business in someway, I hardly see any just cause for reworking the software stack to adhere to whatever is currently vogue in the industry.

Would you say that this is commonplace? If so, how can I detect these kinds of leading advertisements beforehand?

share|improve this question

closed as primarily opinion-based by MichaelT, GlenH7, david.pfx, Ampt, gnat Jun 17 at 0:14

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

19  
Commenters: comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you don't think this question is a good fit for this site, please vote to close or down-vote it. If you'd like to discuss this question with others, please use chat. See the FAQ for more information. –  user8 Sep 1 '11 at 19:08
3  
@Chad, I believe I've said twice that this is not a rant. I've made an observation based on my own experience and based on what others have told me. The question was aimed at learning the reasons behind why companies do this and I also felt the answers would be of some use to other people. Again, I'm open to suggestions towards rewording the question. Some of the answers provide useful insight. If this question does not fall into the guidelines, then close it. I'm not interested in arguing over the subject, I asked this for "constructive" input. –  Desolate Planet Sep 1 '11 at 21:08
1  
Edited to emphasize what appears to be the core question, while deemphasizing your bitterness over being done wrong. –  Shog9 Sep 1 '11 at 21:25
2  
@Desolate Planet - I'm from Scotland too and I have experienced the exact same problem. –  Ozz Sep 2 '11 at 9:59
1  
@James - It is common across industries. Employers embelish job descriptions and seekers embelish their resume. It is not just programming. –  Chad Sep 2 '11 at 16:25

15 Answers 15

up vote 51 down vote accepted

Yes it is a bad idea. If you attract somebody who is strong in that skill set, presumably they have other options, they will more than likely leave. If you attract somebody who is not strong, presumably they don't have other options and misled you as well, they will stay but not be the candidate you were hoping for. Either way you are worse off than you were before.

The secondary kicker is that kind of place gets a reputation for that sort of practice and becomes avoided by potential good candidates.

I've seen this many times.

share|improve this answer
5  
This in a nutshell. The only people who this company will keep are those too timid or lackluster to have any better options; anyone with any ambition or skill will either see through the deceit or leave within a week (or similar short period of time, maybe not necessarily a week) when it's clear they were lied to. –  Wayne M Sep 1 '11 at 18:09
    
@Gratzy, agreed. The IT industry here is pretty weak in terms of job opportunities and most folk take what they can get. It's a sad sight. I'd like to see the IT industry here flourish, but I think being honest would be a good start rather than taking liberties to get more applicants coming in. –  Desolate Planet Sep 1 '11 at 18:17
1  
@Desolate Planet unfortunately most things are supply and demand driven and it sounds like the employers have the leverage in your case. –  Gratzy Sep 1 '11 at 18:20
    
@gratzy - Maybe they leave maybe they stay. But if youjust ask for a pascal programmer who want to have no prospects to grow with the company... no one is going to apply. Better to have an unhappy developer to support while they stay than no programmer and needs for changes to the program. Sucks to be the programmer but if that is your need then it is effective. –  Chad Sep 2 '11 at 16:27

Never attribute to malice what can explained through incompetence

I've seen this a few times, but I'm a bit more sympathetic: I blame incompetence rather than malice here. It's not even usually an individual within the organization, but the organization itself and the natural pressures and incentives at work.

What happens is that an organization, team, or manager decides they need to do the migration. Management buys in... they want this, too, and of course they want to use their existing programmers. Unfortunately, being new to the technology the existing programmers lack the skills for a good migration. To make it happen, management needs to bridge that skills gap, and they have four options: training, consultant, contractor, and permanent hire.

Of those, consultant is out, because keeping them around long enough to accomplish the knowledge transfer needed is prohibitively expensive. Training probably will happen, but it's not enough by itself; it would be like filling the team with new college grads and expecting expert-level work. A permanent hire sounds like a good solution at first, but there are two common mistakes here that doom you to the specifics of the original complaint:

The first is that this is, as stated, a permanent position. That means the new technology is at least one salary more expensive than the old technology right from the get go. That's not gonna make management happy long-term.

The second is that you are asking the new hire to come on board as an authority in an area (the new technology), but they come in with no knowledge of your legacy application, infrastructure, and problem domain, and no real authority in terms of seniority or title. You're asking the impossible.

Instead, this kind of project is the perfect job for a contractor. What you want is a contract position lasting several months, where the first several weeks or months are spent studying the existing application, in design for the new system, and in project planning. No "production" is expected from that early work, expect perhaps a diagram of the existing system (to prove understanding of how things work), a project plan with a timeline for the migration, and design document of the new architecture... but no actual code yet. Even later, this person may end up doing more code reviewing than writing, to help your existing team learn the idioms, quirks, and tricks specific to the new platform.

Unfortunately, finding a good contractor is extremely difficult. They are out there, but the field also tends to be littered with programmers who couldn't cut it at as full-time employees. Management knows this. They also know they can address the extra salary problem by not replacing the next dev who leaves the team (you can already see where this goes now). The result is a often a new permanent hire, and the effects described two paragraphs above and in the original question start to really kick in.

share|improve this answer
    
+1 for the (allegedly) Napoleon quote ! –  Newtopian Sep 7 '11 at 5:08
2  
Very insightful. I happen to be one of these permanent hires that replaces legacy coders -- however the new project never started and has changed directions so many times that I'm still band-aid-ing the existing software in... gasp VBScript. –  sholsinger Sep 7 '11 at 14:27
    
I like the qualifier you put in for "good" contractor, as contracting is the norm where I work. Even more so with the state of the economy, companies just want people to come in, do work for 3-6 months then GTFO. I find that they cause some problems outside of this context though. In one department I worked in, we had a Python script talking to a Java web app, which worked with Perl scripts. I was told the app was this way because the contractors than came in only knew specific things and due to time pressures, they didn't have time to study the existing app and standardize on a technology. –  Desolate Planet Jan 3 '12 at 18:22
    
@Desolate : Why can a contractor come in and do the job they way you describe when a new full-time hire cannot? Please explain, I know it happens a lot, but I cannot see the reason for it. –  mattnz Sep 17 '12 at 3:02
1  
@mattnz Perm hire for this would typically only have experience in the target platform of the conversion, has no seniority, and no knowledge of your existing system, but will be expected to lead the project. The ideal contractor has experience in both platforms, exists outside the normal seniority pecking order, and can focus on learning the existing system early without needing to produce anything in terms of patches or features on the current system, in a way that would be hard to allow a perm hire to do. –  Joel Coehoorn Sep 17 '12 at 4:11

Being deliberately deceptive is certainly a nasty way to operate and will result in high-turnover.

However, even if everyone is totally "honest", how often does a job description truly reflect reality? Most jobs change over time. At best, the job description is a snapshot of what employer "thinks" the job means at the time of hiring. Perhaps in some cases there is a true desire to migrate technology but it just isn't possible for various unforeseen reasons?

share|improve this answer
1  
I agree with your assessment on the fact that the migration may not happen for various reasons, but I first noticed a problem in week 2 of my job when morale as really bad and there was an aggressive attitude towards management. The person I replaced walked out in day 3 of joining the company, yet I stayed because it was my first job and I was a graduate with no experience at the time. It was a case of "don't look a gift horse in the mouth", but in hindsight, I think it would have been better to tell the truth. –  Desolate Planet Sep 1 '11 at 17:28
    
@desolate Yeah, that case certainly sounds like outright deception! Something is wrong with that place. –  Angelo Sep 1 '11 at 17:31

Of course this is a bad idea. Not only does the company bring in candidates under false pretense, but they will quickly gain the ire of many interviewees. This practice does nothing but harm to the organization's reputation, and wastes interviewees' valuable time.

I would personally find ways to make it public:

  • identify the company/organization
  • how the (false) pretense was presented
  • what the organization was actually after
share|improve this answer
2  
Outing the company for what they did sounds like it would feel good, though I can't imagine they'd respond favourably in any way, they might respond with lawsuits (frivolous, but still a nuisance to deal with)? –  FrustratedWithFormsDesigner Sep 1 '11 at 17:14
1  
@Frustrated: and misrepresentation, fraud absolutely don't come to mind... ;) I see what you are saying, though. If they are that hard up to find someone to maintain legacy cr@p, they should go to oDesk and hire a $15/hour consultant. –  IAbstract Sep 1 '11 at 17:18
1  
@IAbstract, $15 sounds like an incredible bargain. A lot of places do this because a good C# contractor will cost them around $40-80 an hour after the contractor company takes their cut. Good Delphi and Cobol programmers are rarer and command CONSIDERABLY more. –  maple_shaft Sep 1 '11 at 17:27
3  
@maple: $15/hr is an incredible bargain - but you get what you pay for. –  IAbstract Sep 1 '11 at 17:42

I hate to break it to you, but things change. The priority back in June when a job ad was written - moving from technology A to B - very well may not be the priority in September. Or that was the presumed plan by one technical manager, who left, and its no longer the plan with the new manager. Thats just the way the world works. I wouldnt start attributing the change in job description to deception unless you have some additional supporting reasons to make that conclusion. Doing so says more about you than the company.

Is it common for the job and description to differ? Sure. Job descriptions rarely portray the actual day to day position 100% correctly. At least I've never had a job that matched the job opening perfectly. Its just a matter of the opening often being filtered through a number of people, with different understandings of whats going on. Again, not malice, just bureaucracy.

How do you handle it? Tell the people who want to hire you that you'll be out the door if the migration doesnt start within X amount of time. If they dont hire you, you'll know they werent serious about it.

share|improve this answer
1  
Grandmaster, I agree with what you've said, but I've sat in actual meetings where management have suggested throwing in some vogue technologies that we don't use just to bring people in and to also say in interviews that management are looking at gravitating towards those technologies when they know full well they aren't. This made me think of my own experience, which prompted me to put the question forward in the first place. I guess it comes down to a company selling a bill of goods to attract some people because they can't afford a contractor. –  Desolate Planet Jan 3 '12 at 18:25

This sounds like a very bad idea. If I took such a job, I would ask during the interview about the details of the migration. If anything failed to materialize about doing that actual migration within 6 months (sometimes these things take time), I'd probably start looking for a new job.

Fortunately, I haven't encountered this myself, and haven't heard any stories from others who did, until now.

share|improve this answer
1  
The thing is, if you ask during the interview "When will the migration begin?" you won't get an answer to that question, at least now one you'll be happy with. –  Desolate Planet Sep 1 '11 at 17:16
1  
@Desolate Planet: I guess if the interviewer has a set of lies and stories ready and prepared then it will be difficult to catch them. I wouldn't simply ask one question, I'd try to probe with different questions about the migration, from different angles. It helps if you've done similar migrations already so you know what to ask. ;) –  FrustratedWithFormsDesigner Sep 1 '11 at 17:19

If by bad idea you mean, is it against their own self interest, then it's probably not a bad idea. It's unethical and exploitative (and the people on the site would be the ones on the exploited side of the relationship, were it to happen to them) but it's probably not actually a bad idea (in terms of the employer's self interest).

This assumes that the management is correct in deciding to keep (in the words of FrustratedWithFormsDesigner ) an ancient, heavily patched, poorly documented, festering pile of code rather than replace it. But if they did replace it, the truth is there is a good chance that the management is responsible for the originally software being a heavily patched, poorly documented, festering pile of code, and they may well end up with a shiny new festering boondoggle.

So why not pay the least possible for software you're only going to screw up anyway? It makes sense in it's way - if you're a dysfunctional company then why not know you're a dysfunctional company and plan accordingly? Assuming lying to people and damaging their careers isn't a concern to you.

share|improve this answer
1  
I appreciate and understand your logic but the reason that the new software will also be crap is because the management does not actively try to promote an environment where the smartest and brightest want to stick around. What you have left are the stupid, the angry and the demoralized and when you form a team of stupid, angry and demoralized people you end up with crap software. –  maple_shaft Sep 1 '11 at 23:29
1  
I agree. But if you're in this situation you probably can't distinguish the smartest and the brightest from the stupid, and everybody is usually angry and demoralized anyway. So why not have your code written as cheaply as possible? The people you lie to were going to leave in a bit in any case. –  psr Sep 2 '11 at 0:05
    
Well I think Jeff Atwood would disagree with you but it is nice to hear some solid opposing viewpoints. –  maple_shaft Sep 2 '11 at 1:07

Just like you wouldn't keep an employee who lied about credentials, employees won't stay at a company which lies or bends the truth unless they're totally desperate. I have encountered this: There is a local company here notorious for stating they are looking for .Net developers when 95% of their application is a horrendous cesspit of Classic ASP/VBScript garbage, and making the defense that only senior people get to do the .Net work. They do this because they know they would get nobody except desperate people in need of any job or the absolute dregs of our profession to ever work for them if it was immediately known they have been using obsolete technology with little plan to move.

TL;DR version: Of course it's a bad idea. A company is welcome to do it but shouldn't be shocked if/when people come in and leave immediately when the truth is known.

share|improve this answer

How common lying is probably varies from place to place, but in my own experience exaggeration is very common, and lying is not that rare either. A few years ago I was promised some capable developers in my team but the small company where I worked as the lead developer ended up hiring the cheapest labor available to save costs; further back when I worked for a software giant, they employed me as a developer but the actual job was testing.

Some managers / business owners do not understand that not meeting promises and letting developers do what they love sabotage morale, which in turn may significantly adversely affect work quality, because software development is creative work and requires a good mood.

OK, enough ranting. I'd like to share my two cents in helping detect whether the technology migration from advertisements are genuine.

To reduce the chance of being fooled by a potential employer, I myself now use the following tactics wherever possible during job hunting.

(1) Ask for a trial day (or a couple of days) before signing up. Explain to the employer that hiring the wrong person can unnecessarily cost a fortune (if a developer formally starts and then quits after finding out the facts, the employer would have to re-advertise, pay another headhunting fee if they use an agent, go through the interview process again, and not to mention the lost opportunities and revenue). Some employers will agree, because they would like to see how good the developer is at real work anyway. During the trial a developer would have the perfect opportunity to see some code, how decisions are made, and product backlog / road map (could be strong indication of migration timeframe and strategies), if the employer allows.

(2) If trial day is impossible, ask to meet the senior developers. During the conversation, try one's best to ask in-depth questions involving the advertised technologies. If the seniors are knowledgeable in that area, or better yet, talk about some recent experience on applying the knowledge, the company is likely to be on the right track towards the advertised technologies. If the seniors do not know much about the technologies (they just thought it is cool to migrate to the new technologies but have not done much research yet, they will probably be busy maintaining the legacy and forget about the migration in a few months), or sneer when talking about the migration in question (their developers may be wanting the new technologies for various reasons, but probably have had difficulties convincing the company to actually start it), the migration is not likely to happen soon.

(3) If the state allows public access to previous legal decisions, search for employment relationship decisions involving the company. Most companies have clean records, but if the potential employer has lost in more than a couple of employment cases, their history of integrity and honesty should be questioned, so should the genuinity of the advertisements.

(4) If all else fail and one absolutely wants to work for the potential employer knowing the risks of not having the promises met, at least apply game theory during negotiation. Make it clear to the employer that being interested in learning and applying the advertised technologies is the biggest factor in deciding to take the job, the candidate is firm to quit the job if the promises are broken, and insist to have the migration work as part of employee performance review. The potential employer will think twice before deciding to lie, knowing that the candidate is not someone who will patiently wait for three years before the actual migration.

I know as a developer we should not focus too much on certain technologies. Instead we should learn more about a company's product, business and process, using the technologies just as a tool. However, I do believe developers should have access to true information and be able to choose the type of work (overall labor market is a free market in most regions). A company that cannot keep promises (with reasonable circumstances), or is unwilling to invest (given that it has the capacity, and benefits can be clearly seen), or wants to mislead potential employees (instead of treating them like a future partner / comrade), will unlikely to flourish and thus working there can be a waste of time if one wants to be successful.

share|improve this answer
    
Like most of the answers, I'm curious as to the definition of "Wrong" developer. I think Chad highlighted this when he said that a company would rather have an unhappy developer for 6 months then repeat the cycle rather than have an expensive contractor. Anything to keep pushing the envelope further... –  Desolate Planet Sep 18 '12 at 21:28
    
There is some good stuff here, but I'd like to address the "trial period". Where I live, employees are typically give a 6 month trial period. During this time, either the employee or employer can void the contract. The main issue with this is that people are conscious of keeping their resume clean. If I jump to another job after seven months, the company interviewing me may be very skeptical about taking me on. Similar to credit cards, you need a good credit history to get the best deals in the market. –  Desolate Planet Sep 18 '12 at 21:45

It is sadly all to commonplace. When a company does not have standards set and enforced it tends to run into problems retaining high quality developers. In addition when they fall behind in the technology curve it becomes harder to attract developers to support there mission critical applications. As they lose their developers their ability to adapt to business requirements falls. The idea is you slap a bandaid on the wound and stop the bleeding. When the wound festers up you get another bandaid. Eventually a new bandaid will not be enough to deal with the problem. At this point a new solution will be enacted quickly and probably with out consideration to actually supporting it. So the cycle will begin again.

If HR is honest about the position it never attracts anyone. Chances are there is someone in the organization that hopes to make it better. Maybe they will get lucky enough to find someone that can both keep it up and running and make a new system that will actually improve the situation. Usually the new solution will come from a canned product sold by some contractor and will just change the problem instead of fixing it though.

The best way I have found to identify these postitions is to ask some specific questions that are easily answerable by a company with standards in place and a working process but will give you answers that do not acually mean anything if they dont. If it is a migration in the future ask about the timeline for it. Ask about the potential problems they forsee with the migration. If they have not identified any problems then they have not taken a real look at migrating and may not. You can also ask about the migration path. If they are actually planning this they should be able to talk about it in concepts. You may not understand any of it but if they can talk about it then there is a better chance of it being real. If the refuse to talk about it or give vague general answers this is a big red flag and you should try and probe more.

share|improve this answer

The simple solution to this is to require to have your working technology and a description of your future job being written into your contract.

share|improve this answer
1  
Sounds great in an ideal world, but I doubt companies would have clauses like that in place as it could work against them. –  Desolate Planet Sep 2 '11 at 10:24
    
In Germany that is common. And provided you are referring to a dynamic and free job market, then an employer will put everything in the contract that is in accordance with his goals to get you, if he believes in you. If not ... then this is a sign for a discrepancy ... for example he thinks you're in no position to actually choose anyway ... OR ... he's not honest - like in the description you give. –  Raffael Sep 2 '11 at 10:28
    
@Desolate - Then you could walk away if they are unwilling to sign something that they are saying is the truth. You can not make people be honest, just make them pay for lieing. –  Chad Sep 2 '11 at 16:31

Yes it's pretty common. Migrations to new technology will be sold as being hours away instead of months or years being the most common. No, actually using an agile development style is probably the biggest lie, migrating to the greatest and latest (or at least current) is next.

It's your job as the candidate to weed out these issues, so feel confident to ask for time frames to migration, whether there's a project plan, estimated completion, resources, etc.

share|improve this answer
    
most companies don't know what it means to be "agile". I previously worked in an investment bank and the team claimed it was "agile". We did SCRUM meetings and had an "agile" tacker, but all the reporting and approvals for code changes etc, invalidated the agile aspect of the team. Getting a working build on demand would take 3 management approvals and a whole host of red tape to cut through. –  Desolate Planet Sep 6 '11 at 19:19
    
In a positive light, you'll get more money working with a niche technology like Delphi/Smalltalk, but if the general morale in the office is bad and the team is constantly griping and moaning about how management won't fix things, it's a major put off. –  Desolate Planet Sep 6 '11 at 19:22

Bait and Switch is the oldest trick in the book. Whenever a migration plan from legacy technology is mentioned in an interview, it makes sense to dig in for details ("How long has this plan been in place? What has prevented you from moving forward on it? How much progress has been made so far?"). Be sure to ask people at the working level, not just managers.

PS> I've been down this road too, unfortunately. I quit after realizing the legacy stuff was never going away; the VP had built his career on it and was frightened by anything newer.

share|improve this answer
1  
I did ask probing questions in the interview. If a company says they've got high turnover, I want to know why. And usually I get the "They just didn't enjoy the work...". I ask why they didn't and they just say they don't know. With regards to migration dates, the typical response is "Management are still reviewing the steps required". Well, why the hell have you even put migration on the job spec in the first place if it's still early days? –  Desolate Planet Sep 6 '11 at 19:12
1  
+1. Digging in is really important if you see a danger sign. –  Scott Wilson Sep 6 '11 at 21:03

This is a bad thing to do deliberately. In relationships (business, professional or even personal) dishonesty means amassing social dept (the counterpart for technical dept in social structures).
Sooner or later you will have to pay for this. Plus it will always bother you, taking away your focus from the things that are really important. It is a waste of time and energy.

Now about the concrete situation you're talking of: this can often happen unintentionally, especially, when there's a communication problem of some kind between the people involved in the hiring and the people actually running the whole project.

It can well be, that the hiring committee thinks, that C# migration is a good idea. It may even be, that management clearly acknowledges the advantages of the migration. But when it's really about scheduling it, they simply put it off indefinitely, because they don't think that the advantages are actually worth the effort.

For example I had once been in a situation, where I got hired as an AS3+PHP programmer to write the networking layer of a multiplayer game. As it turned out, our publisher (who create games themselves) insisted on creating the server software in-house. It actually took about the first 8 weeks of my employment to come to a point where this became clear, because the communication between the studio that hired me and the publisher was not very good concerning this matter.

So I wound up writing an abstraction layer over a web services created by 3 different successive programmers. That was not nice. The nice part was, that I shifted towards optimizing the 3d engine we're using in the frontend and write a lot of nice internal framework code, dealing with all sorts of things I was never intended to touch when joining the team.

In the end, this can always happen to anyone. But as an employer, you should clearly communicate, which of your plans are actually being realized in the foreseeable future, and which of them are just options you're currently considering. And as an employee, you should use the interview to figure this out, simply by asking concrete questions about schedules, milestones, teams etc.

share|improve this answer
    
I think it's good to explore outside your comfort zone as a developer. For example, I did Smalltalk in my last job, which is even rarer than Delphi, but they were honest in what you were going to be doing. A lot of the comments here seem to state you can ask in the interview more about the migration, but you won't get concrete answers. I guess it's down to you at that point to decide, but if you've got a legacy problem and people are walking out the door, I think it's time to ask for help, but acknowledging you have a problem is a good first step . –  Desolate Planet Sep 6 '11 at 19:07
    
I agree. Some of this can't be helped and in some occasions, there can be a misunderstanding of what's required. In the example I gave, the company knew it has massive technical debt. For example, they wrote a database from scratch in Delphi (which was the first thing a new start came running to the dev manager in disbelief). A lot of the Delphi houses in the area I live know Universities are putting out Java/C# developers and they don't want to put forth the cash to hire a proper contractor to do the job –  Desolate Planet Sep 6 '11 at 19:23

My recommendation is to only do what is in alignment with your career path. I recently started consulting for a small software firm on the premise that they wanted to migrate to using Entity Framework, and eventually move from classic ASP to ASP.NET. After writing a nice Entity layer for them along with rewriting one of their applications using it, talk started to come about how they want me to possibly write a mobile iPad application and do some Apple development. Unfortunately if that is their next idea for me, I will leave because that is not aligned with my career path in using Microsoft technologies.

Like others have said based on their experiences as well, this small firm is one that has no real practices in place and is really far behind on the technology curve. I am strong in my skillset because I have made good career choices to stay within that skillset. If I jump around from technology to technology it is not attractive to serious employers on my resume and I won't get taken seriously for a position that requires strength in my primary skillset, and honestly I have career goals that matter to me.

Don't let yourself fall into a position where you stop using your primary skillset and strengths, and don't let yourself fall into a position where your skillset starts moving in the wrong direction, or worse, backwards. If you are in a position where it all comes down to money, stay but definitely be looking for an out and take it as soon as its available. The worst thing you can do is fall into an unhappy career.

share|improve this answer

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