You tell your boss something along the lines of "I've never worked with Perl before, and I don't think I'm going to be able to complete the project with the time we've budgeted, since it can take some time getting up to speed with a new language." Then you present options iike using a language you're comfortable in, or lengthening the time that's available for the project.

Often part of a technical job, particularly a technical job with any interesting work or responsibility, is educating your boss about the true costs associated with a decision so that they can make good decisions. If they want you to do it in Perl, that's fine, they're paying for the time and you've informed them why it will cost more than they thought. It's a good idea to follow up with an email restating this so that there's a written record you can point to later when the project falls through.

Honestly, I had expected that you'd refused a project that was unethical or illegal, not that you'd just decided you weren't interested in the stack they wanted you to use. If you told me that story during an interview, I certainly wouldn't hire you. It shows a level of inflexibility as a developer that makes me seriously question if the reason you refused the work is because you're not capable of picking up another language.

Again, my $0.02 - this wouldn't work for everyone. But ...

Above all else, be positive and constructive.

For example, say that your current skills in Perl aren't great, but that you're certain you can come up to speed fairly quickly. Then point out that the work will probably not be of great quality unless you have to time to do that, and poor code executed quickly will certainly lead to more problems further down the line, so you really want to make sure that the company's code base remains clean and without unnecessary technical debt.

Then express enthusiasm again, and ask how you can work together to get the work scheduled to ensure it's of decent quality, while still meeting the company's timing requirements.

Solve the problems, and get the boss involved in solving them with you. Say that you're willing to do it, and welcome it as a learning opportunity.

A point for concern is your response that you're a Java developer with no interest in a different language. I would hope that most developers would welcome the chance to get experience in another language. New languages are either easy to pick up because they're similar to something you know, or hard to pick up because they are extending your skills and making you more able, adept and, in the longer run, valuable.

Try to see yourself as a problem solver, not just a Java programmer.

To generalize what Colin wrote -- this is a method I learned doing business in Japan. You can never, ever say no to anything; the other person would lose too much face. However, saying, "Yes, and..." and then pointing out possible issues that would arise (like Colin's 3rd paragraph) can often cause the decision maker to change the original request, or even decide it was a bad idea on their own.

Of course, sometimes, you end up doing the work anyway, but the 'disclaimer' in your "Yes, and..." give you a position in which to work where your boss implicitly buys into those limitations -- this is also a better thing.

"Yes, and... {limitations}" instead of a no is always a better answer to a superior. Most of mine have seen the light after discussions like this when something was a bad fit or bad idea.

On the other hand, sometimes I ended up having to do the undesirable. Take pride in what you do, no matter how undesirable, and you will find yourself building excitement for your work. You may discover you learn some cool stuff along the way, too.

Best of luck!

> A point for concern is your response that you're a Java developer with no interest in a different language.

It's not that I'm not interested in a different language (besides Java I use other languages, too), it's just that I was not interested in Perl.

I agree with you about the value of learning new languages, but I think you are more successful in learning a new language when you learn it because you want to learn it, and not, because you must learn it. Intrinsic vs. extrinsic motivation.

I'm more successful in pretty much any task when I have no deadline, five highly competent assistants and a private masseur for whenever I'm feeling stressed. But if I was only willing to work that way, I'd be living on the street. Being a professional means getting the job done even in suboptimal conditions.

Yes, that's true, though I think being a professional also includes the option of saying "no" (on how you say it, that's another question).

No, you can only say "no" if you're a self-employed professional like a doctor or lawyer or consultant with his own practice. Then you have the choice of whether to take on a potential client or not. However, a professional who works for someone else has to take on their employer's priorities. That's the deal you sign up for when you become an employee; that's what you give up for a regular monthly paycheck.

If you're very valuable to your employer, you might be able to get away with saying "no". But most people are not indispensable, and if you say "no" too many times, your employer will start looking for ways to replace you.

Those are valid reasons. I coded a fair amount of Perl a decade or so ago, and I wouldn't be wild about having to do more of it, never mind learn it nowadays. But it doesn't sound like you were approaching the conversation constructively.

Why is it so important to your boss that the project be done in Perl? You need to understand this so you can see if there are other avenues you can pursue that will make him equally satisfied. For example, using Ruby or Python.

And why is it so important to him that you do the project in Perl? As you said, you don't even know Perl. Why isn't the project going to someone who does know it?

If you're lucky, there will be some alternate win-win path to helping your boss accomplish the goals he wants accomplished without getting stuck doing work you really don't want to do. Or you may have to sign up to do a certain amount of scutwork, but get your boss to agree that once you're through the current crisis, you can move on to a path that you will find more rewarding. If a good boss understands your career goals, he will work to find a way to help you work toward them. And the better you are at helping your boss solve the problems he faces, the more likely you are to discover that you have a good boss.

Of course, it's also possible that the reason you're being assigned this task is something to the affect that there's a lot of other Perl in the company, and the company wants to crosstrain people in Perl. Perl is just part of the deal there.. In this scenario, not learning Perl is effectively declining to develop essential job skills, and your only realistic option may be to suck it up until you can go find a better job. Just be glad it isn't COBOL! (Sorry, gallows humor there.)

> Why is it so important to your boss that the project be done in Perl?

It was an existing project developed by the client, and they used Perl. So the technology was fixed.

> And why is it so important to him that you do the project in Perl?

That wasn't important, I was just the guy with some free capacity.

> As you said, you don't even know Perl. Why isn't the project going to someone who does know it?

There was none who knew it (at least as far as I know), the company was a Java shop.

I am in this situation constantly. Bosses very often don't realize when they're making unreasonable demands, and it is sometimes your job to give them a reality check. But you don't just tell them no. Here's my script:

"OK, I'm totally on board with what you want to do, but I wanted to give you a heads-up about some problems I foresee. You want me to do Really Hard Thing and have it to you by Friday, but as embarrassed as I am to admit it, I don't think I'm quite good enough at Really Hard Thing to have it in a condition I'd want to present to you by Friday. I mean, I'll give it my best, but I felt like it would be irresponsible not to tell you so you could make a decision with all the relevant information. If I can make a suggestion, I think it might be better if we do More Reasonable Thing. It seems like the ultimate goal is to do X, Y and Z, and More Reasonable Thing will still do all of that. Alternatively, is there any wiggle room in the schedule so I can make sure you get it in the condition you're expecting?"

Sounds like one of my projects, Perl as well. What did I do? I manned up and got it done. I took on a load of technical debt to do it, but that didn't matter, because the cost of missing the deadline was higher than the cost of sorting it out later (which another team is doing in C# I believe).

What exactly do you think you do that the company pays you for? It isn't programming. Programming is just a tool you use to solve business problems.

Explain the risks as clearly as you can, and if your boss finds the risk acceptable, proceed. As long as you are communicating, it will be a project failure, not a personal failure. Don't be combative about it, make sure everyone fails and learns together :)

Good: clearly tracking the risks as the project progresses.

Better: pushing yourself to learn Perl and mitigate the risks to the best of your ability.

Best: spend some OT implementing it in Java and show her why it is better (or show yourself why it is not).

You tell them you're not comfortable with the timeline and Perl but never refuse. Try your best. Maybe you learn something, maybe you don't. That's work!