Bait and switch job offer - what to do?
July 6, 2009 4:17 AM   Subscribe

What should I do when the job I agreed to take isn't the one I'm actually doing?

The situation is this: (sorry for length)
I'm a software developer, and I was contacted by a recruiter for a company that seemed to be interesting. They're making money, growing (100+ people, incl. 15+ devs) etc.

The first two interviews seemed to be all small-talk (which should have been a warning sign), but when I pressed and got some details, it sounded to me like the job was going to entail a lot of maintenance on a complicated codebase, and not too much building new stuff, which is what I wanted to do. So I told them my feelings, and they brought me in for a third interview with the CIO during which they finally laid out some details about their plans, technology etc.

It sounded like they actually did have some new initiatives to work on coming up, and they were making me a decent offer during a time where my independent practice was suffering from lack of clients paying their bills. Also, they're a high-traffic site, and I figured I'd learn something about scaling and performance from people smarter than me. Plus the usual options BS - "we're a year and a half out from an IPO..."

So I took the job.

Two days after I was hired, that CIO was fired.
For a couple of weeks, I've seen nothing being done but maintenance on some of the shoddiest code I've ever seen. "Quick and dirty" is the rule of the day.
The site does do volume, but it is totally jury-rigged, and I've seen them have to shut down parts of it to keep other parts going. Security issues abound.

They do seem amenable to cleaning stuff up, but it is like attacking the NYC sewer system with a toothbrush.
For someone who takes a lot of pride in his work, even being made to read this code is frustrating.
Lastly, management is very weak - there is very little direction from above, so I'm left to refactor stuff at random, it seems.

Now, I'm wondering if I should contact the recruiter who pushed me into this, since she at least has something to lose if I quit.
Or should I keep my mouth shut, take the paycheck and look for another job?
Or should I talk to my manager (or at least the person I think is my manager, since they're really unclear about structure) about maybe getting a little more work in areas I prefer?

Money is tight, but it wouldn't be too hard to switch, I think. However, there is an opportunity here to make a big improvement, if I can get enough help to make the cleanup effort realistic.
posted by bashos_frog to Work & Money (15 answers total) 2 users marked this as a favorite
 
Why not talk to your manager about your concerns first, and look for another job? If nothing has changed by the time you find a good one, then consider taking it.
posted by Flunkie at 5:00 AM on July 6, 2009


if I can get enough help

Address the if with your manager (or whomever). If it is not being addressed, look elsewhere.

In general, always be on the lookout for elsewhere, esp. when things look dodgy and unstable at best.

As to your initial observation, that the job you got is not the job you thought you would get - pretty common thing, really.
posted by IndigoJones at 5:16 AM on July 6, 2009


it sounded to me like the job was going to entail a lot of maintenance on a complicated codebase, and not too much building new stuff, which is what I wanted to do.

So, wait--what's the problem? Legacy code sucks, but it seems like that's what you wanted. You even say they're amenable to making improvements. Unless, there was a communication issue:

Company: "complicated" means massive, insane, jury-rigged, spaghetti

You: "complicated" means elegant, complex, beautiful and interesting

If this isn't what you want, I'm sure other people will give good suggestions, but be clear about your perspective vs the company's. And don't insult their code explcitly--it'll sound like complaining when they thought that's what you were hired to do.
posted by zeek321 at 5:19 AM on July 6, 2009


zeek321, Its an ambiguous statement but in context I read it to mean: what he wants to do is building new stuff, not maintenance of a complicated codebase.
posted by missmagenta at 5:32 AM on July 6, 2009


zeek321, Its an ambiguous statement but in context I read it to mean: what he wants to do is building new stuff, not maintenance of a complicated codebase.

oops, I think you're right
posted by zeek321 at 5:51 AM on July 6, 2009


The key to negotiating with your boss is having a good option.

If you don't have another job lined up, your boss just has to say "No. Now get back to work."

If you do have another job lined up, explain to your current boss that you want to do new development now, or that you want to run a team that cleans up old crap before you and your team move on to new development, and that the people at another company have made you an interesting offer. Then be ready to walk if your boss says "Sorry, we need you to clean up tedious old crap forever while our other programmers get to do the interesting new work."

So go find another job (and not through an unreliable recruiter) and then talk to your current boss.
posted by pracowity at 6:14 AM on July 6, 2009


It's moot anyway, once you're done building something from scratch, you have to maintain the mess anyway.

No, seriously though, this is pretty common, IME. Not a lot of places are going to hire someone cold to write a complex system from scratch unless they are a startup. I'm currently in the process of migrating our pile of junk to a shiny new codebase, maybe if you stick around you'll get the chance to do that.. It can be a pain, but if the pay is good and you take the attitude that it's a challenge rather than an your skills being underutilized, it could be rewarding.
posted by cj_ at 6:16 AM on July 6, 2009


The key to negotiating with your boss is having a good option.

If you don't have another job lined up, your boss just has to say "No. Now get back to work."
This may be the way it is in some situations, but I don't think it's good as a blanket rule.

It depends upon your boss, and also what is in it for them. In this case, it sounds to me like the OP can make a reasonable case: Not merely "I was told I would be working on something new", but "I've worked here for several months, and I've noticed the following problems: Blah blah blah. These result in our frequent outages and other production problems. I think it would be wise to start a new system from scratch, taking into account all the lessons learned from the current system, while we simultaneously maintain the existing one until the new system is ready. Here's how I would do it: Blah blah blah. Oh, by the way, when I was hired, I was told I would be working on something new, so if you decide to go with this new system, I would appreciate if you would consider me to work upon it."

And simultaneously start looking for another job, without mentioning it to the boss, in case the answer comes back as either "no" or a bullshit "yes".
posted by Flunkie at 6:22 AM on July 6, 2009


I would start looking now for another job no matter what.
posted by heather-b at 6:22 AM on July 6, 2009


I've been in a situation much like yours.

Or should I talk to my manager (or at least the person I think is my manager, since they're really unclear about structure) about maybe getting a little more work in areas I prefer?

It doesn't hurt to talk to your manager about it, but don't expect much. If the entire codebase is like that, it's a problem with culture and engineering values, not some temporary high-pressure situation. Most likely, you'll get some lip service or some talk expressing sincerely good intentions, but either way, it takes a really long time for a company's culture to change.

Let's take the best case scenario and say they really, honestly want to move toward maintainable, well-structured code. Are they going to do this by rewriting a major module tomorrow? Probably not. They've made their bed, and now they have to lie in it to keep their business going in the short term. Refactoring is a luxury for most companies, even ones that have the same outlook on development that you do. It could be a a year or more before you are given a chance to straighten anything out.

Talk, but also start looking. Carefully.
posted by ignignokt at 6:35 AM on July 6, 2009 [1 favorite]


You can't fix the problem. Some projects deserve to die, and they need to drink fresh blood from victims' painful wounds just to keep moving. You do not have to volunteer to be that victim.

Discreetly find something new. *Then* plainly and clearly talk to your manager about what you want from that company. You will have a definite plan by the end of that conversation.
posted by cmiller at 6:54 AM on July 6, 2009 [3 favorites]


when I pressed and got some details, it sounded to me like the job was going to entail a lot of maintenance on a complicated codebase

This isn't a bait-and-switch; they told you exactly what you were getting into. It sounds like even the CIO was pretty clear with you in explaining the future initiatives were in the future, not the present.


Changing a corporate culture like this can be frustrating and unrewarding work. On the other hand an unclear, weak management structure and the freedom to refactor code at will can be its own reward. There's a lot to be said for turning crappy code into good code.

I'd say don't bother trying to fix the whole company. But go to town fixing the part of it you're responsible for.
posted by ook at 7:20 AM on July 6, 2009


when you become an employee of an organization, it's your job to act with the best interests of the company in mind, not yours. the company hired you because they needed someone to fix code, not sit in a corner and develop new applications. yeah, the new stuff is fun, but it's not what's needed. it's quite possible the CIO was canned because they were too preoccupied with new projects as opposed to fixing the current mess.

you do have a new project to work on--cleaning the code. did you expect work to be easy? often it isn't. if you're really as good as you imply, this is within your range of skills. don't be some whiny prima donna sitting in a corner who's complaining because they don't like the work--just shut up and do it. if you're really unhappy, quit, go back to consulting or try to find a job where you can do exactly what you want--maybe you'll find one, but chances are you will not.

otherwise, get back to work.
posted by lester at 7:26 AM on July 6, 2009 [1 favorite]


I like what Flunkie wrote.

Another suggestion that's helped me in the past: Keep track of the measurable improvements that you're making to the existing codebase. Things like "Important Process Number 3 required 35 seconds before refactoring, 2 seconds after, with a decrease of 75% in average database CPU load." Or even "Cleanup of the Foo Module reduced source lines of code by 1,320, improving maintainability."

That kind of thing feels good and makes the current job less of a slog. It also goes (in aggregate) on your resume and (with specificity) at the interview for your next job.

If your team is not using version control (boo!), do it on your desktop, then export your commits to wherever they would go. Tracking your progress with "svn log" is also motivational.
posted by jmcmurry at 8:14 AM on July 6, 2009


Best answer: I'm currently in a very similar boat. With the added "plus" that I can't even get the tools (local db, testing libraries, etc.) I need.

For the first month I fumed; I just couldn't understand how everything on this very high-profile project could be so ad hoc, or how the management was so loose, or how basic basic standards weren't followed.

And I'm still fuming, but I'm also going through the code, and making positive changes. Taking pride in doing stupid scut-work well. And I'm -- very genially -- complaining. Pointing out that this is bad, and that is bad, and "so I changed it in my local copy, and I'll commit it to SVN whenever you want". Sending emails -- that no one cares to answer, pointing out that "this cost us X hours of debugging, and here's my plan to avoid that".

And developing a Plan B to get another job.

Develop your Plan B, and meanwhile, take it as a challenge to see how much you can improve what they have, without just throwing it all out, while gently awakening them to the realization that they're doing it wrong.

And if you need to rant, please feel free to mefi-mail me.
posted by orthogonality at 8:51 PM on July 6, 2009 [2 favorites]


« Older What is this amazing eggplant dish?   |   When registering a domain name, should I pay -... Newer »
This thread is closed to new comments.