6

I have an issue where my project leader is making ipse dixit statements (meaning [it's true because] he said it himself). It takes time to verify whether his statements are true or not (usually untrue), by which time a decision has been made, and will not be reversed.

As an example, "I'm rejecting your code change (from a code review to make some new code more readable) because your code is slower than the currently proposed code and uses more memory" when neither way has been benchmarked. After benchmarking, my code turns out to be faster, and uses less memory, but the other code has been accepted, and my code will no longer be considered.

He is currently using his authority to be "right", instead of waiting for facts that everyone can agree on. How can I diplomatically expose and take unverified statements out of consideration when talking to him?

| improve this question | |
  • For how long this is happening? Anything more than a couple of months - and I would say, there is a serious problem with the organization and/or team environment. Any longer than a couple of months - this should have drawn attention of the stakeholders - as the decision based on false claims are supposed to have negative results. – Sourav Ghosh Jan 22 '19 at 10:34
  • 2
    Software is tough. You have to follow and support your leader. There's a million reasons the "other way" may be preferred. If you don't like a supporting role: start your own company or product so you have no boss. – Fattie Jan 22 '19 at 10:35
  • 4
    @Fattie I know I'm not going to agree with every decision. But I'd at least like the decision to be based on facts instead of opinions dressed as facts. – CJ Dennis Jan 22 '19 at 10:36
  • 1
    "But I'd at least like the decision to be based on facts instead of opinions dressed as facts" Start your own company or product, and good luck! "Who cares", as it were, what you think, or what you'd "like", one way or another about the decision making process - or anything else. Unfortunately a job means you are being paid lots of money to "do what you are told". Take it as encouragement in life to start your own thing! Good luck! – Fattie Jan 22 '19 at 10:41
  • @SouravGhosh That hardly depends whether these are major performance issues or just a few ms in a process that takes seconds anyway. The lead might well be right not to spend time in micro-optimisations, but his way to convey that would be wrong in that case as well. – Frank Hopkins Jan 22 '19 at 11:02
6

Pick your battles.

If your aim is for this guy to prove and validate his claims "as facts", then you're only going to create an atmosphere of confrontation and distrust.

You could soften his claims with

Well, maybe

And leave it at that. In software development, "faster" isn't always "better", there's coding practices, security considerations, maintainability, etc.

And if you're both constructing code that does the same thing (i.e. you're comparing one against another on a like-for-like basis), then there's something wrong in the team - you don't typically developers duplicating work for no real reason.

| improve this answer | |
  • 2
    "you don't typically developers duplicating work" oh yea? Then what is refactoring all about? – Daniel Jan 22 '19 at 12:41
  • 4
    @Daniel Refactoring is modifying existing code to improve or restructure it. It is not coding the same thing as another developer at the same time and seeing which one is better. There is a difference. – Kyle Wardle Jan 22 '19 at 12:58
  • Which is exactly what OP described in: "I'm rejecting your code change - because your code is slower than the currently proposed" – Daniel Jan 22 '19 at 13:02
3

TLDR: You need to accept your leader's authority, but you should point out incorrect assumptions, provide feedback, attempt to establish standards and teach him no argument is often better than a faulty one

Follow the herd leader

Exactly as Fattie said in a comment, as a team you will often encounter situations that will require a decision to be made and often enough there is no time to ditch out all the details to make a perfect fact based decision. Often enough it doesn't matter what is a few ms faster and code style can be arguable. At some point someone needs to decide which solution to go for so the team can move on to bigger challenges. Once such a decision has been made, as a team member, you need to accept that decision and move on.

Responsibility of the good herd leader

BUT: it is your team leader's task to lead by example and "take the team with him", when he's making such authoritative decisions. He can either explain why he thinks something is better or decide by authority or by standard. Usually you want as much standards for such situations based on facts as possible, so situations like this can be quickly resolved by citing the standard and are avoided most of the time anyway as the standard is known. If he argues unconvincingly or even repeatedly factually wrong that shows bad leadership skills and you should help him get better at it. That does require feedback.

Feedback

For instance, you can question his argument. If he says it is faster:

Is it really faster? Can you explain why? Last time we had something similar the other solution was faster. Look, I've got this similar test here...

Try to abstract away from individual things to general problems for which a standard way to solve them can be discussed, tested once and then widely applied.

If you don't have data ready when a decision is made, you can also bring it up in one of the next meetings.

I've read up/tested on lookup times of individual items in a linked list and a hash map and the hash map is always faster, maybe we should define a standard to always use hash maps for such problems from now on.

Pick your battles wisely. Don't try to fix some minor issue that only occurs once, after the fact, but try to get policies established that you can refer to. Note that performance isn't the ultimate measure, readability often trumps performance gains.

Don't attack the authority of your team lead, but try to support him:

Look, if you tell me this is the way we do things here for whatever reason, that's fine. But this is not faster for [reason], so if you want to squeeze out a little more speed, maybe we should give variant B a try.

Don't argue about "my variant" vs. "your variant", try to detach yourself from different options available. That way it is not as much between you and him, but about choosing the best option together.

| improve this answer | |
  • 1
    I've edited my question because the change was about readability and maintainability, but was rejected because of spurious speed and memory usage claims. – CJ Dennis Jan 22 '19 at 11:47
  • +1 - last few jobs I had, I specifically reserved right to disagree with my boss. Not to do things in a way boss don't want, mind. I will do things as I'm told and paid to do them, but I reserved right to say I disagree, or request benchmarks / tests / etc. Luckily didn't even happen this workplace, but at least I'm sure that if I'll have to do something I know is wrong, I can make sure it won't hit me in the face later. – Mołot Jan 22 '19 at 12:52

You must log in to answer this question.

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