Is it ever worth asking a question if you know the answer is "no"?

Question

I'm a relatively new Programmer (2 months) at a relatively small company. I've been tasked with coming up with a solution to a problem we've had, and I've thought of two ways to tackle it.

Option A is a pretty average solution. There's really nothing that special to it, but it gets the job done.

Option B also gets the job done, but it's far more clever. It's a little faster, and it only works because it takes advantage of a few ways our system is set up. The problem is we'd have to make a small change to get option B to work (one I'm not allowed to make on my own).

Since I'm new, the problem I'm approaching isn't very significant in the grand scheme of things, so there's honestly not a huge benefit to using B over A. The change we'd need to make is also pretty insignificant, but since no solution here really saves the company too much time/resources, it's probably not worth making the change. It makes more sense to do option A.

However, if I just did A, then I'd report back to my boss "the problem's solved, I did blah blah blah..." and I don't think his perception of me would change at all. Which isn't bad, necessarily, but also isn't really good.

I know for a fact that if I approached him and asked "I've come up with two options to solve the problem, A and B. B's better, but we'd have to change the whatever," he'd say to just do A. But I feel like it gives me an opportunity to flex my "brain muscles" a little, and to also show that I'm picking up on details in the way our system's set up. It is showing off a little, but I don't think it's obviously showing off, and honestly, I don't know that showing off to your boss a tad is strictly a bad thing. Especially for newer employees where people are still trying to get a feel for what you know.

Is it worth asking about B even though I know my boss'll say "no"?

As a more general question: Is it worth proposing a solution you know will be shot down if it demonstrates things you know (or have learned)?

Answer 1

Is it worth asking about B even though I know my boss'll say "no"?

I would say yes, its worth it because if nothing else you are building your reputation within the organization. Your are also practicing your soft skills, which will be a big benefit to you down the road.

And finally, who knows for sure if the answer will be NO until you ask. If you don't ask you will never get.

Update based on comments:

There are entire books on how to ask for what you want. I would say that you should use a fact based approach to justify what you are asking for. In fact, you can use this approach for virtually all your professional requests.

Some insights based on my experience include:

1. Understand your boss ( or the person you want something from ), and their needs and limitations.
2. Be sure you can demonstrate why what you are asking for is good thing.
3. Include any relevant industry or supporting data to back up your request.

Answer 2

It's worth discussing your line of reasoning with your boss:

• State that you can think of 2 ways to solve this.
• Explain the trade-offs of each one.
• Tell him which one you plan on going with.
• Ask if that makes sense or he agrees.

This shows that:

1. You have the technical knowledge to come up with A and B.
2. You understand the trade-offs (including the financial side) to make the best decision yourself.

Do NOT ask whether you should do B or whether you should do A or B, because this will show point (1) above but may send the opposite message for point (2). Even if you ask which one to go for while presenting the pros and cons of each (as opposed to asking whether he agrees with the one you plan on picking), it may still show that you're not really capable of making this decision yourself.

---

As long as you don't overdo it, there shouldn't be much harm in just getting a second opinion or approval regarding what you plan on doing and it would generally be seen as a strength (because no-one wants a loose cannon that will just do whatever they think is best without consulting anyone else).

Answer 3

Based on your description, Option B might introduce complications in otherwise stable software, so you should expect some risk aversion if it adds little value.

That said, there's nothing wrong with mentioning it in passing. State the couple of benefits you see, the downsides, and why you suspect it's not worth doing.

For all you know your boss and your colleagues might envision other benefits, think about potential side effects from their perspectives, and decide it's actually better.

Answer 4

I'd put it slightly differently. I'd say something like: "I have come up with two potential solutions. B has some benefits but I think A is more practical. I'd recommend implementing A. What do you think?"

That way you're giving the lead all the information you have and letting him/her know what decision you would have made. A good lead will either agree with you or explain why they don't.

BTW there's no need to consider this as showing off. What you're doing is passing on what you've learned and making a recommendation. On the assumption that this isn't a test i.e. the lead hasn't already decided, this is precisely what they should be looking for in a junior.

Answer 5

There's an important factor in this that I don't think any of the answers to date have addressed; you're new to the company.

As a general rule, I would be inclined to say that (assuming no performance difference between the two options) the option that's "clever" and takes advantage of how the system is set up is probably not the best solution, simply because it's clever (and thus presumably not something the next guy to look at things would immediately intuitively understand), and because it takes advantage of how the system is set up (meaning that if we decide to change how the system is set up months from now, we may have a little time bomb, as portion of things that we wouldn't expect to be affected, but which stops working when the system is updated).

But - you're new. You don't know if there are reasons why the system is set up the way it is. You don't necessarily know if the company has been considering changing things significantly, and if your ideas would clash with that, or go right along with it.

So, this isn't just an opportunity for you to show your boss that you thin outside the box - it's also an opportunity for you to learn more history.

Knowing the history behind a project can help you understand why certain decisions were made, why people may be averse to certain directions or changes, and may provide a idea of where things could head in the future. This can be enormously useful. I've been in situations where simple knowledge of the history of a system has been able to prevent potential disastrous changes from being made.

So, approaching this from not just a "we could do this two ways, and I think this way is the way to go", but a "does one way or the other fit better/worse with upcoming plans/ideas?" helps make this less about how smart you are and what a great fit you are, and more about you developing a deeper understanding of the system.

Ultimately, the real conversation may not be with your boss, but with other team members, of course. It's up to you to figure out if it makes more sense to talk to them first, or your boss. If someone's acting as a mentor, that may be the person to approach.

Answer 6

I propose another solution:

Don't ask. But... mention it in passing

You say, your task was to come up with a solution and that's Option A. So after you have informed your supervisor of Option A, you could then mention Option B, like

"I noticed that, if there was change X to the system, a solution like Option B could work and would have the following benefits..."

You would still show, that you came up with a creative and clever solution. If your supervisor thinks it is worth a shot, he can tell you (or may at least think about it). However, he doesn't even need to respond, in case he doesn't consider it (so you demand less of him, than if you had asked him a question). So you accomplish the same, but with a reduced risk to get a "No" as an answer.

Answer 7

First of, you can never be entirely sure of what people might say or think. Maybe your boss will think idea B is a great idea. Maybe with his more advanced knowledge of your systems, he'll find that the benefits/drawbacks from method B are bigger than you anticipated.
Or maybe he won't and pick A instead, but presenting other options won't harm your reputation, quite the contrary.

It shows you've given the problem some thought, and from what you say, it shows you have assimilated how things are set up at your new place as well. As such, it shows some of your qualities to a boss that doesn't really know what you are able to do yet.
It's not showing off as long as you don't over-emphasize how "clever of an idea" it might be when you expose it to your boss.

I would advise you to present both options while remaining factual.
"These are the solutions I've come up with to resolve the problem : option A and option B. I think B would make things faster but implementing it would require us to change X".
Leave it to your boss to decide if the changes necessary for option B are worth it or not.

Answer 8

For me personally, I always ask because the worst that can happen is my boss saying "No". A majority of my best projects that I thought were out of reach (either due to status, experience, politics, etc.) became a reality because I asked.

Answer 9

If you are so sure the idea will be shot down, you need to ask yourself why. Managers in general are not accustomed to rejecting ideas that are honestly beneficial to the company. Evaluate the reasons and eliminate or mitigate them if you can before going to your boss. Your best approach is often to say something like:

I had considered doing it this way, but I think that's not the best course of action because of these reasons...

This can sometimes trigger ideas in colleagues of ways to make it work, or alternate/compromise solutions that didn't occur to you. Sometimes all you can do is make a plan to slowly migrate away from a legacy solution. People working together can come up with better solutions than separately.

Answer 10

Politically, it is often good for you to show your boss your thought process and what things you considered and how you made your choices. So yes go for it even if you think he will not like one or more of the options. If you are going to do this, you will look better to your boss if you are convincing. So present it in a way that management will understand.

When I have two or more possible options, I write it up as formal decision analysis and present it that way. That way the person can see the pros and cons of each option and, more importantly, they see that you thought out the possible solutions.

I generally recommend the the option with the best numerical score, but if he disagrees with my scoring, then we can adjust it on the fly and see what happens.

How to do a decision analysis is the question. In a spreadsheet you set up the decision factors. These are the things that are the basis for deciding which is the best option. Each factor gets a weighting factor which indicates how relatively important that factor is. Then each option is placed against the top. Each option is numerically rated against each ranking factor. Then multiple the weighting factor and the numerical score to get the total for that factor for each option. Then sum them together to see what is the best one.

A sample shown below:

Answer 11

It is my opinion you need a third option. As you seem to understand, companies do not like to make changes outside of the immediate project and your boss may not even have a say in the matter regardless if it is the best way to do things. This has to do with the logic of a business (politics, finances, etc.) the likes of which I am ill-equipped to advise on directly. Therefore, if option A is not so great and option B will be thrown out on grounds of business logic, then you should need an option C that is better than option A and more business like than option B. Without an option C, I would present option B first because it would seem a better solution if it is approved and the external changes can be made. Option A would then be a fallback in the event that all else fails. Presenting option A first or along side option B will cause options other than A to not be considered because option A seems to be the easiest path. Such has been my experience in similar situations.

As pointed out in a previous response, be aware that "clever" is not necessarily "better". Benefits such as reduced processing time, smaller memory footprint, maintainable code, time to implementation, ease of future maintenance, staying within budget, and mitigating man hours are the kinds of things that make a solution "better". Do it fast, do it well, and you will earn your prestige.

Answer 12

It is probably not a mistake to mention that you are aware of a more clever approach but chose not to take it. I would however not ask, for two reasons.

First, being rather new, you may have to ask things at other occasions. You do however not be the guy who always asks the most trivial things, i.e. the guy who is totally incapable of doing one thing by himself. As a programmer, you're a problem solver, go solve your problems.

Second, "clever" is usually less important than getting the job done and being general or portable. In fact, most business solutions are not clever at all, they are abysmal. However, as long as they work good enough so there are no complaints, that doesn't matter.

You mentioned that A will "just work" whereas B would only work for your particular system, and even so it would require a small modification. This is something that will almost certainly provoke a negative reaction. With any luck, you'll get Tony Hoare quoted on you. If you're less lucky, you'll get something less polite.

A solution that works only on one system is usually no-go. Optimizing where there is no urgent need is usually a no-go as well.

Answer 13

There are a lot of good answers, but the title question was "Is it ever worth asking a question if you know the answer is no?" The answer to that is "Yes." There are many reasons you should ask a question even if you think the answer is no. It could be documentation purposes (CYA), or it could be so that everyone knows what the policy is on a certain issue.

To your more specific question, readable code > clever code. But if you have a better solution than the one proposed, you should either implement it, or at least present your case. Steve Jobs once wrote a proof that reducing boot time from 30 seconds would actually save lives. Most importantly, you should be learning, and your company wants you to be learning so that you stay useful, whether they know this or not. Doing the best solution you know how is important to your development.

Also, when you're presenting your case, don't say "this isn't really going to help, but..." List the ways in which it will help. Saving the company hours per year could save them tens of thousands of dollars, depending on who's effected by the code.

Answer 14

Can you do both?

bool bBeClever=false;

if(bBeClever)
    impressiveWay();
else
    boringWay();

Better yet, instead of making impressiveWay and boringWay() entirely different functions, can you make one function that can do either, based on a boolean (preferably alterable at run-time by using a passed parameter or other such variable)?

That's my advice that feels rather tailored to this specific question (about computer programming). Next, here's some more thoughts that may be more likely to be usefully applicable in other scenarios (in other businesses).

If the approaches are so fundamentally different that you really need to do only one or the other, possibly because you don't have enough programming time to do both, then just do whatever is wisest (that is: most easily maintainable with possibly changing circumstances, most likely to get approved by superiors, etc.) but document the other other option. Even if you don't get credit for completing the other option, your cleverness can live on by anyone who is reading the code's comments and/or documentation. Making such a note can also provide value, by letting people remember that there is this available optimization method that could be pursued if specific needs/priorities every change. Hopefully your boss ought to appreciate such added value.

When I was being paid for programming, I know my supervisor significantly appreciated many ideas I passed along, even ones that didn't end up getting implemented immediately.