您如何判断高级开发人员的建议是否不好？[关闭]

最近，我以初级开发人员的身份开始了我的第一份工作，我还有一个高级开发人员负责在这家小公司中指导我。但是，有几次他会给我一些我无法同意的建议（这与我在专家撰写的有关该主题的几本好书中学到的东西背道而驰，我在一些问答网站上提出的问题也同意了和我一起），并且由于我们的日程安排很忙，我们可能没有时间进行长时间辩论。

到目前为止，我一直在通过听取他的意见来努力避免这一问题，并根据我所学到的当前良好做法提出一个对策。他再次提出了自己的观点（大多数时候，他会说最好的做法，更易于维护，但没有走得更远），我记下了笔记（因为他没有提出新观点来反驳我的观点）它并在家里进行研究，但不要进行任何更改（我仍然不相信）。但是最近，他再次与我联系，看到了我的代码，并问我为什么我没有将其更改为他的建议。这是2--3周内的第三次。

作为一名初级开发人员，我知道我应该尊重他，但与此同时，我只是不同意他的一些建议。但是，我承受着进行更改的压力，我认为这些更改会使项目变得更糟。当然，作为一个没有经验的开发人员，我可能会错，他的方法可能会更好，这可能是其中一种例外情况。

我的问题是：我该怎么做才能更好地判断高级开发人员的建议是好是坏，或者是好的，但是在今天的情况下已经过时了？而且，如果情况不好/已经过时，那么尽管他有“压力”，我仍然可以使用什么策略不按他的方式执行它，同时又要保持我尊重他作为长者的事实呢？

首先，作为一名高级开发人员，我希望我领导的项目初级人员能够直接直接地将他们的疑虑带给我。如果他们不同意，那对我来说完全可以。在某些情况下，我会针对他们的关注采取行动。在大多数情况下，他们的担忧被抛 在一边，并简短地解释了理由，并非出于对开发人员本人的不尊重，而是由于其他一些原因，例如：

1. 大三学生手头上没有所有信息，无法理解做出的决定。在某些情况下，稍作解释可以帮助开发人员超越关注点并解决不理想的情况。
2. 初中生有不良信息。实际上，请不要忘记您是大三学生。就软件而言，这相当于十几岁。我敢肯定您有很多很棒的主意，但是您可能一无所知。我发现最有抵抗力的初级开发人员是那些坚信他们知道什么对代码，公司和整个世界最好的开发人员。这些开发人员可以通过谦卑获得更好的服务。
3. 采取某种特殊方式的决定是在年长的头上做出的。最后，长者仍然为其他人工作。实际上，可能存在做某事的更好方法，写某事的更有效方法，或者有更好的软件/硬件来帮助完成任务。但是，企业仍然在驱动决策。业务经理，董事，副总裁等经常做出影响开发过程的决策。这些是老年人无法控制的，当大三学生抱怨时，他们所做的只是增加了老年人的压力。
4. 刚出手的长者没有时间考虑到这一点。有期限，有时在中途改变模式，实践和行为对于期限而言是昂贵的。由于在砧板上是他的脖子，因此与“完美书写”相比，使产品正常运行并按时输出更为重要。

这些只是我想到的事情。有很多原因导致某个想法，实践或概念可能被比您高的人拒绝或丢弃。他们中的许多人都令人不快，但它们都归结为我们都是人，而且我们都有意见的事实。目前，他的观点恰好在您的观点上。

牢记这些概念，您应该继续将您的疑虑带给高级开发人员。寻找另一个可能填补空白的高级开发人员。许多高级开发人员处在他们所处的位置，因为与人相比，他们在软件方面要好得多。他们之所以在某些地方，是因为他们知道当实习生时要吻谁的屁股。寻找一个真正了解指导某人并获得其诚实意见的人。他们可能会不同意您的意见，并填写您没有的空白。他们可能会同意您的意见，并帮助您团结事业或改善局势。

您绝对不应发动任何形式的暴动。即使您内心深信自己的方法是正确的，也已向您发出了要遵循的指示，并且应该遵循该指示（除非这显然是非法的）。如果您在遵循这些说明时遇到困难，则可能要尝试找出原因，因为您将发现这种行为模式在许多生产任何类型软件的公司中非常普遍。

最好的选择是继续以道德和专业的态度开展工作。以模范的方式获取要求您完成的软件，并通过升级退出该软件。如果没有晋升，您将获得大量参考和经验，以寻求其他部门或公司的机会。

尊重高级开发人员。与您相比，他对项目成功的追求更高。由于他有责任，因此他也获得了权力。如果他说改变某事，那就去做。

话虽如此，当您遇到已经存在的问题时，请立即提出您的问题。

最后，与他坐下并向他解释您在此处发布的相同问题。也许您错过了一些大事，也许他会为您的建议提供更多机会，无论哪种方式，如果您认为他的建议很差，请不要让他处于黑暗之中。

发生这种情况时，您需要与高级开发人员进行对话。也许他知道您对代码或技术/业务要求不了解。如果是这样，您应该学习它。

私下进行。可以将其视为具有挑战性的权威，最好将这些事情一对一地完成。表现出愿意承认和尊重他的资历，做出让步和合作的意愿，但要坚持不懈地回答您的问题。从协作框架而不是好斗的框架来处理情况。您可能会考虑请他指导您。

归根结底，您必须平衡自己的想法（公平地说，它们相对较新且未经检验）。也许您确实是对的，但是您应该尽力向经验丰富的人学习，以便做出更明智的决定。优秀的高级开发人员欢迎与初级开发人员合作，指导和学习的机会，并欢迎以建设性的方式挑战他们的想法，因为他们也知道有时他们是错的。

您经常说的是通过常识方法。请记住，高级开发人员可能对项目有更多的了解，但是对做事的正确方式可能并不了解。你必须衡量他告诉你做什么-他给你不好的意见，如果他说，在什么样的脸飞了更佳要求，即人（比他更资深的;不一定在你的公司？我说的知名的“名人”开发人员，他们经常发布或撰写有关软件开发正确方法的书籍，或者至少是业界公认的最佳实践的书籍。

这是一个来自高级开发人员（或任何开发人员）的“坏建议”的示例：如果他们完全不了解松散耦合是什么以及为什么这是一件好事，并且被告知您将所有代码都写进去，比如说代码-在ASPX文件的后面，很明显，高级开发人员很笨拙，不应听取他的建议。

另一方面，如果他告诉您系统中特定模块的工作方式，那么通常最好再听一次，只要他告诉您的内容不会面对正确的开发原则。

这是我的经验法则：公司的高级开发人员可能只是任期最长的开发人员。他可能没有任何实际技能。他说的话是否与您所在领域的一些最受尊敬的开发人员所说的相反（比他经验丰富的人，而且他们更有能力和受人尊敬）？如果他是，除非有非常极端的情况，否则他的建议很可能是不好的。

对于极端偏见的观点，我们完全希望获得赞成票/分歧。

可能很难理解高级开发人员的优势，是的，他可能会引领错误的发展，但是，对于大型项目，一致性更为重要。

如果有50个开发人员全部遵循自己的编码风格，标准，方法和设计模式，那将是非常混乱的。如果做错了事情，那么始终如一地做错总是比许多不同类型的错误和某些做对了的事情更好。

当需要执行维护，添加功能或修复“错误”内容时，如果预先知道现有设计的问题，则容易得多。

尊重您的意见是件好事，但最终最好还是保持一致。团队中流氓的任何人都不会被视为团队成员。

如果上级不能给您充分的理由说明他们为什么忽略行业最佳实践，那么不要在这里浪费时间。您永远不会前进，因为您太有威胁性了，无论如何，您是否想花时间维护大量错误代码？

大多数开发人员离开大学后就会停止阅读。您还没有，所以您已经进入了前10％。这些天有很多机会。如果您所在的城镇没有工作市场，请寻找一个更好的城镇。

哇，这是一个绝佳的机会，让您发光并炫耀自己的技能。在我职业生涯的早期，我的上级主管无法做出任何决定，因此无法做出任何决定，因此我利用这次机会学习了如何进行更高层次的工作。它使我升职。您应该做同样的事情。

作为高级开发人员，这种被动的主动挑剔行为会让我发疯，而在面对之后，您会带我给您不好的评价。完美的解决方案是团队可以一起生活的解决方案。

至于样式，这应该由您的样式指南和最佳实践决定，具体取决于您的出身。如果您充满激情，请为它辩护，但是一旦做出决定并在团队中与您一起工作，您就可以继续工作。

您的处境不太好，但正如HLGEM指出的那样，您可以将这些职位化为祸福。您的问题是多方面的，因此我将分部分进行讨论。

我怀疑，他不知道。同时，他试图向我展示自己的嚣张气焰，这样我就不会问他太多问题了。

这很可能是真的。从开发或指导的角度来看，已经从事该行业数十年而又没有强大的软件开发人员的开发人员大为不同（存在差异）。经验来自于应对新挑战，尝试新想法和学习新技能，但是大多数程序员将自己的一生都花在了公司办公室的一角，用他们忠实的Visual Basic和Java工具来开发薪资应用程序，却从未见过如此飞速的发展。他们冷淡的灰色办公室。

这没有错。对于许多开发人员而言，这是他们所希望的一切，并且完全适合这种情况-但是，这不是培养下一代程序员的理想情况，更不用说领导开发人员了。

虚张声势和自大可能是一种防御机制，试图弥补不足之处。您如何处理？不要直面它-如果您的领导能力不强，而老板不愿纠正这种情况，那么您将不得不忍受它。这并不意味着翻身并死亡，但是您不能强迫某人成为好领导。

但是，他只是查看我的代码，而他的大部分评论都与编码准则有关

这就是让我认为您是对的，因为他可能不是一个好的程序员。这并不是说他目前没有比您更好的程序员（至少他会在这个行业工作这么长时间会拥有更多的经验和经验），但是，这并不能转化为成为一名程序员。有效的线索。准则虽然很好，但是仅次于代码的功能，有效性和效率。

在这种情况下我该怎么办？

我已将这种情况告知了我的经理，我已要求他更改我的主管，尽管他每次都说“是”，但他没有采取任何严肃的行动。

您是否已向经理列举了所有这些具体要点，并提供了具体示例来对其进行备份？如果您只是去找他说：“我需要一个新的线索”，那么他不会认真对待您，并将其视为“人际问题”，而不是技术问题。在这种情况下，许多老板的反应是忽略它，希望它会“自行解决”。

这里有一些建议。

1. 不要因自己的情况而感到烦恼 - 大胆尝试虽然不好玩，但会教给您一些关键的研究技能，供您在职业生涯后期使用。
2. 开始推动您的潜在客户参与其中。做到这一点认真和尊敬。继续努力并持之以恒，直到他屈服为止（这实际上适用于生活中的许多情况）。
3. 如果您的线索不参与，请查看是否还有其他人可以帮助您。除非您在只关心挤奶时间的血汗工厂工作，否则您的公司不会介意具有更多经验的其他开发人员向您展示一些绳索并审查您的代码。
4. 开始关注新工作。我不会说你在“必须离开”的局面是，但它不会伤害你的职业生涯是在需要的地方你的发展作为一个程序员更严重。

如果你有一个更好的方式做解决特定的问题，只是DO IT。

让您的代码/解决方案成为最佳选择。否则，请遵循已被告知的内容。

案例

当我还是一名初中生时，我遇到了这样的情况，即特定的代码部分并不是最好的。我不仅对它进行辩论，还只是对其进行了改进，然后向我的上级展示了结果。他接受了，因为代码始终是国王。

当然，作为一个没有经验的开发人员，我可能错了，他的方法可能会更好，所以我的问题是，我可以通过哪些方法更好地判断高级开发人员的建议是好是坏/过时了。

您可以成为经验丰富的开发人员。除非您这样做，否则您将无能力判断自己作为大三学生的直觉是否正确，届时这将无关紧要。

同时，请阅读Joel Etherton的答案。

我强烈建议不要尝试“不按自己的方式实施”。

到目前为止，听起来您做对了。你很谦虚，提出了一个反对意见。从您的问题中我无法分辨您是只是不同意他的方法，还是不同意并提出了另一种选择。但最重要的是，当您试图击倒别人的方法时，总是提供一个清晰，深思熟虑的选择。正如他可能看到的那样，您有一个可行的好主意，而他有一个可行的主意。

在任何位置，我们总是被迫做次优的事情。如果您真的不喜欢它，那么您可以照做并提出来。之后，是老板的路还是高速公路。从好的方面来说，您可以避免大三学生做出错误决定的很多风险。

选择战斗。如果您要谈论一个小时的工作，那么您将不得不不时更改代码，直到您逐步完成。下次您遇到大型项目时，请提前询问是否有机会在开始之前介绍您的想法。投入一些额外的时间，制作出惊人的演示或原型。

我所做的令人震惊的是，只是停止询问。当有其他选择的时候，我只是离开了，按照自己的方式做，但是增加了自己的才能。将其作为学习经验来培养您的能力，并仍然满足他或她保持老派的需要。

最后，并不是每个高级开发人员都关注新的工作方式。他们有时会采用古老的教学方式，这对他们20年前开始使用的语言非常有用，但被认为是骇人听闻的，或在当今世界“闻起来很臭”。

这听起来像是一种可怕的继续前进的方式，事实确实如此。但是我也从我的前辈那里学到了很多东西。但这实际上只是我的意见。最后，您必须对自己的工作感到高兴，并将注意力和紧张情绪保持在较低水平。通过不反对，您会发现压力下降了。

不要因为年长而信任老人。尽可能多地挑战权威。主管当局应能够令人信服地回答任何问题。这就是首先使他具有权威性的原因，不是吗？

因为某人一生都信奉迷信，但这并不意味着他是对的。请记住，在中世纪，人们认为地球是平坦的，其中一些自以为是的驴子甚至有理由杀死怀疑者。原来，怀疑者是对的。非常差的评论。

永远不要害怕不好的评价。您会相信一个盲人判断肤色吗？

上面的好答案会补充说，“最佳实践”或“更易于维护”之类的回答是学习一些东西的机会。您说：“您能举个例子说明为什么这种方式是最好的，这样我才能理解其中的区别吗？” 或“在什么情况下，这种方式比其他方式更易于维护，因此我可以学会像那样预先计划？”

如果上司是对的，给您一个榜样将很容易。如果他是一只鹦鹉...给他一个饼干来阻止南瓜，然后做你认为最好的事情。除非有其他命令。

如果长者的角色是指导，他将在被问到时解释原因。

正如HLGEM和Jarrod之前所说，这确实是变相的祝福。他们的答案都很好，我想补充一点。

由于您的领导者不在您的域中，因此您需要对应用程序部分做出一些重要的决定，因为您的领导者对中间件并不了解。您还需要与经理保持联系，以了解应用程序的运行方式，产品用户的需求以及经理如何解决产品团队向他提出的情况。告诉我有多少人将在应用程序上获得这种知识。

当您在一个大型团队中时，您肯定会从您的队友和/或您的领导那里获得帮助，但是您将不了解经理的想法或产品团队的想法，因为这种事情通常会贯穿您的领导，并且可能会团队中的一些高级开发人员。我同意一个人的项目很难进行，但是如果硬币的另一面如此之大，为什么要错过机会。学习您可以学到的东西，在可以的时候享受乐趣，如果困难太大，请像Jarrod所说的那样说服您的经理，或者根据情况找到新的工作/项目。

您将在整个职业生涯中都与这样的人打交道。在许多编码问题上，您将与许多人不同意最佳方法。我认为多年来为我工作的最好的事情是，如果他们继续紧迫问题，请与他们保持联系，并告诉他们您已经在各种可能的解决方案中考虑了他们的解决方案，并且您认为该解决方案您认为这是在这种情况下最好的方法。

现在，如果您每次都拒绝他们的建议，那么有时您可能需要不时屈服并使用他们的“建议”，以抚平一些皱褶的羽毛。只要他们不觉得您每次都拒绝他们的意见，那将对保持你们之间的和平大有帮助。

还请考虑他们是高级开发人员，并且在该环境中工作的时间比您更长。现实生活中的编码通常与最佳实践或社区公认的标准不符。他们可能会建议他们以某种方式进行某些操作，以致他们无法充分表达自己的观点。因此，即使您不同意他们的意见，也请确保不要仅仅基于您认为自己的解决方案更好的事实就不要忽略他们的建议。

一切都与平衡有关。不仅是编码平衡，还有团队平衡。许多项目失败的原因不是因为开发人员没有能力，而是因为他们找不到友好地合作的方法。

我想从我的个人经验中提供一些东西，这些东西应该被视为jzd在此处发布的内容的补充答案...

1. 问另一个高级开发人员，
2. 自行研究。

在一次专业任命中，我应该由一位资深人士进行指导。他知道一些东西，但说实话还不多，不幸的是他不知道，所以他对自己的答案非常有信心。我莫名其妙地觉得他的话是错误的。当他所做的事情与我所采取的MS认证中提到的最佳实践不符时，我有一些证据：-)。之后，我开始询问其他公司的其他人员（当时stackexchange尚未启动并开始运行），并开始阅读博客以比较答案。

如果我错了，那就太好了，因为我只是改变自己的行为，但事实并非如此。

在过去的几年中，我注意到了一些事情，几乎我所从事的每个公司，我从事的几乎每个项目，几乎每个新员工（无论技能/经验水平如何）都希望做点“与众不同”的事情。

可能是编码标准，整体架构，语言或方法论。但这总是东西。很多时候，这只是在说明一个明显的事实：“对于我们的最终用户来说，是否应该对所有内容进行更好的记录？”

我对你的建议不是那个家伙。

总有一天，您将成为一名受雇并付钱做出这些决定的高级人。那天到了，去吧！直到那一天，意识到你的位置是什么。我有一个老板，就我而言，我的整个工作就是让老板高兴。这不是第二次猜测我的薪水等级以外做出的决定。如果您不确定，请与您的老板/主管交谈并找出答案。

但总的来说，让每个人都采用过时的方法要好于过时的方法，而不是采用过时方法的团队的一半，采用某种新方法后的团队的1/4，以及尝试开发前沿技术的团队的1/4 ，全新的方法。

我认为所有这些都有一个暗流，请明确提出：不要好斗。保持你与他的关系。接受他的建议，并在诸如此类的书籍和网站上进行验证，这很不错，但不要攻击他。如果他是一名高级开发人员并且已经完成许多项目，那么他不是白痴，还有很多可以向他学习的东西。看起来您已经完成了，表达了理解他的观点的愿望。即使您确定他错了并且您是对的，也要接受相反的可能性（似乎您已经了解了这一点）。试图弄清楚你在争论是因为你想更好地理解他的观点，而不是因为你试图证明他是错的。

如果当您问他一个问题时他没有立即与您联系，或者如果他的回答含糊和/或无益，请不要以为他是在开除您。正如这里已经提到的，他可能很忙和/或感到压力。

耐心也很棒。在您的脑海中列出您认为应该做的不同的事情的清单，并在适当的时候提出。除了“这是最佳实践”之外，请确保您对该建议有正当理由。并且要小心行事，不要犯错，这样以后当您提出论点时就具有信誉。

到目前为止，我一直在尝试通过听他讲话，提出一个反对意见，再提出他的观点（大多数时候，他会说最好的做法，更易于维护，但是没有走得更远），从而避免了这个问题。 ..在家想一想，但是...我还是不服气。但是最近他...看到了我的代码并问我为什么不将其更改为他的建议。这是2--3周内的第三次。

（针对操作进行了略微编辑。）

这部分与我有关。判断自己是否正确的一种方法是理解他在说什么。我读到的内容（根据我自己的历史，其他人可能会有所不同）是一个初级开发人员，不了解指导者在说什么，也不要求澄清。您能弄清楚的一种方法是请他澄清：这比这更好吗？还是为什么这比我们的代码更具可维护性？如果您不知道他的回答，那么您真的不知道他是否提供了很好的建议。

我真正担心的是，他要求您多次更改它，而您没有。从他的角度来看，这是一种可能的方式：他要求您进行更改，您问为什么，他给您（在他看来有效）的原因，而您拒绝进行更改。您不需要澄清，因此他假设您了解原因，并且太懒惰或太顽固而无法更改它-对于高级开发人员来说，考虑您并不是一件好事。相信我，问问题比以这种方式获得声誉要好得多。

一些想法：

1 /有效吗？他的方式有效吗？是客观原因导致他的方式会逊色吗？

出于客观原因，我的意思是可以毫无歧义地进行度量（性能，错误，代码长度...）。如果他的解决方案有效并且没有客观指标表明这是一个糟糕的解决方案，请按照自己的方式来做。他的方法更好……因为它可能与代码库的其余部分更加一致，并且对他来说，使用/重用您的工作将更加容易。您可能不喜欢它，但这不是它的意思，不是吗？

如果它不起作用，或者在重要指标上表现不佳，请实施它，将他的解决方案与您的解决方案进行比较，然后告诉他您已经尝试了他的方法，但是您无法使其表现良好（给出指标）并询问他如果您在实现中犯了错误，或者您有一个不知道的要求

2 /明星程序员说...为什么要该死？您会发现著名的程序员在许多基本主题上彼此矛盾，例如规划，设计，OOP与过程，单元测试，异常处理，源代码控制等等。

如果两个解决方案之间的唯一可操作性差异是谁喜欢它，请跳过它。通过不喜欢的范例进行工作，您可能会从所需的心理锻炼中受益

基于您只应该向想要成为自己的人咨询的想法，答案是，如果您想变得像他/她，高级建议是好的。

我的大部分问题都是通过发布到论坛上并得到其他人的答复来进行分类的，我已经像这样存活了大约一年。

在这种情况下我该怎么办？

老实说，这就是很多技术工作的样子。您必须是一个自我启动者，可以根据需要自己解决难题（在互联网及其居民的帮助下）。

从获得代码审查和获得体系结构设计帮助的角度来看，即使我有好的管理人员，除“静态变量应以s_开头”之外，我也从未进行过太多的代码审查。

抓住机会学习和学习如何学习；这些将是您将来可以使用的技能。

如果您想一想管理层不了解您真正有能力完成工作，那么您可能是错的。管理层也可能知道，如果他取代您并接管您的工作，那么您现在的领导将是完全无用的。

他们没有重新安置您的真正原因是，尽管您面临所有挑战，但您仍然是最合适的人选。他们显然对您的工作过于重视，以至于无法将其移交给其他人。

不要小看管理层的智慧...

它们比大多数开发人员认为的要聪明得多。直到开始管理，我才明白这一点。他们可能也知道您的线索确实是无用的，但是他们可能无能为力解决这个问题。

让我为您描绘一幅，在公司有5年工作经验的Lead A无能为力。经理知道这一点，建议他解雇上级主管。上级经理问，如果他这么不称职，为什么几年前没有与他打交道。经理现在看起来很糟糕，尤其是因为线索A的薪水过高，却无济于事。

这是另一种可能的情况，线索A与重要人物是密友。他在政治上太热烈，无法承担责任，

无论哪种方式，都有一个长期运行的错误，例如大型组织更容易将不称职的人扫到地毯下，给他们忙碌的工作和虚假的权力，这些权力适合他们多年无法承受太多“损失”的“经验” 。不幸的是，许多组织宁愿这样做，然后才真正解决问题。

当然，这样做的原因是，这种组织中的经理总是比短期解决这类人才可能给组织带来的长期问题更好。

因此，尽管它是短视的并且可能是不道德的，但您必须承认，它比许多开发人员实际认为的要聪明。

啊啊。这个问题使我想起了很多事情。首先，我要说的是我无法与上一个工作场所的一位经理相处。这不是人格问题。这是一个沟通问题。我说XYZ和那个特定的经理会打断我所说的ABC。除非我与该经理一起工作了一年以上，否则我将无法很好地沟通。

过去的这个周末。一个人就单身人士与我争论/不同意。我说过它们不好，永远不要使用，绝对没有理由使用它们。我将他链接到http://www.gmannickg.com/?p=24，并链接到了更深入的文章争论后的几天。另一位程序员（DudeB）提到他只在适当的时候使用单例（我在“ never”中加了）。DudeB没说什么，但是DudeB确实说DudeB在一个有内存争用的项目中，因为所有线程都在访问单例。在提到这一点之后，展示文章并提及内存争用，我所争论的那个人说我们必须同意不同意我同意的观点，因为我不喜欢谈论单例（但我正在写这首歌）

点是。有时您可能会像这个家伙一样犯错（也许有人会在评论中与我不同意单身人士）。在我的经理（我的高级程序员）的情况下，我只是做了我明确要求做的事情，而且我再也没有认真对待那个工作场所的质量。当允许时，我确实做了我喜欢做的事情，但总是按照要求做，但是如果我不同意，我至少会提出一次。

我对此有完全不同/有争议的看法。

人们常常不了解最终目标，对于大多数行业而言，最终目标是实现利润最大化和损失最小化。我知道这听起来很无情（因此有缺点），但是如果您不打算取得成果，经验和睿智就无关紧要。

人们可能会陷入极度间接的琐事中，而这些事情对公司的直接结果影响很小。

如果您认为某件事是对的，那么最好的选择就是证明这将如何产生更好的可测量结果。

最初，我会尝试坚持下去，直到一天结束时，对长者的抵抗至少在您获得更多经验和尊重之前可能是徒劳的。以此作为学习经验，如果您仍然有相同的想法，请在2年以上的时间内-转到另一家公司。那是您可以结合使用您的和上司的好主意来打动您的新雇主的时候。当然，您可能会在职业生涯的较早阶段就开始意识到一些错误决定的原因，并且有时您可能会雇用一名初级开发人员。

[转贴：因为我不知何故在这里创建了第二个帐户]

但是最近，他再次找我，看了我的代码，问我为什么不把它改成他的建议。

您应该清楚这些是建议还是命令/指令/指令/其他内容。

建议=我认为最好这样做。但这是你的选择。

订单/等 我想这样做；这是我的选择。

如果这确实是一个建议，请按照您的意愿做，让您的代码站起来。如果是命令（此导师以这种方式对您具有控制权）-按照他们的指示进行。