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

  • 37
    So is Option B objectively better than Option A? I see you say it's more clever and a tiny bit faster, but more clever does not necessarily mean better.
    – David K
    Commented Aug 4, 2017 at 15:17
  • 52
    Here's another question for you: which option is more sustainable down the road? As in, if tomorrow you got hit by a bus on your way to work, could anyone else support option B? And will option B restrict/change how you approach problems down the road?
    – tonysdg
    Commented Aug 4, 2017 at 16:10
  • 19
    You shouldn't let you code base suck just to cover the hit by a bus scenario. As long as it is a fair standard pattern that just requires a few changes (and maybe a little knowledge) it’s worth looking into. If we all just wrote the easiest to read and maintain code all of our code would suck and we would never get better (Just think of a team that’s still using .Net 2.0 without LINQ because extension methods and queries in code are scary.) Commented Aug 4, 2017 at 16:19
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Aug 7, 2017 at 21:50
  • 2
    A "trick" that relies on a few ways your system is setup has a specific description: "Brittle." The trick is not in creating something that works. The trick is in creating something that doesn't stop working. Commented Jan 2, 2018 at 6:40

14 Answers 14


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.
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Aug 7, 2017 at 21:43

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

  • 1
    Pretty much what I would have said. Present the options and their trade-offs. It might turn out that your Boss sees an advantage in one that you (as the new programmer) weren't even aware of. Commented Aug 4, 2017 at 15:38
  • "You're not really capable of making this decision yourself" -- well, capable or not the questioner isn't authorised to make this decision. Or rather, is authorised to decide on A but is not authorised to decide on B. Getting B requires delegating upwards! Commented Aug 5, 2017 at 9:44
  • @SteveJessop Sure, but even when delegating upwards, you want to show that you have the knowledge to make the decision yourself (even if you don't have permission to do so) to make your boss more comfortable giving you more responsibility in future. Commented Aug 5, 2017 at 14:17

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.


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.


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.


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.

  • 2
    This is the only answer that I can see that actually addresses the original question fully - all the others seem to be working under the assumption that @LordFarquaad actually wants to implement 'B'. I don't think that's true - it sounds like they have correctly identified A as the most pragmatic choice, but they also want to gain whatever advantage they can from having come up with B as part of their analysis. I would do more than 'mention it in passing', but otherwise, this is the right approach.
    – Beejamin
    Commented Aug 6, 2017 at 12:17

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.


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.


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.


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: enter image description here

  • 1
    For a small scale issue like the one @LordFarquad is describing, I would suggest this type of analysis is spending way too much time and effort. If I had tasked a junior employee with "Can you fix 'A'?" and they came back with a dynamic, tuneable spreadsheet, I would be less than impressed.
    – Beejamin
    Commented Aug 6, 2017 at 12:13
  • 1
    @Beejamin: I would strongly suspect that the junior had introduced spurious precision, too. The example spreadsheet above might be a well-considered weighting of the various concerns, or it might be a post hoc rationalisation of the assessment, "data security is essential to this project, and B and C are insecure". One test is: if we could tweak Plan C to justify awarding it 2/5 for data security (matching B), would that be sufficient to go ahead with C instead of A? Someone who can't answer "yes" to that question has no business presenting this particular matrix :-) Commented Aug 7, 2017 at 8:57
  • ... and should instead present a matrix with speed and integrity rated at some tiny fraction of the rating for security, to ensure they act only as tie-breakers for equally-secure proposals. But it's easy to lose discipline on this, and only rate data security (or whatever is most important to your real project) "high enough" to produce the "correct" answer, knowing what proposals are on the table. For the process to be reliable, everything must be weighted appropriately to deal with any proposal that might be added later. Commented Aug 7, 2017 at 8:59

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.

Scotty's Secret to being a Miracle Worker


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.


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.

  • @JoeStrazzere Wow, you're everywhere on this site. What actually happened was, "“If it could save a person’s life, would you find a way to shave ten seconds off the boot time?” [Jobs] asked. Jobs went to a whiteboard and showed that if there were five million people using the Mac, and it took ten seconds extra to turn it on every day, that added up to 300 million or so hours per year that people would save, which was the equivalent of at least 100 lifetimes saved per year.”
    – jfa
    Commented Aug 10, 2017 at 18:34
  • "[Engineer, Larry Kenyon] was suitably impressed, and a few weeks later he came back and it booted up twenty-eight seconds faster,” [Bill] Atkinson recalled." fastcompany.com/1790791/… So yes, he proved that reducing boot time would save lives.
    – jfa
    Commented Aug 10, 2017 at 18:37

Can you do both?

bool bBeClever=false;


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .