工作中会给到新人的适应期不会太长，也并不是所有团队都会给新人犯错的机会。从校园刚出来的大家，多多少少都会不适应这样的节奏。运气好的，可以遇到好的导师、团队，在大家的帮助和自身的努力之下，快速适应而且开始施展拳脚。运气差的，可能会被各种甩锅冲晕了头，在职场 PUA 中开始怀疑自我，最后被这个行业排斥和抛弃。

当你开始体会到职场不再是象牙塔的时候，或许你在经历一些不好的事情。你会困惑，会苦恼，会无可奈何又那么无力。但是，等待我们的只有束手就擒吗？

6.1.1 　找到自身的定位

当我们抱着很大的期待开始参加工作，最容易遇到的一个问题就是：我不喜欢现在手上的工作，我想做点有意思的。

其实每个人都是这么想的，但现实是这些没人想接的工作，依然需要有人去做。作为一个刚来的新人，挑活干很容易给人留下眼高手低的印象，因为大多数团队对于应届生的要求是聪明好学、听话负责。我们刚加入一个团队，彼此之间还会有一个相互考核的磨合期，在这个过程中大家会下意识地相互打标签，而一旦标签被贴上了，需要耗费很长的时间、很多的精力才能改变大家对你的认知。

做好需要做的事情

因此，作为新人刚来到一个团队，首要的是主动积极地去完成被安排的任务、以及需要有人去做的任务。例如可以通过解决其他人不愿意做的事情，来留下一个比较好的印象。这并不意味着不能去做自己喜欢做的事情，我们通过基础性的任务证明了自己的能力之后，就可以慢慢地接一些更有挑战性的任务。

需要注意的是，即使很好地完成了团队给的任务，也不意味着我们马上就可以做自己喜欢做的事情。并不是所有团队都会是理想的样子，这样工作内容倾向打杂的情况也可能会持续一两年甚至更多。当这种情况持续过久、已经脱离预期，则可以考虑主动找上级或同事讨论自身的困境。如果团队氛围并不开放、也不支持这样的讨论，那么可以考虑其他方式（例如选择离开）来解决。不要让自己陷入这样的困境时间太久，除非你可以在工作外有更好的成长方式，否则这会对自身的发展多少有些影响。

少抱怨，多做事

程序员的日常，除了跟产品讨论需求设计、跟项目管理争取开发时间、跟测试说明某个问题并不是缺陷而是设计如此之外，剩下的开发时间并不是特别多。而在这仅有的开发时间中，我们还有很大一部分是去翻阅其他人写的代码、定位其中的问题，真正写代码的时间不会很多。

从头开始参与一个项目的机会比较少，大多数情况下我们都在接手“祖传”代码。这些祖传代码，常常因为当年着急上线、赶时间而被粗糙地设计（甚至没有设计），通常会有特别多的历史包袱。在这样的历史包袱基础上，一个原本简单的问题可以变得极其复杂，我们无法简洁而优雅地实现某个功能。一般来说，有洁癖的程序员会选择重构，但重构这种性价比不高的工作往往不会被重视，甚至在一个对技术不了解或是不重视的上级眼中，这就是在浪费资源，很多时候这种工作不会被认可。

除了历史代码，工作中还有很多的规范、流程，它们可能出于安全、方便管理等考虑，以牺牲一定程度上的灵活自由度来换取其它结果。即使目标是为了最终提升整体流程效率，实施过程中必定也有不少的调整、返工等情况，导致开发体验下降。

一般来说，遇到这些问题我们总忍不住吐槽几句，如果一直憋在心里只会积累更多的不满，这种吐槽也算是发泄的一种方式。但如果我们持续地吐槽一些问题却不解决它，不管是对自身还是对周边的人，会影响大家的积极性、形成消极对待事情的氛围，这其实变成了无意识的抱怨。如果一个问题出现让你不舒服，那么尝试去解决它。如果你没有办法解决，那么就尝试去接受它，抱怨并不能解决任何问题，相反它会带来更多的问题。遇到问题的时候，多调整自己的态度，不要抱怨。

但是，避免抱怨并不意味着不能提出问题。很多时候大家会说提出问题的时候需要提供解决方案，如果可以这么做当然最好，但实际上很多事情并不是我们自己有足够能力和资源去解决的。相比之下，如果大家都看到了问题，却没有人提出来的话，问题甚至永远都不会被发现、更不用说被解决。

6.1.2 　多思考，多询问，多总结

如果想要在短时间内获得快速的成长，最实用的方式就是“多想、多问、多记”。这是一个简单但特别有用的技巧，我们在每做一件事的时候，都可以按照以下步骤来执行：

1. What/Why/How。思考要做的是什么事情、目的是什么、要怎么做可以达到预期效果。
2. 任务过程中多进行反复思考，包括最初的想法是否与实际情况相符合，以及相应的原因是什么（也可以与其他人进行讨论、寻求帮助等）。
3. 一个任务结束了，可以将最初的预期、过程中遇到的问题以及如何解决、最终的结果等进行总结，同时可以拓展思考以后遇到类似的任务应该要怎么做等。

我该怎么做

很多时候，我们做一件事就只是做完了一件事，并没有从中收获更多，甚至连为什么要做这件事、为什么要用这种方式去做都不清楚，那么我们对事情的把控和理解能力永远不会获得更多提升。三分做、七分想，使用这种方式去做事情，可能刚开始的时候做事效率会有所影响，但越到后面做事会越来越顺手、也能避开很多可预见的问题。

做每件事的过程中，可以保持阶段性地对自己进行提问：我可以怎么做、我该怎么做。大多数人在面对繁重的任务时，容易习惯性、反射性地进行任务拆解、排期，一个任务完成就紧接着开始下一个。事实上，越是在时间紧急的情况下，越是要频繁地进行思考，询问自己有没有更好的方法可以打破现有的困境，来提升效率、改善现状，只有通过这种方式，我们才有机会进行逆袭，而不是被这些任务淹没。

提问的艺术

除了自身的思考以外，我们也常常需要对他人寻求帮助。如何提出问题是一件讲究技巧的事情，提问的方式恰当除了可以得到想要的答案、还可以拉近彼此间的距离、给人留下一个沟通舒畅的印象。相反，如果提问的方式不合适，我们没法获得预期答案的同时，甚至会让人产生觉得你很烦、表达能力欠缺等问题。

那么，怎样算一个比较好的提问呢？

(1) 描述清楚问题背景。

我遇到过很多人在寻求帮助的时候，一上来就会直接抛问题。举个例子，某一天小明向我丢了个代码截图说：“你这里为什么要这么写”。此时我的内心就会有几个疑问：

是出了什么问题吗
没有出问题的话，小明到底想干嘛
？？？
关他什么事啊

其实，小明最近遇到某个功能实现，得知我也做过相似的功能，于是参考了我的代码，发现有个地方存在一些特殊的逻辑处理，觉得很奇怪却一直没想明白，希望找我问清楚避免踩坑。虽然我本身是一个很热爱讨论的人，但是这样的提问方式却有种质疑的味道，容易让人反感。最坏的结果是我选择敷衍了事，小明也没法问到他想知道的东西。

这里其实可以通过增加描述问题的背景，来把前因后果解释清楚。例如，小明可以这样表述：“你好，我最近在做一个 XX 项目，里面有个功能和你的 XX 项目很像。我参考了你的代码，发现这里有个地方逻辑比较特别，有点想不明白为什么要这样实现，想找你咨询一下”。

(2) 多站在对方的角度说明。

很多时候，我们在讨论问题的时候，容易一着急就脱口而出“我”的想法。例如这样的表达：“我的意思是这里不需要这么做”。这样的讨论方式，需要对方具备较好的角色转换能力。如果双方都是通过这种方式来交流，那么我们很可能需要花较多的时间讨论，甚至有可能会因为觉得对方过于强硬而闹得不愉快。

我们可以调整下表达方式，通过站在对方的角度进行描述，可以让对方更容易听进去。例如同样的场景，我们可以说：

• “我理解你的意思是想要 XXXX 这样做，我的理解有没有问题呢？”
• “你想要这么做的原因是 XXXX，对吗？”
• “我觉得我们可以通过 XXXX 方式来解决这些问题，效果会更好，你觉得呢？”

通过一步步地引导，让对方知道，他想要表达的内容你的确接收到了。在这样的基础上再进行讨论，可以降低对方的排斥性，更快地找到双方的共同点和差异点，一起分析和找到更好的解决方案。通过这种方式，也可以让你自己确认是否可能错误理解了对方的想法，避免因为双方讨论的内容不在一个点上导致的时间和精力浪费。

(3) 让对方快速理解问题所在。

我们的日常工作中，也常常会遇到这样的讨论：

小明: 在吗？
我: ？
小明: 你写过 XXX 吗？
我: 写过，怎么了
小明: 你遇到过 XXXX 问题吗？
我: 没有
小明: 那你有想过 XXXX 这个问题吗？
我: （不耐烦）没有
小明: 那你有用过 XXXX 吗？
我：（这人到底想干嘛啊...）

这样的场景下，被询问的人有种犯人受审的感觉。如果这种低效又容易让人困惑的对话方式一直持续下去，那么被询问的一方不耐烦的概率是极高的，甚至以后看到这个人的未读消息都不想点开。

我们可以通过结构化地梳理想要表达的内容的方式，让对方可以快速地知道我们希望他们做些什么。例如，可以通过分点列出自己的疑问：

小明: 你好，我这边在调研 XXX 技术方案，想要在 XX 项目上使用。想知道你这边有没有写过 XXX，想找你咨询几个问题：

1. 写 XXX 的时候，你有遇到过 XXXX 问题吗？
2. 对于 XXXX 这个问题，你有没有什么比较好的建议或者想法呢？
3. 针对 XXXX 这个问题，我觉得可以使用 XXXX，请问你有相关的经验或者建议吗？

通过一次性把想要询问的内容贴出来，对方可以花最少的时间、以最快的方式来理解你的状况和问题所在，并通过这些整理好的问题进行一一解答，还可能在回答过程中想到其它的点，给到符合你预期的答案。

好记性不如烂笔头

我们的工作和生活里，会遇到了很多的问题，最后解决了。但很多事情并不是解决了就等于结束了，我们会经常反复地遇到同一个问题，然后需要努力地回想——当初这个问题最后到底是如何解决的，尝试想起来当时的解决步骤、搜索关键词等。

工作中遇到的问题特别多，想要每一次都印象深刻地记在脑海里显然是不可行的。俗话说，好记性不如烂笔头，避免一个问题反复花费时间去定位解决的最好方式，就是记下来。习惯性地养成每次将思考、讨论、分享的内容写下来，可以解决很多问题。

(1) 将某个问题的解决过程、解决办法记录下来。

对于同一个问题多次反复出现、对我们造成不必要困扰的，当我们将它们通过文章、文档等各种形式记录下来，下一次遇到的时候可以直接找出来。我个人特别喜欢将遇到的问题整理成文章，放在自己的博客上，这种方式的好处在于当你需要的时候，可以直接通过关键字搜索找到当初的文章。

(2) 将讨论结果写下来，并作二次确认。

每次与其他人讨论事情，不管有没有结论，最好都通过聊天记录或邮件的方式保留下来。这样做的一个好处是，可以避免未来可预见的一些争执，因为每个人的记忆其实会结合自身的想法进行改造的。

举个例子，张三和李四讨论 XX 技术方案的设计，张三表示可以通过 A 方案来进行，李四却觉得 B 方案更好。于是张三和李四来回进行了十几个回合的深入讨论，最终张三成功地说服了李四使用 A 方案。接下来，张三就按照 A 方案进行开发，但最后上线的时候，李四却说他自己当初明明是说 B 方案更好，责备张三自作主张。

如果没有留下相关的讨论结果证明，张三就会哑巴吃黄连——有苦说不出。那么，如果当初在和李四讨论完之后，张三再通过办公软件给对方发送二次确认，那么最后上线的时候，这个问题很可能就不会再出现，就算出现也可以把聊天记录丢出来解决：

张三: 李四你好，刚刚我们讨论了 XX 技术方案的设计，分别提出了 A 方案、B 方案，在讨论过程中因为 XXXX 等原因，我们最终决定使用 A 方案。辛苦有空确认下，确认好了我这边开始动工哈~

李四: 对的没问题，加油~

这样一个二次确认的小技巧，能解决工作中大多数的争执和困扰，大大提升工作效率和体验。我自己还会习惯在代码注释和提交的 Commit 信息中记录相关的一些讨论、决策、需求单地址等信息，这些信息也的确很多次在事后的争执中起到比较关键的作用。

(3) 思考和设计过程也要记录下来。

除了前面提到的，把一个问题的解决过程和解决办法记录下来，我们也可以把一些突发奇想的点和进行某个方案设计的思考、方案选型、对比过程都记录下来。

作为一个程序员，我们常常会习惯性地直接卷起袖子就开始写代码，这并不是一个很好的习惯。更好的方式是，我们先将大致的方案列出来、仔细研究是否有风险点、是否在某个模块有更好的实现方式。写代码环节其实是最简单的，思考要怎么将代码设计得健壮性、拓展性、可读性、维护性都更好，才是作为一个开发最好的挑战。

这些思考和设计过程，其实是我们开发经验中最珍贵的部分。如果可以每次都记录下来，我们可以将自身的所有工作经验都沉淀下来，形成一定的技术壁垒，这些是我们将来区别于体力好、能拼、学习速度快的年轻人的关键内容。

6.1.3 　如何提出自身的想法

那么，我们要用怎样的方式来表达出自己的一些想法，才不会被觉得眼高手低、或被认为只是在抱怨呢？

1. 找对人

如果我们有一个问题需要找人讨论，那么需要先思考：在这个问题中，我们想要得到怎样的答案？

如果我们想要解决一个问题，就需要找到能解决该问题的人。例如，张三负责的列表模块出问题了，如果你找负责文件模块的李四讨论这件事，不仅问题没得到解决，还可能耽误了最佳修复时间。甚至在李四看来，他并不能解决这个问题，但你却一直找他询问，对双方来说都在浪费时间，而看起来你也似乎只是在抱怨这件事、并没有打算去解决它。

如果我们需要一些帮助，就要找到可以确切能提供帮助的人。例如，负责列表模块的张三不想再做列表模块了，他想去做文件模块。但他没找上级表达自己的想法、也没有找李四协商是否可行，而是每天跟王五说好想换去做文件模块。这么做会存在三个问题：第一，王五并不能解决张三的问题；第二，李四、上级都不知道张三有这样的想法，信息差的持久化容易影响相互之间的合作；第三，张三自身问题没有得到解决，长时间的期望没有得到回应也容易心生不满，影响自己的工作状态。

找到能直接解决问题的人，是最有效的解决办法。而当我们不知道谁可以解决这个问题的时候，可以通过找其他人、让对方推荐相应负责人的方式，来一步步找到你需要的那个人。

2. 对事不对人

有些时候，我们需要对某个问题进行总结或者复盘。一个问题的出现总是有原因的，并且很多情况下都是人为导致的。因为这个原因，我们常常容易会习惯性地将某个问题与某个人挂钩，这可能会导致问题根源不能得到很好的解决，同时还可能造成团队成员间合作的不和谐。甚至有时候，我们的本意并不是追责某个人，但对方过于敏感也会导致同样的结果。

要记住，我们要解决的是某一类的问题。或许这个问题是由某个人导致的，但解决这个人并不意味着问题不会再次出现。例如，我们在一些管理运营系统上常常会出现误操作的情况，在这样的情况下，除了可能需要追究具体操作的人，更需要去反思系统是否可以通过加审核、高亮提示、多次确认等方式来降低误操作的可能性。

3. 考虑全局

很多时候，我们会因为个人的喜好而产生一些想法。例如想要调整工作方向，但不能直接表达出来是由于个人意愿想要调整工作内容。如果这样的调整与团队方向不匹配的话，会给团队带来困扰，在一些不大友好的团队中甚至容易被贴上缺乏大局观、挑活干的标签。

那么，我们可以先自行进行思考，可以通过怎样的调整方式，达到既符合自身的想法、也能给团队带来一些收益的效果。先列举出现状，再对比调整前后的优缺点，拿出足以说服团队的理由，再去跟团队协商是否可行。尊重是相互的，如果我们自身的确以全局的角度出发提出问题，那么团队也会给予我们同样的尊重。

这是一个很重要的技巧，关键在于我们要解决团队的问题，而不是给团队带来问题。这些问题里同样包括了自身的一些想法，因为我们每个人都属于这个团队，个人的问题同样是团队的问题，共赢是最理想的状态。

6.1.4 　不要害怕犯错

虽然前面有讲到，并不是每个团队都会给予大家犯错的机会。但是如果因为这样的原因过于害怕犯错，我们在工作中会束手束脚，轻则影响个人表现，严重的可能同样会被认为缺乏思考、面对挑战的积极性不足，无法担起重要业务等。

被打脸是常态

新人必不可免地会犯错，曾经说过的一些话也常常会发现不够准确。大多数新人都会因此觉得好丢人，被打脸的画面会在脑海中不停回放，无法释怀。

很多时候，缺乏经验的我们会很容易掉进各种各样的坑里。摔倒是家常便饭，夸下海口的事情也往往不会按照自己的想法发展。这是很正常的事情，即使是你的上级、领导、其他你觉得很厉害的同事们，也都曾经遇到过同样的事情。这些并不是需要觉得丢人的事情，实际上除了你自己，其他人并不会记得这些事情。

因此，不要因为害怕被打脸而将自己的想法藏到心里，不敢去尝试，不要因为害怕被责备而将事情隐瞒。要知道，如果你不去验证，永远都不知道这些想法是否正确。

最重要的是学到东西

工作时间越长，你越会发现脸皮厚真的很重要。除了不要害怕丢脸，更要懂得适当地向其他人寻求帮助。

人们大都好为人师。通过向对方询问问题的方式，不仅可以学到更多的东西，还可以拉近彼此间的距离。当然，我们在提出问题之前，最好先在搜索引擎里检索一遍，一些通过查找就可以得到答案的基础问题，就不要拿去打扰别人了。也并不是每个人都喜欢回答别人的疑问，在对方态度一般、显得不耐烦的时候，可以尽量简短地描述出自己的问题、告知对方是否紧急，并礼貌地表示感谢和打扰。

不管对方有没有帮忙解决问题，都要表示感谢。因为对方花费了时间来翻阅你的问题、并尝试进行解决或是解答，而这些事情本身就不是他们的职责所在。

避免重复犯同一个错

在大多数情况下，团队对新人犯错会有一定的包容。但如果同一类错误反复出现，那么大家对他的印象会大打折扣。我们不怕会做错事的伙伴，就害怕做错事还不懂得改正的。

当我们在某件事情中没有达到预期，可以通过主动询问其他人来找到自己的问题所在。一般来说，相对友好的同事会告诉你问题出现在哪，也有一些人会因为不想得罪人、不喜欢分享自己的想法等种种原因，选择了保持沉默。在这种情况下，通过表达出认真、端正、希望获得指导的态度，大多数人都不会拒绝，这样得到答案的可能性会更高一些。

如果知道了犯错的原因，可以进行分析和归类。例如，小明在某次发布过程中因为某个藏得比较深的 BUG 没有被及时发现，导致了现网事故。除了找到具体的 BUG 出现位置、处理解决、进行问题分析和复盘的同时，还可以思考可以通过怎样的方式来避免下一次再出现相似的问题，这些方式包括：

• 流程上更加严格地进行交叉 Code Review
• 新增对应的测试方式（单测、集成测试、人工测试用例），保证类似问题可在测试过程中被发现
• 制定更细致的发布流程，通过监控、反馈等方式及时发现问题，进行回滚或修复，尽可能降低对现网用户的影响
• 等等

问题的归纳和复盘是很重要的一个步骤，通过这种方式，我们可以用最少的犯错成本来发现更多的问题，并提出相应的解决措施。除了自身的思维可以得到拓展以外，还可以将这些总结经验分享给需要的人，促进相互间的交流、形成更多的探讨。