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


129

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

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

实际上,我已经当了10年程序员。但这是我的第一个多线程嵌入式linux工作-我已经在这里工作了2年,对每个人来说,我仍然在努力挣扎。而且我认为我已经变得如此沮丧和边缘化,以至于我失去了工作之初的很多热情。

有没有人遇到过类似的情况?如何提高错误修复率?


更新:我进行了审查。我参加了一个为期3个月的“员工发展计划”(Dunk提到的那种)。不知道我是否可以解决这个问题。但是,即使我必须继续前进,我也从这次经历中学到了很多东西。

另一个更新

自第一次审核以来,大约有6周。我对面临同样情况的任何人的建议是要谦虚接受批评并从错误中吸取教训。并且不要害怕看起来愚蠢。提出很多问题。让人们知道您正在尝试学习,并不断询问直到您理解为止。但是要做好准备,使其不起作用。我正在构建代码组合……并尽力而为。

另一个更新

我很犹豫,在这里,因为我担心我无法将未来的雇主介绍给我的stackoverflow个人资料...但是,无论如何,有人读这个问题可能很有趣,但是我却真的迷失了我几周前的工作。我正在重新学习所需的所有技能-我从这里提供的建议中学到了很多。


170
让您的老板知道他很高兴保存您的评论,而不是在他发现这是一个问题时不提。
Blrfl

13
维护编程需要某种人员。也许这不是你的事。同样,新的发展需要另一种人。您谈论发现工具/技巧/技巧。您为自己使用创建了哪些工具?如果答案是否定的,那么我真的认为您不是维护编程类型的人。如果您由于缺乏绩效而在多个项目之间徘徊,那么请以明确的信息表明您不具备所担任的职位的资格。请找到更适合您的职位。
Dunk

40
如果您不得不猜测由于性能而被改组,那么管理层做错了什么。同样,如果您第一次听到业绩不佳是在两年之后,那么管理层做错了什么。
萧伯纳

32
@Bee:通常,一旦有人对您的评价不佳,就该离开了。他们可能会让您加入“员工发展计划”,但我认为我从未见过有人一旦进入这一阶段就可以康复。找到工作最简单的时间是当您已经有了工作时。因此,如果我是您,我将更新我的简历,并很快开始寻找其他地方。您还应该对所从事的工作类型非常小心。7年的经验仍然留下选择。一旦达到10,公司将期望在特定领域的专业知识。选择一个自己喜欢并且擅长的领域。糟糕,您刚刚看到已经达到10分。
Dunk

8
尚不足以作为一个答案,但是关于“更快的方法”:您指出这是一个新领域。可能是您要解决的方法是反复试验,并不真正知道正在发生什么“深入”?在这种情况下,全面学习基础知识将使您更好地发现潜在问题。
Matsemann

Answers:


80

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

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

  1. 你没有他们聪明。有可能吧?(研究表明,我们所有人都不如我们的朋友那么受欢迎不那么有趣,并且(随之而来)也没有我们的朋友聪明。)因此,也许您只是头脑迟钝。再说一次,就您而言,我认为这不太可能。快速浏览一下您的StackOverflow配置文件,就可以了解您在各种主题上提出智能问题的历史。因此,您显然是一个思想家,并且也许是一个很好的思想家。

  2. 你太瘦了。您的同一SO配置文件表明,您的问题涵盖了过去两年中非常广泛的技术(图形,Web,Python,C ++,C,Linux,嵌入式,线程,套接字等)。就我个人而言,我知道当我陷入(或想要)探究多种不同流的情况时,我发现自己确实在快速(或更确切地说是在缓慢)游向上游。也许您真正需要的是FOCUS。也许还有健康的优先次序。无论如何,您可以将不太重要的锅放回炉子中,然后将主锅上的热量调高吗?

  3. 你没玩 当大火熄灭时,蒸汽机注定会减速。您在帖子中承认自己的士气最近受到了严重打击。不幸的是,您已经陷入了自我增强的负谐波的吮吸旋涡中,该谐波会破坏桥梁。这是一个非常熟悉的螺旋:艰巨的任务->压力->错过最后期限->更多压力->应对机制差->更多压力->拖延->更多错过的最后期限->批评/八卦(真实的或想象的)- >压力更大。您得到图片。这很少导致有用的地方。从我白水漂流的日子里汲取教训:当您被4级急流背面的循环水吸引到水下时,您的救生衣不会使您浮回水面。最好的策略(虽然不直观的)是找到底部的河流,并走出了激流的。因此,我对您的建议是:找到一些基础,老兄(朋友,教堂,健康的新习惯等),并利用它来使自己走出漩涡。

  4. 您不在您的区域中。迈克尔·乔丹(Michael Jordan)成为了一个非常la脚的棒球运动员。(好吧,他仍然比我强,但绝对是个小联盟。)也许“多线程嵌入式Linux”不是您的专长。但是软件开发的领域非常广泛(如您所知;参见上述#2)。您的公司是否足够广泛,可以找到其他利基市场?在上一份工作中,我被聘为嵌入式软件开发人员。(我没有这个领域的经验,但是我告诉他们我是一个“快速学习者”。)我很快就沉如石头。但我一直在努力工作,并一直在寻找我的问题做了知道如何解决他们。事实证明,我逐渐能够转移到新的职责上,使我可以大放异彩,并为此获得了相当的赞扬。因此,也许您需要重塑自己的品牌。

关键是:如果你很慢,那是有原因的。但是, -您是一名软件工程师,伙计!调试自己!


2
真是个绝妙的答案。我认为所有的点都适用于我(和关于#1,以及或许我不聪明,我听说有不同类型的智慧-也许这是关系到#4也许我numbskull嵌入式Linux开发但也许我在网络方面比较擅长...现在我考虑一下,这实际上可能是现实的)。无论如何-您很有洞察力。
BeeBand

14
3和4(对于程序员)比大多数老板想象的要大。如果程序员士气低落,他/她将无法专注于工作。对于程序员来说,士气就是动力,而动力就是一切。
2013年

7
极好的答案。顺便说一句,调试自己是一个好短语。希望我能再次支持您。
Kyeotic

2
您的“会遵循”在第1点不起作用,因为友谊悖论将两个人之间的关系建模为图中两个顶点之间的简单双向边,而图中谁比谁必须考虑“更聪明”还有许多其他因素,更不用说传递性规则不适用。我确实同意第2、3和4点。就OP而言,我认为他的老板是一个混帐人,遭受了邓宁·克鲁格效应。
funkymushroom 2013年

1
程序员,自己调试。爱它:)也不错的答案。这对我很有用,不是因为我处于那种情况,而是因为我现在看到了如何避免这种情况。+1
jammypeach 2014年

56

您的老板可能是正确的:您可能“表现不佳”(稍后再介绍)。但是,责任不只是您的能力水平。我认为,无法控制之外的力量会给您造成压力,这对您的表现没有负面影响。

让我们看一下您的老板现在提出这个问题的一些原因:

文化与政治

可能存在无法控制的力量,要求您的老板现在表达他的关注。了解您正在使用的系统很重要。您的工作是使老板看起来不错。唯一的方法就是了解他/她承受的压力。

能力

正如您所说的那样,他的能力很可能达不到标准。在这种情况下,我将执行以下操作:

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

如果您的表现很慢并且基于实际差距,请找出该差距,并与老板一起制定详细计划,以弥补这一差距。

这次审查也是一个很好的机会,可以证明您不满意。确认您不喜欢这份工作是一件好事。但是找出原因。您喜欢工作的哪一部分,不是吗?可能是这份工作不适合您...


2
这是一个很好的答案。对于我为什么不喜欢这份工作,我有一些思考。主要是它们给我们提供的伴随错误的日志文件,我比其他任何人都更讨厌它们-我总是在黑暗中完全,完全从他们给我的任何错误开始。我认为我讨厌这种“黑暗中”的感觉。
BeeBand

4
除非有人在同一项目上遇到过类似的问题,否则大多数人会在遇到新错误时“在黑暗中”开始工作。然后根据症状,找出如何重新创建问题,这应该为从哪里开始猜测问题的原因提供思路。您继续一步一步。没有魔法,没有讨厌的东西。您说您讨厌日志文件。您是否创建了任何工具来自动分析那些日志文件?忽略了日志文件应该有用的事实,如果不是这样的话,不久之后我便创建了一个工具来帮助我对其进行分析。
Dunk

1
@Dunk是的,我确实创建了一种工具来以多种方式解析日志文件。之后我发现有人一年左右就已经创建了。
BeeBand

@Bee:您创建的工具显示了一些必要的主动性。在项目之间进行转换时,没有人给您概述开发环境吗?如果存在工具,那么项目负责人肯定会让您知道它们的。
Dunk

@Dunk re概述-不。我的第一支团队负责人为我展示了一种特定的工具-但没有指出该工具可用于修复特定类型的错误或可以转换为其他项目。当我转到这个新的维护项目时,没有人在开发环境中与我交谈-我只需要四处询问。只是在努力构建自己的工具之后,我问了一位同事,他提到了我该如何使用原始工具。(注意,这是与我之前的评论不同的工具)。
BeeBand

38

某些工作环境不可行。我见过没有人能够生存的环境(对于刚加入的人而言,这是不存在的),因为很多东西都没有记载,而且强烈建议不要提问题。

您确实需要对期望和为帮助您实现期望而提供的资源诚实。问题可能不是你。

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

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

对于您而言,要做到就已意味着您已经做了正确的事情,并且有为您做的事情。

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

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


2
我见过我职业生涯中完全一样的团队。他们维护的代码是庞大而隐秘的,并且会严格保护有关其工作方式的信息。新团队成员被故意留在自己的设备上,并最终转移以挽救自己的职业。
Anthony Giorgio 2013年

31

首先,请注意:此答案仅适用于非法遣散雇员而被解雇的某些地区。那个...

这可能是建设性解雇的情况,属于非法行为。

策略是使员工士气低落并降低其自尊心,直到他们辞职为止。这是公司无需支付遣散费或解决不得不面对员工并解雇他们的问题,从而节省资金的一种方法。

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

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

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

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

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

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

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

这就是为什么我认为您发现自己处于建设性解雇中间的原因。他们对你不满意,所以直到你离开之前,他们都会把你当作废话。

而且我认为我已经变得如此沮丧和边缘化,以至于我失去了工作之初的很多热情。

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

参考文献

我不是律师,但是Google在星期一输入一些讨论建设性解雇主题的文档时值得阅读。这里的重点是要当心公司的薪水减少,羞辱和职业突然改变。

请注意以下相关事实:

  • 在困难的工作条件下未能适当地支持员工
  • 对员工的过分约束短时间内改变员工的工作地点
  • 实行减薪或减薪

法律问答:建设性解雇

提出建设性解雇的理由

维基百科

建设性解雇的要素


11
这不是违法给予负面的绩效评价,但他们必须是客观的,并同意将工作可行的标准,并支持你。
pjc50

9
当我发布答案时,我想,也许我反应过度了,但阅读您的帖子后,我的经历引起了共鸣。错误修复不能用性能上下文来衡量。我花了3个月的时间来修复一个错误。通常,聪明的人是会遇到困难的人。
Reactgular

9
我投票失败,因为我看不到任何证据表明您是律师,并声称提供法律建议。另外,如果其他员工平均每个月修复X个bug,但操作人员正在修复X / 10,那绝对是客观和合理的。
安迪

7
@Andy感谢您分享投票理由。我同意错误修复率是一个指标,但是在下周五告诉某人他们的负面评价是客观的。除了巧妙地让他们在周末流汗。假设期望的结果是该员工周一不参加审核,是否不安全?那不算是建设性的解雇吗?我希望我能改变您的观点,因为建设性解雇是我们行业中一个持续存在的问题。
Reactgular

7
法官不可能裁定这是建设性的开除。您可以对法律条文进行修改和修改,但是这种类型的法律适用于员工受到骚扰或虐待,处于积极敌对状态的情况。根据OP的说法,他们被告知他们得到了负面评价,因为他/他在漏洞修复率方面还没有与其他同行竞争。这是一个艰难的处境,但几乎没有敌意,当然也不是非法的。也许老板可能会比较机灵,但是反馈不必
局限于

26

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

如果将您与之进行比较,那您将无所适从。总是要花更多的时间来加快项目速度,并且您不会知道所有潜在的交互点在哪里。

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

您可以使用笔记本或白板来绘制功能路径,线程和锁定生存期的图表,并标记出您观察到各种行为的位置以及可以在其中插入新探针的位置。

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


3
这是一个了不起的回应。我印象深刻。
Daniel Hollinrake

26

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

你能为这个做什么?

  • 调试时记笔记。只要始终打开编辑器窗口,并写下您的意识流即可。除了您,这对任何人都没有意义。您可能会发现这可以帮助您更快地进行调试,但这也意味着您需要具体指出一些事实,以证明您整周都没有在玩Nethack。

  • 与所有同事比较笔记。他们通常需要多长时间来修复错误?他们的错误是否固定?他们多久更改一件小东西并发现自己被一堆串连串的后果淹没?这些问题的答案将使您对与部门的其他部分是否真正挣扎有所了解。

  • 与质量检查人员和客户支持人员交朋友。他们对错误的重要性有最好的了解。通常,这与错误的难易程度几乎没有关联,因此您可以稍微玩一下系统,然后尝试分配所有高重要性,低难度的错误。(这并不是真正的作弊。组织良好的团队始终会首先解决这些错误。)

  • 如果您的老板连续两年没有为您提供有关绩效的充分反馈,那么首先要提出此绩效评估的问题,然后当您得到解决方案时,就需要与老板的老板一起提高。要有礼貌,尤其不要让他们看到你有多生气,而是要以书面形式提出具体批评。


4
“调试的难度是一开始编写代码的两倍。”
-Brian

4
@TimG:和其他程序员一样,Kernigan低估了难度。
亩太短了,

哇,我想指出,这是一个非常棘手的问题,我很惊讶在这里看到这么好的见解。谢谢。
maksymko

12

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

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

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


2
ended up getting micromanaged until I was terminated-好吧,我刚刚查看了您的SO资料,您显然已经从中反弹了,所以我发现您的反应令人振奋。我将在星期一谈论您的第一点-我收到来自不同地区的错误。
BeeBand

10

在工作两年后,每个人(您,您的老板,您的同事)应该清楚自己的立场。也就是说,您永远都不应发现自己一年做的不好。理想的工作环境将提供持续的反馈。

无论如何,关于如何调试多线程代码:您没有提到这是否是您的代码还是其他人的代码。有一些新的调试器和静态分析器可以处理并发。但实际上,知道模式将是您最好的选择,因为您会知道要寻找什么。

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


2
是的,这不是我的代码-这是一个庞大的嵌入式系统,始建于10年前。我认为您对模式是正确的-我需要回到基础知识。
BeeBand

1
@BeeBand,很高兴知道您的情况。希望一切顺利。
Daniel Hollinrake

10

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


知道BeeBand是否已经做到这一点将会很有趣。阅读评论和答案似乎是一个非常不友好的环境。
Daniel Hollinrake

1
好吧,我对此表示同情。我知道在一家开发团队忙于工作的公司里会有什么感觉。幸运的是,尽管在我的情况下,我与一些出色的同事一起工作,但我们互相照顾。有谁可以配对吗?花时间训练您并帮助您提高生产力将为每个人带来回报。从您做事的声音和尽职尽责的工作中,您的公司将从您的利益中受益。
Daniel Hollinrake

8

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

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

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

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

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


7

首先,增强信心:

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

无论如何,不​​可能为发现错误设置时间限制。毫无疑问,Bug狩猎是一项技能,其效率非常有价值。

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

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

另外,您如何理解并发?如果您已经开发了十年,但是大多数经验不是使用多线程代码,那可能是个问题。

您应该详细研究多线程:不仅仅是了解如何使用API​​,而是真正深入地了解它。如果您正在执行多线程编程,那么您应该是那种能够从一英里远的地方查看代码库并发现竞争状况,死锁,优先级倒置,饥饿等情况的开发人员。


1
并发性的最大问题是,编写无错误的代码要比修正错误代码中的错误要容易得多。特别是如果代码几乎正确。而且错误通常不在一个地方,而是分布在很多地方。
gnasher729 2014年

5

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

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

我认为我的建议只是部分地解决了您的问题,但是无论如何都值得一读,因为使用遗留代码对任何开发人员都是不可避免的。


我目前正在根据您的建议阅读。
BeeBand

3

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

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


据推测,它以封闭的问题/时间单位来衡量。说“好吧,有些错误比其他错误花费更长的时间”可能是合理的,但是除非OP在代码中特别困难的部分工作并且其他所有人都在做简单的事情,否则可能不会停滞不前。
加勒布

3

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

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

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

如果该推进装置长时间不存在,则继续前进。

您正在浪费时间和精力在一个烧钱的雇主身上,这不能使您的兴趣不断/技能更新/作业充满挑战性和/或使您感兴趣。那是管理层的工作。除此之外,它们纯属开销。

保持激情,因为这是关键。


2

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

“但是令人沮丧的是,我到那里一年半后才发现某些工具/技巧/窍门。我从一个团队转到另一个团队(我想我的表现不佳),我发现这些“隐藏”工具经常出现。”

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

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


2

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

因此,首先,记录您遵循的过程。确保记录该过程中每个步骤要实现的目标。

您可以将流程概述为具有以下任务:

  1. 确保您完全了解正在报告的问题。
  2. 尝试重现该问题。
  3. 开始将问题分解成小块
  4. 考虑问题的可能原因。
  5. 测试那些假设

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.