【职场生存术6】寻求帮助是一项高级技能,得慢慢学
上面的场景熟悉不,是不是经常遇见,要么是自己没调研就去提问,被人嫌弃,要么自己不会寻求帮助,结果耽误了时间。这两种情况都说明了一个问题:我们还不懂怎么正确地寻求帮助。
一、为啥不敢寻求帮助?
1,面子问题
这个很常见啊,"问这么简单的问题会不会显得我很菜?"当你把提问的文字写了三遍又删了三遍时,谁知道你心里不知道上演了多少遍职场版《楚门的世界》,"万一被同事看不起怎么办,领导会不会觉得我能力不行?"但事实上哪些看似工作业务娴熟的师兄、技术大牛,可能都曾在夜深人静时对着“段错误”怀疑过人生,但其实,暴露无知才是求知的第一步。
2,错误认知
我之前就被老板PUA过:"自己的问题应该自己解决""你是一名优秀的985本硕研究生,遇到不会的就应该边学边做好它",所以导致每每遇到问题我都会觉得我应该独立解决问题才是我的真本事。但是"优秀开发者就该单枪匹马搞定所有问题"——这个神话正在摧毁无数程序员的职业生命,哪个伟大的产品不是由强大的团队完成的,《哪吒2》的成功也是要归功于几十上百家动画公司的,技术世界的复杂度早已超出个人极限,就像咱们不可能用单核CPU运行深度学习模型。
3,性格因素
内向的i人,不善交流,又害怕被拒绝又不想麻烦别人(不会有你吧),性格特质则像隐形的锁链——我们总在"不想暴露硬件知识短板"和"担心被笑软件思维"之间纠结,却忘记了嵌入式开发的本质是数字与模拟的对话。就像设计混合信号电路,需要ADC的精确也需要运放的宽容。
二、不会寻求帮助的后果
1,时间成本
往小了说,一个有经验的同事/同学用五分钟或者三行代码就能解决的问题,而你自己摸索可能要花整整一天,甚至还可能解决不好;往大了说,项目进度被耽误了,工作效率严重下降了,周报总不能写:解决一个报错,方法是重装了系统。
2,心理负担
打个不恰当的比方:那个因为不敢问Q格式定点数优化而通宵调试DSP算法的工程师,在听到FAE讲解补偿滤波器设计时突然明白:自己用笨办法实现的FFT算法,其实芯片自带硬件加速单元。技术债不可怕,可怕的是在示波器前死磕时错过的架构级解决方案。更怕的是,越报错越焦虑,越焦虑越报错,汗流浃背,心跳加速,要真还解决不了,甚至可能一蹶不振。
3,团队影响
就像最一开始截图里的,一年前遇到过这个问题,复现且解决了,还写了笔记,结果后来者再遇到还是要重新头大,这就是很明显的本可以共享的经验没有共享、本可以避免的坑没有避免,未共享的经验就像断裂的齿轮,每个成员都可能重蹈前任的覆辙。
三、啥时候该寻求帮助?
(正题开始了噢)
1,该自己解决的
基础的语法错误、简单的环境配置问题、经常遇见的问题、有明显的错误报告打印的时候,以及报错内容在百度、CSDN上一搜一大把的时候,别去问,自个儿解决了就成,有时候照着网上教程走十分钟就解决的事情,问一圈人说不定还不一定能解决,然后跟这个人唠一句,跟那个人扯两句,一个小时没了。
2,该求助别人的
自己解决半天了还是没招的时候,网上搜了半天还是没思路的时候,知道这件事组里有人做过的时候,知道这段代码是谁用过或者维护过的时候,需要业务相关的上下文的时候,不用纠结,快去问吧,会有好消息的。
四、咋正确地寻求帮助?
1,求助前应该准备什么
首先,学会表达,学会表达,学会表达!把你的问题在什么情况下出现,环境信息,代码片段,错误日志都准备好,最好还能列出来你都尝试过哪些方法,当前有没有跟着别人的方法走到哪一步,最好把如何复现以及你自己的猜测也准备好。而且在文字描述时,不要一大段话甚至不加标点,学会断句和合理分段,让别人看着也条理清晰。
2,选择合适的人求助
你做嵌入式的,就去问嵌入式的前辈,做ROS的,就去找机器人工程师,要像选择依赖库般谨慎——核心模块问题找架构师,业务逻辑咨询产品负责人,身边真的找不到合适的人提问,在网上找遇到过相同问题并解决的网友提问也不是不可,只是那样就别指望什么时效性了。
3,求助时机的选择
这个简单,你换位思考下就知道了,别人正在忙着敲代码的时候,最好别找;下班时间快到的时候,如果今天不是默认加班,别去找;别人正在开会的时候,也不要找。最好是提前给人家发个消息打个招呼,问问啥会儿有空,相当于预约一下。
五、提问的艺术
1,好的提问方式
提问时,表述清晰且有逻辑是非常重要的:“我在实现XX功能时遇到了问题,具体是在XX步骤中卡住了。”这样的提问能够让对方迅速理解你的困境,节省双方的时间;同时,可以提供一些你已经尝试过的解决方案:“我已经尝试了A、B、C方案,但都没有成功。”这样对方就能在了解你尝试过的方案后,更高效地提供帮助;提出问题时,适当的引导也很重要:“我觉得可能是XX原因,你觉得呢?”或者:“能否帮我看看这个思路对不对?”这些方式能够让对方理解你的思考过程,从而给出更有针对性的回答,而不是让人家再从0开始思考。
2,糟糕的提问方式
糟糕的提问通常会让对方感到困惑或者难以提供帮助:“我Docker打不开了啊?”这问题就太过于模糊,让人难以理解你具体想要什么样的答案。类似的,“为什么我的代码不行?”或“帮我看看哪错了?”等问题也很容易导致回答者无法准确判断你的需求,那不妥妥浪费时间吗。尤其是“这个bug怎么解决?”这样的提问,不仅缺乏足够的背景信息和细节,还无法帮助对方快速定位问题。这些不清晰的提问方式不仅可能得不到有效的帮助,也会让对方感到有些无从下手,甚至会对你有些厌烦,遇到脾气不好的人索性一句“不知道”就给你打发了。
3,提问时的注意事项
首先是说明你的问题背景、你已经尝试的方案以及你的思考过程,这样人家才能更准确地理解你的问题并给予帮助;同时保持谦虚和诚恳的态度是非常重要的;向他人提问时,记得尊重对方的时间,看到人家着急忙别的事情就别耽误人家;提问后及时总结得到的答复,并感谢人家的帮助,体现出你的感激之情和对他人时间的尊重。
六、建立良性循环
及时记录和总结、主动回馈他人以及建立系统化的学习体系。首先,通过记录解决方案、总结问题原因、整理相关知识点并分享给同事,可以帮助自己与团队不断积累经验。其次,主动帮助遇到类似问题的同事,分享经验教训,不仅能加深自己的理解,也能促进团队合作和知识传递。最后,系统化的学习体系通过收集常见问题、整理解决方案并形成知识沉淀,不仅提升个人能力,也为团队长期发展奠定基础,从而形成持续循环的学习与成长。(这段话AI写的,太有那味了)
思路来自站外作者辣条加辣《自洽的程序员》
作为牛马,为了那点“窝囊费”,难免有些抱怨和感悟,汇总一下叭~