软件开发是一项收集信息、处理信息的工作，当信息存在缺失，请务必敢于提问，哪怕问题看似“愚蠢”。而现实中很多人羞于提问，担心会暴露自己的无知，影响大家对自己的印象，其实不然。
为什么要敢于提问
以技术分享为例： 对新人来说，分享者心里预留了提问空间，因为他深知自己的经验不是一蹴而就，是通过踩坑积累，尽管他很想在短时间内把信息同步出去，因受“知识的诅咒”影响，无法切身的站在新人角度给予讲解，需要新人提问来弥补空缺，所以提问不需要有思想包袱。
其次，分享者需要通过提问来确认来感受自己是否讲明白，亦或通过收到的问题“质量”，来测量倾听者的理解程度，如果分享后，没人提问，可能有两种情况：要么讲的很好，大家都听明白了，以至于没有要问的问题；要么效果很差，大家没有理解，无法有效提出问题，根据历史经验，沉默的原因往往是因为后者——大家没听明白。
提问对自己的收益最大，当信息缺失对自己接下来的工作构成阻塞，对疑惑闭口不提，只能造成更大的障碍，产生项目风险。而真诚的提出自己的疑惑反而给人一种踏实靠谱的印象，如果在众人沉默，提出了大家都疑惑的问题，也会增进团队成员对自己的信任。
是不是越勇于提问越好呢？——当然不是。
这里有两个矛盾之处： 相比查资料、看源码，程序员更喜欢张口就问 程序员虽然喜欢条理清晰的文档，而又懒得写文档
我们很难判断自己的信息缺失是因为“懒”不看文档，还是对方文档写的太差，缺失信息。
通常情况下双方都有问题：分享者懒得“写好文档”，倾听者又想“躺着听明白”，都不想往前多迈一步，让信息传递增加损耗，导致一方问多了可能会觉得烦，一方担心问题低级不敢提问。
作为新人应该怎么做？
新人是信息索取者，自然是被动的，现实中很难要求信息一应俱全后再开始工作，理应自己的主动收集，主动记录，除了甩掉心理包袱之外，还需要一点技巧。
先全局再细化
一个好的方式，应该是提前预习，先建立全局认识，从背景到输入输出，汇总手边所有信息，以不求甚解的方式，理清整个脉络。可以在纸上画出基本架构图或流程图，对于流程中没衔接起来的，或细节缺失的部分留作记录，形成问题清单。
处理问题清单
拿提前梳理好的问题清单，主动发起沟通，并在沟通过程中及时记录，如果一天中所接受的信息已经够多了，就停下来，把当天记录的内容重新复习一下，甚至可以留作发起第二次沟通，开场白可以是：上次同步完信息，我回去摸索了一下后，发现还有一些细节需要确认，分别是 A、B、C...
通过一份新的问题清单，大家能看到你的努力，一个正常的职场氛围中，大家更乐意帮助努力的人，而不是试图躺着让别人讲明白的人。
注意：凡事有个度，作为新人，要保证同一问题，不要做二次同步，作为分享者，也要保证关键信息同步到位，不能幻想倾听者能聪明到可以自行脑补推理的程度，毕竟信息每转述一次会有 20% - 40% 的损耗，在信息同步完成后，可以让倾听者口述一遍，减少理解偏差。
不要依赖短期记忆
我们短期记忆有限，以至于一个电话号码都要拆成 123-4567-8989 的形式才能有效传达，11 位的手机号码都已经很长了，日常生活中，我们接收 6 位的短信验证码，都需要快速默念几遍，在心里形成顺口溜，赶紧填入，可见我们的短期记忆的存储空间严重不足。
而在信息同步的时候，有个最大的误区，我们会把短期的“记住了”当成“我会了”，一项繁杂的项目交接，分享者会一口气把所有能想到的信息传授给你，你用短期记忆记住了这些东西，并信心慢慢的表示明白了，这也给分享者留下了好印象，虽然你有一些细节没能理解，但为了继续保持好印象，也没有开口提问。刚开始你还能记住这些内容，但随着时间的流逝，哪怕只隔了一天，短期记忆的弊端立马出现，让人感觉昨天还听明白的东西突然苍白了起来，这时候又有更大的心理负担，不敢再次提问，煎熬就这样开始了。
总结
想要快速成长，请先抛掉心理包袱，敢于提出“愚蠢”问题，再次之前最好先有准备，在提问之后，请务必记录，不要依赖短期记忆。
