4 ms·

> And if your boss hired to to work on a project, don't refuse to do it; otherwise what did he hire you for? The project was in a programming language I didn't

> And if your boss hired to to work on a project, don't refuse to do it; otherwise what did he hire you for? The project was in a programming language I didn't know (and it wasn't used at the company) with a tight schedule. And I knew I wouldn't be able to finish it in time in the quality I want to provide. Plus as a Java developer I wasn't that interested in that particular programming language (Perl). How else would you handle such a situation?

ColinWright 15y ago
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.
- peapicker 15y ago
  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!
- throwaway789a 15y ago
  > 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.
  - chc 15y ago
    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.
    - throwaway789a 15y ago
      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).
      - deleted 15y ago
        [deleted]
      - greenyoda 15y ago
        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.
  - 15y ago
trickmonkey 15y ago
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!
warwick 15y ago
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.
thwest 15y ago
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).
chc 15y ago
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?"
gaius 15y ago
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.

ColinWright 15y ago

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.

peapicker 15y ago
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!
throwaway789a 15y ago
> 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.
- chc 15y ago
  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.
  - throwaway789a 15y ago
    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).
    - deleted 15y ago
      [deleted]
    - greenyoda 15y ago
      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.
- 15y ago

trickmonkey 15y ago

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!

warwick 15y ago

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.

thwest 15y ago

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

chc 15y ago

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

gaius 15y ago

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.