有什么方法可以更快地解决错误吗？我刚刚受到老板的警告[关闭]

#1 楼

许多答案都对老板的方法/战术/指标/等提出了质疑。但这是没有意义的。也许你很慢。每个开发人员的房间都必须有一个比其他人慢的对吧？ （这只是简单的设定理论。）所以让我们假设是你。答案是，你为什么慢？ （很明显，这是您必须解决的问题，才能更快解决问题。）

可能有各种各样的原因，但是这里有一些可能的解释要考虑：


你没有他们的聪明。有可能吧？ （研究表明，我们所有人都比我们的朋友不那么受欢迎，不那么有趣，并且（随之而来）也比我们的朋友们聪明。）因此，也许您只是头脑迟钝。再说一次，就您而言，我认为这不太可能。快速浏览一下您的StackOverflow配置文件，就可以了解您在各种主题上提出智能问题的历史。因此，您显然是一位思想家，并且也许是一位优秀的思想家。
你太分散了。您的同一SO配置文件表明，您的问题涵盖了过去两年中非常广泛的技术（图形，Web，Python，C ++，C，Linux，嵌入式，线程，套接字等）。就我个人而言，我知道当我陷入（或想要）钻研许多不同的溪流的情况时，我发现自己游得非常快（或者说真的很慢）。也许您真正需要的是FOCUS。也许是健康的优先排序。无论如何，您可以将不太重要的锅放回炉子中，然后将主锅上的热量调高吗？
你没玩当大火熄灭时，蒸汽引擎注定会减速。您在帖子中承认自己的士气最近受到了严重打击。不幸的是，您已经陷入了自我增强的负谐波的吮吸旋涡中-一种会破坏桥梁的力。这是一个非常熟悉的螺旋：艰巨的任务->压力->错过最后期限->更多压力->应对机制差->更多压力->拖延->更多错过的最后期限->批评/八卦（真实或想象中的）- >压力更大。您得到图片。这很少导致有用的地方。从我在激流泛舟的日子里汲取教训：当您被4级急流背面的循环水吸引到水下时，救生衣不会使您浮上水面。最好的策略（尽管不直观）是找到河底，然后走出激流。因此，我对您的建议是：找到一些勤奋的人（朋友，教堂，健康的新习惯等），并利用它来使自己走出漩涡。
您不在您所在的区域。迈克尔·乔丹（Michael Jordan）成为了一个非常la脚的棒球运动员。 （好吧，他仍然比我更好，但绝对是个小联盟。）也许“多线程嵌入式Linux”不是您的专长。但是软件开发的领域非常广泛（如您所知；参见上述＃2）。您的公司是否足够广泛，可以找到其他利基市场？在上一份工作中，我被聘为嵌入式软件开发人员。 （我在那个领域没有经验，但是我告诉他们我是个“快速学习者”。）我很快就沉如石头。但是我一直努力工作，一直在寻找确实知道如何解决这些问题的问题。事实证明，我逐渐能够转移到新的职责上，使我可以大放异彩，为此我最终获得了相当的称赞。因此，也许您需要重塑自己的品牌。

关键是：如果你很慢，那是有原因的。但是，嘿-您是一位软件工程师，伙计！调试自己！

#2 楼

您的老板可能是正确的：您可能“表现不佳”（稍后再介绍）。但是，责任不只是您的能力水平。我认为这并不能暗示您无法控制的力量会给您造成压力，这会对您的表现造成负面影响。

让我们来看看您的一些原因老板现在可能要提出这个问题：

文化和政治

也许有些势力无法控制，您的老板现在必须表达他的关注。了解您正在使用的系统很重要。您的工作是使老板看起来不错。做到这一点的唯一方法就是了解他/她承受的压力。

能力

能力很可能达不到您所说的能力。在这种情况下，我会做以下事情：

从您的老板那里获得关于他如何衡量绩效的具体反馈。您关闭的错误不如X人吗？您应该解决一定数量的错误吗？如果您是一个人工作，则需要确保评估您的绩效的人员正在公平地评估绩效，而不是基于一些先入为主的想法。

如果您的表现缓慢并且存在实际差距，请找出该差距并与老板一起制定详细计划，以期弥补该差距。

这篇评论也是一个很好的机会，可以证明你不高兴。确认您不喜欢这份工作是一件好事。但找出原因。您喜欢工作的哪一部分，不是吗？可能是这份工作不适合您...

#3 楼

某些工作环境不可行。我见过没有人能够生存的环境（为刚加入的人们所幸免），因为很多东西都没有记录在案，而且强烈建议不要提问题。

你真的需要对自己诚实关于期望和提供的资源以帮助您实现这些期望。问题可能不是你。

您提到有些人从事与您相似的工作，我认为这些人没有困难，但是对您2有5年以上的经验。与同龄人相比，您感觉如何？ ？他们是完全超越您（在这方面）的摇滚明星，还是像您一样？也许他们只是在更简单的时候才了解该系统...您提到在从事此工作之前有8年的编程经验。你在那里怎么样？如果您做得很好，那应该告诉您一些事情。

让我印象深刻的部分是，您将自己描述为对自己遇到的所有错误都处于黑暗之中。可能是因为代码库是如此庞大且未知，以至于期望可能不合理。

达到目标就意味着您已经做了正确的事情，并有自己的目标。

最重要的是，您需要对自己和所做的事情感到满意。如果那意味着继续前进，那就这样吧。

继续前进比找一份工作毁了你的生活。

#4 楼

首先，请注意：此答案仅适用于非法遣散雇员而被解雇的某些地区。就是说...

这可能是建设性解雇的案例，而且是非法的。

策略是要挫败员工的自尊心并降低其自尊心，直到他们辞掉工作。这是公司无需支付遣散费或解决不得不面对员工并解雇他们的问题的一种省钱方式。


他想和我谈谈为什么我太慢了，为什么我的错误修复率这么低。


此错误非常模棱两可。政党的任何一方都不可能声称对方是错误的。您花了一个月的时间来解决一个错误。所以呢！通过陈述事实来支持您要求一个月的要求，您可以处于防御状态。考虑到您当前的技能，经验和知识。作为雇主，管理员工的时间和精力是雇主的工作。雇主必须是承担与修复错误相关的风险的人。不是员工。他总是可以选择将错误分配给其他人。

如果您是承包商，并且合同中规定将负责错误的修复，那么情况就完全不一样了。

雇主抱怨您花费太长时间是错误的吗？绝对不是，但是他不能要求您对此负责，也不能因此而解雇您。他可以对您说：“我们没有更多需要您技能的错误，您可以休假。”但是他们必须告诉您新问题可以解决的那一刻。否则，他们必须遣散而终止。他不能做的是给您您无法处理的工作，然后抱怨它。我认为这是非法的。


我喜欢编程和解决问题，但实际上确实发现我的工作真的很辛苦。


找工作很难找到工作，而雇主给您的工作太辛苦了，两者之间有很大的区别。如果您认为完成分配给您的任务阻碍了您在公司工作，那可能是非法的。


我实际上已经从事程序员大约10年了。但这是我的第一个多线程嵌入式linux工作-我已经在这里工作了两年，对于每个人来说，我仍然在努力挣扎。


这就是为什么我认为您发现了自己正处于建设性解雇之中。他们对你不满意，所以直到你离开之前，他们都会把你堆满。


我想我已经变得很沮丧，被边缘化了，失去了很多


雇主有责任提供安全和积极的工作环境。没有更多信息（很可能是个人信息），局外人很难说出这里到底发生了什么。要求职业律师提供免费咨询。他们将能够告诉您您是否正在玩游戏。

参考文献

我不是律师，但是Google是否讨论了一些关于建设性解雇的文件，值得一读，然后在周一输入您的评论。这里的主要要点是当心公司的薪水减少，羞辱和职业突然改变。

相关事实请注意：


在艰苦的工作条件下未能适当地为员工提供支持
员工的过多纪律
在短时间内改变员工的工作地点
实行减薪或减薪

法律问答：建设性解雇

提出建设性解雇的理由

维基百科

建设性解雇的要素

#5 楼

也许您正在与某个项目的原始程序员进行比较。我知道，作为我所从事的项目之一的原始开发人员，在修复其中的错误时，我拥有巨大的优势。我不认为这是因为缺少文档，只是我可以凭直觉跳到潜在的问题，因为我的大脑知道所有代码。

如果将您与之相比，那么你就是不会去衡量。总是会花更多的时间来加快项目速度，并且您不会知道所有潜在的交互点在哪里。

我读了您的评论，关于不了解工具和其他程序员用来解决问题的技巧。也许对于下一个错误修复，您需要尝试配对编程。这可能非常有用。轮流驱动键盘。多说话。

您可以使用笔记本电脑或白板来绘制功能路径，线程和锁的寿命，并标记出您观察到各种行为的位置以及可以在其中插入新探针的位置。

解决这类低级别的线程问题可能真的很困难，我非常感谢您。在发现两行问题之前，我必须分析数GB的日志文件。你知道吗？我盯着那个眼睛待了好几天，然后才向一年前实习的初级工程师寻求帮助，然后他想出了一种新方法，在一小时内发现了问题。因此，在花了一些时间解决错误之后，请多加注意。它可以有很大帮助！

#6 楼

在这个行业中最常见的管理功能障碍之一就是不了解调试本质上是困难的。我有将近20年的经验，我仍然经常不得不花整整一周的时间找出导致该程序崩溃的单行错误（五十分之一）。然后，如果我的经理不理解这些内容，他们会麻烦我花一个星期的时间来更改一行代码。

您该怎么办？


调试时记笔记。只要始终打开编辑器窗口，并写下您的意识流即可。除了您，这对任何人都没有意义。您可能会发现这可以帮助您更快地进行调试，但是这也意味着您需要具体指出一些事实，以证明您一周都没有在玩Nethack。
与所有同事进行比较。他们通常需要多长时间来修复错误？他们的错误是否固定？他们多久更改一件小东西并发现自己被一堆串连串的后果淹没？这些问题的答案将使您对与部门的其他部门是否真的很挣扎有所了解。
与质量检查人员和客户支持人员交朋友。他们对错误的重要性有最好的了解。通常，这与错误的难易程度几乎没有关联，因此您可以稍微玩一下系统，然后尝试分配所有高重要性，低难度的错误。 （这并不是真正的作弊。组织良好的团队始终会首先解决这些错误。）
如果您的老板连续两年没有就您的表现给予足够的反馈，那首先是一个问题提出这项绩效考核，然后在得到解决方法后，与老板的老板一起提高。要有礼貌，尤其是不要让他们看到你有多生气，而是要以书面形式提出具体的批评。

#7 楼

当您可能喜欢编程和解决问题时，可能会遇到一个问题，即您将所学知识运用到其他领域的程度如何。您所修复的大约十二个错误中是否有一个足够相似，以至于帮助您修复一个的bug对另一个有用？这是回顾您所做的工作以及完成该过程需要花费多长时间的一部分。只是要考虑的一个想法。

其次，我将研究您的工作方式。您是否经常受到打扰，因此当您尝试修复错误A时，会被告知错误B和C的优先级更高？仔细考虑一下工作方式的哪些变化可能会对您有所帮助，因为这很可能是老板想知道的一部分。

我有一些工作地点告诉我，不喜欢我花多长时间才能完成一些工作。当然，在这些地方，如果我完成一件事情，就会在我的腿上丢下5件新东西，因此很容易不知所措。虽然我可能不再在那里工作了，但是我对于如何将注意力集中在几件事上并没有一个好的解决方案，因此我不会觉得自己想一次全部掌握1000件事。如果我能知道一些要完成的关键事情以及如何判断我的工作，那我比拥有一英里长的“待办事项”清单要好得多，而且似乎没人在乎部分完成。因此，这可能是组织内部文化的一部分，尽管我会谨慎地要求改变这里的情况。我记得在一个工作场所，我要求更多的反馈，并最终受到微观管理，直到我被解雇为止，因为我不仅仅遵守待办事项清单上的内容。

#8 楼

在工作两年后，每个人（您，您的老板，您的同事）应该清楚自己的立场。也就是说，您永远都不应发现自己一年只做过一次糟糕的事情；理想的工作环境将提供持续的反馈。

无论如何，有关如何调试多线程代码：您没有提到这是您的代码还是别人的代码。有一些新的调试器和静态分析器可以处理并发。但实际上，知道模式将是您的最佳选择，因为您会知道要寻找的内容。

如果您了解关键部分，比赛条件和死锁的工作原理，那么您会处于更好的状态发现意外情况的位置。如果您看到两个线程之间没有条件变量的“通信”，或者资源没有特定顺序就被互斥，或者没有明显的原因声明了局部变量static，那么您就有潜在的错误！因此，学习您所在域的最佳实践，您将可以更好地判断何时出现异常情况。

#9 楼

除非必须，否则不要独自奋斗。招募同事。让他们帮助寻找错误。向他们询问他们的思考过程和工具。也许在您的评论中将此作为您改进计划的一部分。如果您周围的每个人在此系统上都做得更好，也许他们知道一些特定的知识？

#10 楼

老板刚刚告诉我，我将在周一收到负面的绩效评估。他想和我谈谈为什么我这么慢
，为什么我的错误修复率如此之低。


请注意，在任何非功能失常的公司中，事情不会发生在此订单上。如果老板担心您的表现，他应该设定短期目标，并谈论您的结果以找出问题所在。

相反，他决定给您一个负面评论，然后找出原因。听起来他不愿意让自己参与这个问题，而只是想在表中列出结果。

不要以更快地解决错误为目标。旨在评估自己的能力，检查同事的工作方式，他们如何知道自己的知识，并意识到这不是理想的公司。

关于实用技巧，我使用代码段和我自己的mediawiki做笔记。我始终牢记接下来要读哪些书，以及继续学习的方向。学习是获得更好工作和更幸福生活的途径。

#11 楼

首先，增强信心：

为什么要受苦？您可以轻松地找到一份他们会认为自己是“上帝”的工作，因为您可以进行Linux嵌入式的任何工作，而无论您的bug修复率如何。

无论如何，不​​可能在寻找错误。毫无疑问，漏洞搜寻是一种技能，而且效率很高，很有价值。

您可能会缺少别人知道的一些基本技巧，这会使您的速度变慢。

例如，如果您和我正在使用某些Linux中间件，并且我正在使用Valgrind查找内存损坏问题和数据争用情况，而您仅依靠gdb和printf，即使即使您比我聪明。

此外，您如何理解并发？如果您已有十年的开发经验，但是大多数经验不是使用多线程代码，那可能是个问题。

您应该详细研究多线程：不仅仅是知道如何使用多线程。 API，但实际上是在更深层次上“获得”它。如果您正在执行多线程编程，那么您应该是那种能够从一英里远的地方查看代码库，并发现竞争状况，死锁，优先级倒置，饥饿等情况的开发人员。

#12 楼

我最近读了《有效地使用旧版代码》一书，这使我在解决任何代码库中的问题时都大大提高了信心。

如果您使用的代码不够完美，我认为这本书会有所帮助。我发现很多时间是为了修复错误，我需要首先重构周围的代码以什至理解它，然后一旦我理解了代码，并希望使代码可测试，跟踪并解决问题的难度较小。 （有时，我什至只是为了理解代码而重写了代码，然后还原了更改以减少引入新错误的风险。然后我插入了错误修复程序。该技术基于本书中的技巧。）

我认为我的建议仅能部分解决您的问题，而且是间接解决的，但这本书无论如何都值得一读，因为使用遗留代码对于任何开发人员都是不可避免的。

#13 楼

询问上级，您修复错误的速度是多少，团队修复错误的平均速度是多少。更重要的是，问他如何测量错误修复的速度...

这种度量标准并不是真正的度量标准；如果是这样，它将比LOC更加不可靠（尽管测量的是不同的东西）。如果没有适当的衡量，就没有理由指责您任何事情。

#14 楼

认识到您不是与雇主和/或客户一起工作。请在采访中毫不犹豫地提及，只是从一开始就将记录设置为正确。

您是在小企业（即您自己）上投入大量资金的专业人士。

您愿意在有利益联盟的情况下每天都将您赶出机架。

如果这种推动力持续了很长一段时间，请继续前进。

您正在浪费时间和精力在流连忘返的雇主身上，这使您的工作兴趣不断/技能不断更新/作业充满挑战和/或有趣。那是管理层的工作。除此之外，它们纯属开销。....

继续前进，因为这是关键。

#15 楼

我一直在类似的情况下，因为我害怕寻求帮助。从您在此评论中所说的话来看...


“但是令人沮丧的是，我在那里呆了一年后才发现某些工具/技巧/窍门一半了。我已经从一个团队转移到另一个团队（我想我是因为表现不佳），我
经常发现这些“隐藏”工具。”


...您可能遇到了与我相同的问题。调试就像编写代码一样，是一种技巧，而无需首先进行很多调试。观看其他开发人员解决调试问题的工作可能具有很高的教育意义。当您在整理某些内容时遇到困难时，请寻求帮助。尤其是如果您要覆盖以前从未有过的土地。最好在恐慌之前就这样做，因为您还没有完成任何事情。

话说，我同意管理层在做错事情的评论。如果有人在为某事而苦苦挣扎，他们应该在负面评价开始之前就获得帮助。地狱，如果团队中的任何人都在挣扎并且从未得到帮助，我想说团队中的每个成员都在做错事（尽管这可能是人们过度仔细地查看其错误修复率的直接结果）。

#16 楼

OP所缺少的是提及解决错误所遵循的可重复过程或方法。

因此，首先，记录您遵循的过程。请确保记录该过程中每个步骤的意图。

您可以将过程概述为具有以下任务：


请确保您理解确切地报告了问题所在。
尝试重现问题。
开始将问题分解为小块
考虑问题的可能原因。检验这些假设

了解这些错误是否已经存在很长时间，或者是随着最近的更改而引入的。如果这些错误是由于最近的更改而引入的，那么进行代码审查和/或仅阅读人们正在创建的代码会有所帮助。

我认为，如果您可以清楚地定义问题，例如，“我尝试解决错误时，如果不考虑要测试的假设”，那么您可以获得更集中的建议。