永远不要只提出问题

我看了一下你的资料，注意到你在StackExchange社区已经有一段时间了。毫无疑问，你会注意到，在这里得到最好回复的问题都是那些提出问题，并试图回答问题的理由的问题。如果你要问一个问题，那么你要确保也要让他们知道你自己已经做了什么尝试回答这个问题。这对你有很多好处：

• **这表明你并不是无谓的提问。如果你把你的推理暴露出来，那么你就是在让对方知道你在提出问题之前已经做了尝试，而不是偷懒。 *如果有同行带着问题来找我，暴露出他们是如何尝试回答问题的，不仅会帮助引导他们走上正确的道路，而且我还会帮助他们了解自己如何去思考这个问题，从而让他们自己去思考。你把自己的思维过程和推理暴露得越多，别人就越能帮助你在以后的问题上有所建树。

这里有两点需要解开。

我以为科技公司的其他人都喜欢谈技术…..

不一定。很多技术人员会谈论与他们现在所做的任务相关的技术，但可能对其他的事情完全没有兴趣。

我想你可能把这一点和：

当我试图解决一个我不熟悉的问题时，我也因为 “走错了路 "而被骂过，而不是问一个不熟悉的人

考虑一下那个哭狼的男孩吧 :) 如果你把别人的时间都花在谈论与自己正在做的事情无关的事情上，那么当你问他们一个相关的问题时，你可能会发现，他们可能会觉得自己已经和你失去了足够的生产力。

我基本上都是尽量自己一个人想办法解决的问题，至少有一个小时的时间。这是不是太短了？

在很多情况下，是的，太短了。除非你要解决的问题很简单，那么你应该投入更多的时间去寻找和尝试不同的变式。如果问题是简单，那么适当的网络搜索应该会得到正确的结果。

把这些放在一起，我看到的是一个年轻的程序员，他的判断力有一些问题，这也是你的HR告诉你的。这并不是不可克服的，但有些事情你需要考虑一下

–把假设性的技术问题留到午休室里，除非你很了解这些人，否则不适合把自己和别人的时间都浪费在无关紧要的问题上，这是不合适的。 - ***学习如何应用更好的网络搜索术语.如果有人告诉你，你问的问题太多和花了太多时间，那么很明显你问错了问题. - 问问题时，要表现出你已经尝试过的东西.经典的Stack Overflow心态。如果你没有任何东西可以展示出你为解决一个问题所做的共同努力，那么你还不够努力。事实上，如果有什么有形的问题要问，也不要害怕利用像 Stack Overflow 这样的资源，因为这可能是在公共领域。最后一点； –把问题留给特定业务的问题。不要问如何驱动你的编程工具，而_问一些领域或环境特定的问题，这些问题不会在公共领域中出现。你可能会发现，PIP可能是一个非常有价值的工具，可以帮助你成为一个更好的开发者 :)

问题是，当你打断别人的工作时，他们失去的不仅仅是回答问题所需的5-15分钟。他们失去了更多的时间，因为他们需要重新集中精力。而这可能是相当令人沮丧的。

我也遇到过类似你这样的情况。我以前经常去找人，马上就问他们问题。甚至当他们做了一些会阻挡我的事情时。这甚至可能会打断附近的其他人。

我的经理给了一个解决方案：使用电子邮件和即时通讯，即使对方坐在你旁边，也要用电子邮件和即时通讯。这样一来，你会更多的思考如何制定问题，在这个过程中，你可能会自己回答。另外，对方有空闲的时候也可以回答你。

还有一个办法，就是设置一个会议，把所有的事情都弄清楚。

我试着从公司的角度来回答。我不是那家公司，所以可能有些事情我没有看到，但我在自己的公司也见过这样的情况。

**多问*

你的困惑似乎大多来自于你不明白，问问题是个危险的游戏。是的！！！！！！！！！**

当你提出问题的时候，你就等于承认自己什么都不懂，***也*了自己想不通。作为一个软件开发者，你的任务之一就是要把它弄清楚。你是在侮辱 “目前的 "开发团队，基本上是在问："所以你写了这么烂的代码，我不可能弄清楚怎么读懂它，或者它在做什么，所以我要去需要你来解释给我听。”

现在，这里的棘手的部分是，有些时候正是这样，你应该提出问题。只是重要的是要记住，无论如何，这些问题都有其消极的一面。

另一件事，我觉得我在你的OP中感觉到的是，你问问题的时候太早了。对于一个新的开发者来说，坐在那里看书，研究一整天，写2行代码是绝对没问题的。事实上，以14年的经验，我最终还是会这样做。写专业的代码并不在于 “做了多少"，而在于 "做得有多好"，并且能够重复这种成功。我怀疑没有人会因为你花100倍的时间去做十分之一的工作而对你大喊大叫。事实上，当我雇佣一个人时，第一个月我就把第一个月当做没有期待任何真正的工作，而前6个月则认为没有什么期待。当你向团队成员寻求帮助时，你也在拉低这个人的工作效率。你在影响他们的流程的同时，也在侮辱他们（见上文）。如果你不得不求助于人，你就没有办法获胜。把每一次求助，都当成是一场败仗。你仍然可以打赢这场战争，但你输了这场战役。

有一些事情你可以做，以缓解这个问题：

1. 用电子邮件询问，千万不要当面或聊天。聊天可能是首选的 "正式 "方式，但电子邮件会更好，因为接收者可以在自己的时间内处理。

2. 从 "低下 "的立场去接近它。你是这里的求助者。做一些吐槽。这没关系。一点点不会伤害到你，也会让接收方知道你确实很在乎他们的时间，也就是说，"我知道你真的很忙，但我似乎想不出如何与你的API整合。"。当你有时间的时候，你能不能告诉我，我缺少什么？” 这表明，你错了而不是他们。这一点很重要，

3. 列举出你自己所采取的步骤。"API文档说要传入一个代表用户ID的字符串。我试过传入user.id属性和用户名，都没有成功。" 这说明你至少尝试了一些东西，总的来说，你已经开始 “了解 "这个产品了。

问问题时要有更好的判断力*

这句话，在我看来，听起来像是你向别人 "发牢骚"，对方没有好气的说："你的蹩脚问题让大家都很烦，你的问题是什么？不要再问了！” 换句话说，我认为这不是问题。一旦你改正了你的其他问题，这个问题就会消失。

坏的文档*

咳咳！这又是一个人身侮辱。这是另一种个人侮辱。永远不要这样说。永远不要！你又一次说他们的代码质量太差，以至于你无法理解。他们的回应总是会说："别人都是这样，所以你一定是白痴，不是我！"

还有，这有点 “欢迎来到现实世界 "的意思。在现实世界中，客户支付的是工作中的应用程序，而不是代码或文档（大多数时候），所以文档随着时间的推移而退化是非常常见的。

我想说的是，无论文档有多糟糕，我都会说。不管文档有多烂，有了源码就在你面前，你就不需要它了。这是一个真正的好东西，不要误会我的意思，但是没有它你也可以工作。

迟到*

很明显，不要迟到。这是一个不需要考虑的问题。事实上，在你现在的情况下，提前30分钟! 别找借口。你这样做会毁了你找到下一份工作的希望。如果我给人事部打电话问你的出勤情况，他们说 "他经常迟到 "或者 "他因为迟到被记过"，那就是一面红旗。我之所以提到这个，是因为无论你是留着这份工作还是换一份新的工作，这一点更会阻止你获得下一份工作。

质量低下的代码*

这很可能是真的。考虑到问题的问题，你很可能没有写出好的代码。你是新来的，这也是意料之中的。我发现大学里根本就没有教过什么东西。现实世界的编码。我从来没有从大学毕业就直接雇佣了一个人，并得到了一个 "优秀的开发者"。这并不意味着他们没有成为优秀的开发者。他们只是一开始并不是那样的。写出好的代码意味着要跟上最新的趋势和技术。你在不断地学习。当你停止的那一刻，就是你开始烂的那一刻。

总结

这篇帖子已经很粗糙了，但我想清楚地表明，一个公司的立场可能是什么。很多时候，他们（公司）会用很多 "经理人的话 "来包装自己的言论，可能会让人难以理解。我试图在这个帖子中尽可能地减少经理人的讲话，但这意味着它有点粗糙。

你修复你失败的职业生涯最重要的步骤：

1. 早点去上班! (我怎么强调都不为过)

2. 带着你已经在侮辱对方的心态去问问题

3. 展现你的工作。问问题的时候要明确说明你已经做了什么

4. 多花点时间自学。重要的是要花更多的时间去研究事情，而不是去问事情。说实话，3-4天的时间自己找一些东西，会更受人尊重，然后一个30秒的问题。

我想站在管理的角度去试探一下，

一个PIP是一个综合的东西

很有可能是你的管理层所强调的绩效提升的东西的集合，都是一起做的。我猜想，如果你是那个问了很多很多问题的人，但是来的早，来的晚，写代码的时候做的好，团队会把问的问题当成是个人的怪癖，或者说你特别彻底。

但当团队在回答了超过平时的问题后，需要帮助查找和修复更多的bug，而他们看到你工作时间少了，或者没有通知就迟到，团队和经理就会觉得你的贡献没有达到应有的水平，没有投入额外的时间来凑热闹。问问题很可能是针对其他问题提出来的，因为如果你试图通过多问一些问题来修复代码质量，团队就会觉得难以为继。

每一个小时都是重要的

一个刚毕业的大学生是团队时间的投资。任何一个告诉你不同的经理，要么是没有雇佣过新的大学毕业生，要么是在撒谎，要么是在为他/她工作的团队领导非常出色。任何新员工都是一些投资，但大学毕业生需要更多的时间。通常情况下，这样做是值得的，但是要注意，大学毕业生确实比更多的问题。当每个人都达到了一定的速度，了解代码，并且不问很多问题的时候，一个开发者团队会在一个星期内完成更多的工作。而且，一个团队在这种胶合状态下，能够很快地提出和回答问题，这也加快了工作效率。而且每次开发人员停止写代码，开始回答问题的时候，都会有一个上下文切换。因此，高度中断驱动的问题回答比坐下来回答一个小时的问题更容易成为生产力的杀手。

我可以肯定的说，任何上下文切换都要花费1个小时，所以即使你有一个5分钟的问题，当有人停下来回答你的问题时，你已经花费了团队1个小时。这意味着，花1个小时的时间而没有得到，然后请求帮助实际上比花2-4个小时的时间要多。

不存在 “只需要对方花5分钟就能为我节省1个小时 "的说法。考虑到每次中断至少要花1小时的度量，对方最好是为你节省2-4个小时。

好的提问技巧：

–了解并根据紧急程度提问–如果你绝对要在1小时内解决一个问题，那么中断几乎所有能帮助你的人都是个好主意。如果给你一个3周的最后期限，那么少打断，多解决自己的问题是一个比较好的主意。这就意味着，在紧急情况下，人们往往会问很多本来要自己研究的问题。因为绝对要尽快得到答案。

—-使用问题论坛有明确的目的性，或者从现有的问题/答案中直觉出目的性。比如说Stack Exchanges，有一套相当广泛的基础规则，这些规则都是相当完善的，而且特别期望用户在提问之前搜索以前的答案。一个不同的论坛可能会期望重复提问，但只在一个非常狭窄的领域内。 - 研究你的问题。期待写出一个好的问题，可能需要和给出答案一样多的时间–在很多情况下，你要描述(有声有色地!)把你带到无法回答问题的步骤。另外，你很可能会记录下问题的所有症状。 –锁定你的问题–在可能的情况下，弄清楚谁能真正回答问题，而不是问每个人。不是每一个问题都值得讨论。 –将一大堆问题汇总起来–特别是当你是新手的时候，花一天的时间来复习问题和代码。把你的问题汇总成一个灯泡状的列表，把题目汇总在一起。然后问一个导师或好友，在这些问题上可以去哪里寻求帮助。很有可能在第1小时中的大部分问题在第6小时前就会得到答案。在1-2小时来的问题，在8小时#8之前无法回答的问题，很可能会在你的列表中名列前茅，因为你知道在8小时内你是无法想通的。 —代码不是 "自记录"，但通过阅读可以学到一大堆信息。我学了很多没有文档的系统，就是拿着本子坐着，边走边画我的版本设计图，才学会了很多没有文档的系统。如果你没有读过上面几层，下面几层，你没有读过你所从事的领域，也没有读过你所使用的外部API的文档，那么你的研究还不够深入。 –当你想弄清楚一个答案时，如果你能 建议可能性，而不是要求答案。"这样做会不会是正确的方法？"总比 "我该怎么做 "好。- 即使答案是 "你的做法完全错了”—-你还可以问 “为什么我的方法会错？"，以及更玄乎的 "我怎么会反复学习如何正确地做？"？这就是 "授人以鱼 "的方法—-学会钓鱼，不要问那些只能让你钓到1条鱼的问题。 —-避免问那些仅仅是礼貌性的不同意的问题。在 "我的方法可行吗？"与 "我不明白（即同意）你为什么要用你的方法？"之间有一条线。这些都是很好的对话，但最好是在你了解了别人之后再进行非正式的对话。新人有权利问很多 "where”&“who "的问题（docs在哪里？但 "为什么 "如 "我们为什么要这样构建？"、"我们为什么不多记录代码？"、"为什么这不是重点？” - 这些问题都是合理的，但在你对工作和业务有了更多的经验之前，它们并不是最必要的问题。这些问题对于你和你的老板进行1对1的谈话是非常好的，因为你没有其他紧急的问题，但是如果 “为什么 "的问题把你的工作重点放在哪里，是谁和怎么做的问题上，那么你就没有把注意力放在工作上。

问题*

你所描述的是大多数应届毕业生面临的问题。大多数大学只教给你基础知识或概念，而在实际工作中，你需要的东西更多。

大多数公司在招聘应届毕业生时，都有培训计划，如果你按照计划去做，一年左右就能有信心做好你的工作。但有些人确实会有好奇心，如果你给他们一个简单的任务，让他们去修一个系统中的一个小部件，他们会在掌握了整个系统之后才会明白，而我相信你就是其中之一…..

我想你问问题是因为，

• 你觉得你在完成一个任务时，会花更多的时间，因为你不懂系统中的某些部分。 现在）

• 开始花更多的时间了解系统（不只是8个小时）

• 用SO或其他相关网站来代替（做完你的研究部分后）

• 请你的公司好好培训你@你需要帮助的领域。

我按照上面的方法，现在在同一家公司工作了5年，我可以说我知道的比这里的任何人都多。

这里已经有很多答案了，但我想针对你的问题的几个具体部分来回答。

虽然也有人骂我，说我自己没有花足够的时间去想办法，然后再找别人帮忙。但事实并非如此，而且**我的经理现在也不知道从我遇到问题到请人帮忙的时间有多长。我基本上都是尽量自己想办法解决问题，至少有一个小时的时间。在问一个知道答案的同事之前，花在问题上的合理时间是多少呢？

强调的是我的。

首先，是的，一个小时的时间可能太短了。我说可能吧………..这真的要看问题的严重性。而且有一个时间限制是好的，但你应该更多的依赖指标，说明你已经到了一堵墙，而不仅仅是时间限制。但重要的是，当你准备提出问题的时候，接受你的问题的人应该能够通过你提出的问题的种类，就能看出你对问题的研究程度。

而这时，我们就到了引文中加粗的部分。你在技术上是正确的。

但根据你问的是什么问题，你提供了什么信息，问题的上下文，以及通过简单的谷歌搜索，我可以很容易地找到答案，我可以很好地估计出你在解决问题上花费了多少精力。如果你花了10分钟或者10个月的时间来解决这个问题，这并不重要。你应该已经研究过那个页面了，它不是解决了你的问题，就是你在告诉我这个页面，为什么它没有解决你的问题。

但是，另外，你问的是什么问题？你是在问直接的解决方案吗？还是你在要求在正确的方向上给你一点提示？有时候，你所面临的墙是你完全不知道一些库或代码库中的一些现有的部分会让你的问题得到简单的解决。

我想说，你已经通过学校的硬碰硬了解了这家公司的要求。在这个地方提问是不允许的。

我觉得你的主要问题是可见性。偷偷懒地问问题是很多人都能看出来的事情；即使他们不觉得有必要回答，也可能会影响他们对你的判断。同时，如果你花一天的时间在你的办公桌上搞清楚一个功能，没有人看到那轮子转的情况。你看起来是在做错事，而不是在你的办公桌上敲击键盘，这看起来像工作。当然，也许在周评、月评或年评中，你的工作效率会反映出你的工作效率很差。但你的懒惰问题每天都会被看到好几次，而你的实际生产力的衡量频率却少得多。

我也曾在你这样的岗位上。我被雇来修复一个适当的CMS的bug，而首席（读：唯一的）开发人员却在疯狂的为客户添加功能。我们的工作积压得很厉害。代码库没有版本控制，每一方都有自己的定制版本。

我想，与其花半天，一整天，甚至几天的时间去逆向工程一个功能，还不如花10分钟，20分钟，30分钟的时间和领导聊天，让他给我解释一下，而不是花半天，一整天，甚至几天的时间去找一个功能，找出1. 2.它应该怎么做，2.它应该如何工作，3.如何修复这个bug。

结果，当我的老板（两个合伙人之一）发现这件事的时候，他认为这对我来说很糟糕，因为我无法独自解决代码故障，而且我占用了我们的主开发人员的宝贵时间。(首席开发人员似乎很喜欢谈论他的代码库是如何工作的–无论如何，他并没有像他告诉我的那样，向我的老板抱怨）。) 所以，我不再问问题了，我的工作效率大概降到了原来的10%。大概一个月后，我就被放走了。

总之，这家公司是在用一种可怜的方式告诉你，他们不重视这种时间效率和文件的副作用。所以不要做，

花一天时间想办法。花几天时间—-花一个星期! 谁在乎呢？不是这家公司。不管你做什么，不要问问题， 因为他们才会关心这个问题。不管是管理层，还是你的同事们的抱怨，都不重要。公司已经告诉你，它在培养什么样的文化了。

所以，如果你考虑到你的情况，有了迟到和低质量的代码，下降的生产力可能加起来就是太多了。与其等待斧头落下，不如找一个更适合你和你的风格的地方。一个也许有一些代码注释和文档的地方，作为一个开始。

那么我的故事是如何结束的呢？经过一段时间的失业，我找到了一份新工作。除了代码库好了很多（我们使用的是行业标准的CMS，我们在版本控制上，我们有dev、staging和prod环境等等），我的同行们都很优秀，而且我的公司鼓励学习。我们有一个wiki，我们在这里分享我们的信息，避免重蹈覆辙。我们整天在slack上聊天，谈论工作，提出问题，集思广益，分享新闻、信息和发现。我们开始做项目来改进我们的流程，比如敏捷、流浪者、实施持续集成等。我们互相教导，互相学习。我们的行为像同事和合作者，而不是竞争对手。我们对新员工和承包商都有入职指导，如果没有这种文化，我们就不可能有这样的入职指导。这是一件好事，因为在我在这里的这段时间里，我们已经从两个人（包括我在内）发展到了八个人，而且在繁忙的时候，我们也有了承包商。这段时间我在这里学到的东西比我职业生涯中的任何一个时期都要多，特别是在我不擅长的科目上。这很好，我在这里已经4年半了，除了学习一门新的技术外，没有什么理由离开。我的新地方的文化真的是以学习、理解和实施最佳实践为导向，这将导致生产力的提高。这是一个双赢。

说真的，还有更好的工作场所。这个地方不适合你，你也不适合他们。

如果你问一些与工作无关的问题，那么这可能会被认为是闲聊，这在你的老板眼里是一件坏事，所以不要再问了。然而，一个更有帮助的答案是，在你提出这个问题之前，问他们是否有时间回答问题。

在我看来，听起来你的老板有点笨，或者他只是想把你赶走，不管出于什么原因。他们会失败的，因为他们不做记录，当他们的主要开发人员离开后，他们的主要开发人员就会有灾难。

我如何做一些我需要学习的工作，但已经告诉我的事情，我应该怎么做。

1. 有趣的问题和小题大做

所以……

你想问多少个#1就问多少个#1就问多少个。他们可能会觉得你很烦人，但这是个好/聪明的烦人。

如果你问的是#2，那么他们会认为你的理解能力有问题。或者你就是喜欢问问题，但不听话。这在一定程度上是可以忍受的，而且很快就会变老。

根据你的职位和你给团队带来的奇特的东西，3号可能是可以的–你对某一领域很了解，你很抠门，什么的。然而，你最好不要在问了#3之后再问#2s。

毫无疑问，#4s是不好的。问一些这样的问题，你可以逃避，但作为一个新员工就不行了。同事们会希望你在考虑#4之前，先问#1（和一些#2）。如果你问了很多#4的问题，他们会认为你是个不折不扣的人。仅仅问几个#5s就能让你对任何一个团队成员产生抵触。这意味着你没有得到它，而且很可能没有能力得到它。

嗯…… #6S是因人而异的。很多人可以问成吨的#6s，如果他们是娱乐性的或有趣的。在另一边，如果你不是#6s可以是非常糟糕的，特别是如果你问#2-5s。

如果你想，如果你对自己为什么他们不能只是对我好，并帮助我，如果我有问题，问#2-5s所有的时间。因为他们可以雇佣其他人知道更多，不问愚蠢的问题。如果我是你，我会开始多注意，甚至可能会随身携带一个记事本，当有人回答你的问题时，你要确保你百分之百的确定你得到它或要求当场澄清。

这个回答是关于如何接受反馈的问题（其他的回答已经很好地涵盖了如何提问的问题）

虽然我也被骂过，因为我在解决一个不熟悉的问题时，因为 “走错了路 "而没有问熟悉的人，而被骂了。当我问起这个矛盾时，经理和HR说，我只是需要用更好的判断力来判断什么时候问问题。没想到问问题也会有这么大的危险性，

那是自己的不良反应。想象一下你自己站在他们的位置上想一想。你知道有些员工的表现很差，而你正在告诉他们需要改进的地方。

当收到反馈，尤其是负面的反馈时，你应该首先倾听，然后寻求理解（必要时提出澄清的问题），然后才会作出回应。要么你的老板错了，要么你错了（或者你们两个人都错了）。你应该考虑到可能是你，因为你的老板不太可能完全错了，而你是完全对的–即使你是，你也只能通过让你的老板知道他错在哪里，才能让他相信他是错的，这也需要听他的意见。

你也可以向他请教如何做得更好，比如，在听到你问了太多和太少的问题后，你可能会问：

所以我既问了不必要的问题，又没问必要的问题。我应该如何判断哪些问题是必要的问题？也就是说，我应该多问什么样的问题，少问什么样的问题？

下面的实事求是的讨论，很可能就能看出你需要改进的地方。

这种情况是否正常？新人到了公司就不应该有好奇心，或者问一些与工作没有直接关系的问题吗？

在多大程度上，问问题是人们所期望的，或者说是人们所希望的，在不同的工作场所，问问题的程度是不同的。你可能希望能适应你的工作场所的文化，你可以通过观察你的同事来发现这一点，记录下人们对你的行为的反应（他们是对你的问题感到恼火，还是对你的问题感到高兴？

我想，如果你像我这样的年轻人，你的心态是节省时间，找到答案，然后再去解决下一个问题。然而，我发现对于老一辈的人来说，这并不是他们所关心的问题，也不是优先考虑的问题。所以，是的，花一个小时来解决一个问题对年长的人来说太短了，但是对你来说可能会觉得太长了。我建议你观察一下代沟，即使你不同意，也要跟着去做。

至于因为问问题而惹上麻烦，我尽量用 “我想看看应该怎么做，或者按照公司的标准去做 "的解释。我再次注意到，在老一辈的人中，不知为什么，这让人很烦躁。我觉得老一辈的人往往会认为我自己解决了这个问题，我没有得到任何帮助，所以他们不太愿意帮忙。他们也会觉得自己被打断了。就像上面有人提到的那样，试着找合适的时机寻求帮助，同时抚摸自我，即："我听说你是这个问题要找的人……….” “有人说你是专家……….. "希望这将使他们忽略了中断，他们将更愿意帮助，因为你给了他们一些东西来证明。最后一句话要小心，因为我相信在某些情况下可能会起反作用。

我觉得很难准确定义，但我曾与一些初级开发人员共事过，他们中的一些人提出的问题，有的人回答起来很满意，有的人却没有。回答你的问题会分散你的同事们的注意力，这也没关系，如果_，从长远来看，会有好的结果，公司也会受益。这意味着你需要问正确的人，问正确的问题，并达到一个让你获得理解的地方，让你取得重大进展。如果你有这方面的诀窍，人们会觉得帮助你的时间是值得的，你是一个有价值的合作者。如果不是这样，他们很可能会觉得你很烦人。

显然，如果有很多你不知道的东西，那就会让你处于一个微妙的境地，但态度和能力会带来很大的不同。没有人期望你什么都知道，但他们确实关心你如何处理。这里的其他人已经讲到了你可以做的事情，当你确实有一个资深的dev鸽派的时候，你可以做的事情是最有价值的，所以我不会重复他们的建议；我只是想给你的同事们一些启示，让他们了解导致这种情况的原因，这样你就可以理解和避免将来的情况。

这几乎是对你的雇主的建议，但也许你可以让它为你工作。

当你入职时，他们给你指派了导师吗？给新员工一个指定的导师，让他们有问题可以去找他们的导师是个好主意。:-)

导师也会知道正确的人和正确的地方，比如文档等。例如，有些项目可能有Google Doc文档，另一个项目将其放在内部文件服务器上，第三个项目将其提交到源码库内。而其他项目根本没有任何文档。

另一个提示是，在开始一个新项目的工作时，要要求参观一下。有经验的人和你和一个有经验的人在一起的四个小时的时间，可以让你快速上手，而不需要这四个小时的时间，因为中断的时间会蔓延到几个月。

有一点要记住：代码就像语法一样。人们可能知道自己的代码很烂，但不喜欢被人说出来。比如说，如果我指出你反复写错了 “判断"，你可能会很生气，因为我并没有给你增加什么建设性的东西。好吧，反正我就是这么做了:)

但是，再加上很多老练的程序员确实倾向于采取神态。你想问的是基于逻辑的真诚问题，可能会对他们造成很大的威胁。我曾与无数的例子（我自己也可能是其中之一）合作过，他们一直在维护同样的蹩脚的代码，15年来都没有相关的代码。他们知道现在有更好的方法，但他们没有兴趣也没有动力去学习新的东西，所以你作为下一代的存在对他们来说就是一种威胁。当他们装模作样的时候，你只需对自己一笑置之，记住你才是真正有能力的人–你还有很多年的时间去研究未来的技术，而你的职业生涯的最终方向仍然掌握在你的手中。

我同意其他人提到的观点，对于有志向的开发者来说，这听起来并不是一个好的孵化器。然而，这种情况很常见。这需要时间和经验来确定你的利基，找到一个适合你的雇主，并确定什么对你来说最重要。所以，在那里支付你的会费，接受你的肿块，规划你的职业生涯，并在你投入了几年的扎实工作之后再出来。现在，你只需要接受这些建议，不要担心PIP，不要担心PIP的问题，并不断提醒自己，你现在的处境只是一种手段。你的上司希望你能像在Wendy's工作一样按时上下班。即使对于没有经验的新开发者来说，情况也不是这样的，所以在其他地方可能会有更光明的未来。

我试着跟他们说了我在这里跟你们说过的事情。他们就因为我和他们 “咬牙切齿地争论，不听他们的建议而生气了。我说我只是想说说我的观点………..他们更恼火了。

我想我可以解释一下他们恼火的原因：他们根本不想要反馈。你的经理并没有邀请你发表意见，他只是用这个 "需要改进 "的计划说，你有一个不好的行为，需要改正，"为了你自己的利益"。是给你发工资的人，也是可以开除你的人，只有他们。当你批评他们的决定时，他们就会恼羞成怒，因为他们付钱给你是为了听从他们的命令，而不是质疑他们的命令。他们不是 "公正的法官"，他们是给你钱的人，他们才是 "公正的法官"。而且，如果你在批评他们的时候，他们给你一个严肃而正式的警告 "要不改，要不就滚蛋"（他们所谓的 "改进意见"），这可能会让他们认为你没有救赎能力。