I'm working with php and sql.

I think that my method of implementing functions is better than what my boss proposes. Just now he explained me how to do a check on a list of email addresses, and I do not like his idea. I proposed mine which is better and quicker to implement, but he disagreed.

Now I think I will go ahead and implement my idea, because his idea was not clear enough to me. Do you think he will be mad?

  • 71
    It sounds like the problem might be that you are not doing a very good job of explaining why yours is "better and quicker to implement".
    – Nicole
    Dec 20, 2010 at 8:15
  • 21
    Please add some more information: (1) Can your boss program? (2) What was exactly your boss's solution. (2) What exactly is your solution? Until these unknowns are understood, its hard to judge if your solution is actually any good.
    – Darknight
    Dec 20, 2010 at 9:06
  • 4
    You are better than your boss? Whatever makes you think that? We need details.
    – user9682
    Dec 20, 2010 at 11:43
  • 3
    I think it might also help to edit your question to link to your other, related question: programmers.stackexchange.com/questions/28228/…
    – user9682
    Dec 20, 2010 at 12:38
  • 3
    Let me guess, you've been coding for less than 5 years? Sweet, innocent child... :-)
    – Ed Griebel
    Dec 20, 2010 at 15:54

17 Answers 17


Having been "the boss" and, as it turned out, actually better than my staff in all cases bar one - yes, he will be mad - or annoyed or frustrated and in any case, quite possibly, right in the first place.

If you're genuinely better than him then you should be able to understand his proposed solution and to see why yours is better and then to explain why.

But you state:

because his idea was not clear enough to me

In which case you need to go back and understand what he wants and why and whether - as has been the case both in me making suggestions to my staff and my staff proposing solutions to me - you or he has missed something. But don't assume that he's wrong and you're right unless and until you understand what he's asking for and whether he's covering something you haven't thought of (yet).

Oh and in the one case - he's a better programmer but he's not so good a couple of steps back from the problem where I'm better and we had great fun working together for that very reason.

  • 13
    +1 "unless and until you understand what he's asking for" Dec 20, 2010 at 10:47
  • 3
    Great answer, wanted to add that we should not assume the boss does not have additional information from his boss or someone higher up leading to him having additional knowledge allowing him to conclude his solution is better. I have seen this happen before and instead of looking like an ass it helps to make sure you understand your boss and where he is coming from before jumping to the "my boss does not understand my solution is better".
    – Chris
    Dec 20, 2010 at 13:01
  • 1
    sometimes having the better solution isn't enough nor the most important thing; the reality is that egos, hierarchies, and encrusted time-honored team/company rituals exist - and they are greater than you and hold importance sometimes beyond our immediate understanding. the best thing you can do is be able to analyze and lay out the options side by side and present their benefits and caveats in sufficient detail for the manager (or team) to make a decision. at least at that point you know you've done your due diligence and the fate of the project is no longer in your hands. Dec 20, 2010 at 15:03
  • 1
    The thing that makes me question this answer is "having been better than my staff". I don't want to work for a boss who thinks he's better than me... Dec 20, 2010 at 17:22
  • 1
    -1. If you truly are better at programming then all of your subordinates, then you have been given the wrong job. Nothing says that a manager must be better at everything. Ideally, a manager should be better at managing the project, and the programmers should be better at programming. It should be the same way with everyone in every job description. A truly great team is a team where skills compliment each other so that the team is greater than the sum of the parts. I'm sorry bud, but your arrogant attitude has no place in a team. Go work solo and save everyone some grief.
    – riwalk
    Aug 27, 2012 at 21:55

You are critizing him by thinking you are better than him, instead of critizing his ideas.

You need to change that inappropriate behavior in the first place.

Take the opportunity to challenge his ideas positively by asking "why?" enough times. If the idea is so stupid, he will eventually discover it himself by answering your questions.

This technique has the advantage help you understand. His idea is probably more intelligent than you think.

Also seeking to understand before trying to be understood will help your boss disarm himself against you. When you propose someone something, its lizard brain will try to determine if it's a treat. His lizard brain want to him to be safe. Seeking to understand him will re-insure his archaic brain.

Now if you have a better proposal, I'm sure he will be more than happy to listen to you. Be prepared to be asked "why?" enough times until he is convinced.

After all, you are the professional, that's why he hired you at the first place. He should listen to you.

If he is not interested by your ideas at all, there is only one thing to do: quit.

  • 2
    +1 for "You need to change that inappropriate behavior in the first place." First understand your superior's proposal inside and out before criticizing it.
    – Chris
    Dec 20, 2010 at 13:02

You say your method is "quicker to implement". That rings alarm bells to me.

Code that is quicker to implement can, very often, be hard to maintain.

He is your boss. Unless you stay there for life, he's going to be living with that code for much longer than you are. Perhaps his strategy takes that fact into account.

Short answer: Insubordination is a sure-fire way to get fired.

  • 4
    Your short answer is the absolute best summary of the issue.
    – justkt
    Dec 20, 2010 at 13:45
  • I disagree, quicker and simpler is better. more complex with a lot of corner cases is worst and harder to maintain. I even believe you should always do it the simplest way and later it will evolve if it needs to.
    – IAdapter
    Jan 9, 2011 at 17:39
  • I partly agree with you, I also think 'Simpler is better'. But, favouring "simpler for the person who reads the code 3 years after" over "Simpler to write". So, in that sense, 'Simpler' may have a trade off with 'Quicker'. If ya get me.
    – JW01
    Jan 9, 2011 at 20:11

Your bosses job isn't to program better to you, it's to manage you. So putting aside the fact that given his apparent programming background and that he may know reasons why your solution isn't the best - show him you can take direction and he'll trust you more down the track when you come to him with better solutions.

I can almost guarantee it's your approach to telling him why he's wrong (what about saying how we can do it better?) that's stopping you from being heard.

... not to say there aren't real inexperienced dicks out there :)


Consider that your boss needs a few things from you:

  • The ability to program. By all rights, unless he's a developing manager, he (hopefully) hired you hoping that you'd be better than him.
  • The ability to work on a team: that means listening as well as explaining ideas.
  • The ability to do what you're told. When the final word has been said, after all of the back-and-forth discussing of a problem, you're not the boss. If you try to be a hotshot when you've been told specifically not to do something, you can't be trusted.

If you want to continue with the issue, you could implement your boss' idea, implement your own (on your own time if it'll take a while to do), and demonstrate them both to prove that yours is better. I'd leave the attitude in the shower when you do.

  • "When the final word has been said, after all of the back-and-forth discussing of a problem, you're not the boss." - what this means is, that when it comes to explaining to whoever is paying you and your boss why it didn't work, you will be glad your boss has to do the explaining and not you. Dec 20, 2010 at 12:04

Yes he will be mad. So I'd advise you to email him a reason why your method is better. And ask him for an approval for going ahead with your method. My point of "email" is to ensure you list down and collate all your reasons before going into any further discussion.

Try wording it as "I trust this method suits the project/issue" - so unless he has a better way, he should go with you.

If you are really sure and have enough ammo to support your view, go with "I trust this method suits the project/issue because of 1,2,3.. reasons"

One more personal advise - saying "I am better than my boss" comes across as a bit arrogant, I understand you might be angry right now - but in a professional context this wont be well appreciated. Hope your boss doesnt read this post ;)

  • 9
    Never, ever, try to resolve a conflict with Email. Emails allows you to react according to what ever mood your in when you read them.
    – Morten
    Dec 20, 2010 at 8:48
  • I agree with Morten's comment. Most conflicts also start in email conversation. Body language is vital.
    – user2567
    Dec 20, 2010 at 10:02
  • @Morten, Pierre: Agree to your "email" comments. I meant there should be a discussion on the OP's points vs his bosses' points.
    – JoseK
    Dec 20, 2010 at 10:18
  • Email should be a subsequent step, to follow up, document, and detail the conversation that needs to happen first. I lost count on how many emails have come to bite back the people who have sent it (myself, included). The most volatile disagreements and misunderstandings were due to the "email first, ask questions later" strategy. No matter the tone you have in your mind when writing an email, the tone will almost always be interpreted differently by the recipient. If there's a conversation first, a tone has already been established. Dec 20, 2010 at 14:33

Being a great developer is not just being a good coder! Part of the job is to work well with others, and collaborate with your teams and bosses. If you think that your way is better, try and explain that to him, showing him "data" of why it is better.

If he claims that his way is actually better, than try to keep an open mind for the case that he might be right. If he is not, and is just pulling authority over you, then you have one bad boss... (because part of being a great boss as well is collaborating with your team and managing it properly). In which case, it might not be such a bad idea to start looking around.


It's surely a quick and easy way to get fired.

My advice is to implement both and use the one your boss wants.

If there is a problem, tell him you have a fix, and show it to him, but don't tell him why you wrote it.

  • I have to disagree with this one. Creating two implementations just to prove someone is wrong is simply waste of time. I am 100% sure that in most of the cases normal discussion about pros and cons of each solution is enough.
    – Tx3
    Mar 16, 2011 at 10:54
  • You don't have to bend over in every situation. High level players know their stuff, know how to prove it, and also know when to retreat. And they're most sought after, and paid the best salaries. Code monkeys translate incomplete specifications into an incomplete code.
    – Coder
    Aug 27, 2012 at 22:08

I don't think you have the right attitude here. Thinking you are better than your boss or just thinking you are better than somebody else never helps matters. Did you tell him why you didn't like his idea or did you just say, "I have a better way of doing things". Why is your idea better exactly? Is it a less convoluted algorithmically? Does it have better run-time? Is it easier to maintain? Does it use easier to understand design patterns?


As many answers already provided, I don't advise you to code a solution your lead hasn't approved. You first have to prove him that your solution is better in a constructive way. If he's a good manager and deeply thinks his solution is better than yours, you can expect from him to explain why. Don't forget that as manager, he may have other criteria than you to define what an efficient solution is. Maintainability or easiness of reading may be one of them.

Besides, if he's a good manager, it won't be a dishonor for him to choose your solution if you have objectively succeeded in proving that it is really better.

But at the end, even if you still disagree with him, don't deceive him; don't do something he will ignore. Team management is also based on trust and transparency so you could screwed up your relationship with and the team efficiency. And the team objectives should be your first priority.

If the situation occurs again and again, and his choices are always bad, he shouldn't stay your boss for a long time. If it's just occasional, don't be too overproud...


It seems your in conflict over something, so you have to focus on being constructive.

If you sincerally do not believe in his solution you should find a constructive way to tell him how you feel about it. There are a few things to consider in this. Your responsible for your delivery, but his is responsible for the team's delivery. You will have to show that your interest is that of the teams delivery and your own (that these two align).

Make a list of pro's and con's with the two solutions and dicuss it with your boss in a constructive manner. Sometimes it easier to show that your or he is missing a key component of the solution with a list.

Try to understand what he wants, it's the end goal that is the purpose. If you get in conflict over this then your not focusing on the right goal.


My advice is to first determine if his solution is in fact better. Post the two solutions, ask SE for an unbiased opinion.

I would NEVER ignore my boss. If he has the technical know-how, then there is no harm in a healthy discussion. He pits his idea and you propose your's.

However, if you do determine that in fact his method is inferior and he won't allow you to do the job he hired you for, quit. There is nothing worse than having a knucklehead stand over you telling you how you should do something when they clearly have no idea what they're talking about.


Let's start with the fact that it is the boss's job to make decisions, not yours. You go against those decisions behind his back and it's a quick path to being fired for cause.

You can and should present your ideas before the decision is made, but once it's made, it is your job to make the decision work even if you don't agree with it. If you can't do that you will have a very short career.


Depends on the person. If he's reasonable enough and you show him your solution and it is better, he won't probably be mad. But if he's not, then you're in trouble.

Now, for the non-generic bullshit part: He is your boss. He's not there to be a better programmer but to be a better manager/leader. Maybe he has reasons you haven't considered.

If you're a risk-taker, then go for it but don't be mad if you'll get fired. It's all a bet.


Don't bite the hand that feeds you.
If you think yours is better, even after exhaustive analysis, then sure, do as you believe but you will live with the consequences.

  • Why not? No one will benefit if the end product will be bug ridden piece of trash. It's important to work in a team, and decide as a team. But your task as a professional developer is to find professional solutions, and defend your position if and when it's right.
    – Coder
    Aug 27, 2012 at 22:48

My boss can't program his way out of a paper bag(actually can't program just a good talker and con artist, but to satisfy his inadequacies, he has me do things that cover up my work, so he can cover the real brains behind whats happening. 1% of the ideas are from the key questions that I ask. 100% of the the code and methods came from me. When by boss gives me bad ideas I implement my own, my boss is more into getting himself ahead then a successful program. My strategy of networking with everyone around him helps stifle his lies at a local level. Now I work for division 1/3 of the states in a major corp. I will use the same strategy again, although I'm going to need to be even more creative in networking.

To answer the original question in this post that bosses code is not good as mine. As the other people have stated. What makes you think so. Code is logic. Why exactly do you believe yours is better? In my case there is politics evolved that goes beyond having a successful product. In my case he wants to stifle my notarization to push along his own. Not sure what your situation might be lots of possibilities here.


It can be either way, depending on details.

I know that I have been in a lot of situations where I have been arguing with the bosses about one thing or another. A lot of times I have proven that my idea is better, sometimes they have shown me a solution that was a lot quicker and more complete. Sometimes neither of us knew, so I had to do the research, compare the ideas, and maybe even come up with something new for the next round of decision making.

If the boss is a good boss, and you're at the senior level, he probably knows you have a lot of experience and a better/fresher view on internal problems, and he will understand why you did something if you'll explain it to him. He will also avoid micromanaging you.

And sometimes, no matter how good you are, you miss simple things, that later make you wonder how you could be so stupid to overlook a trivial solution. And the boss, with his overview from distance might spot them a lot easier.

Not the answer you're looking for? Browse other questions tagged or ask your own question.