※ 引述《school5566 (千年大嫌者)》之铭言： : 小弟入行不久还算新手 : 请问各位平常如果遇到问题 : 就是专案做到卡住啦 一般那些问题可以问同事主管? : 因为我常常遇到卡住去问直属主管 : (不是我故意问他 是经理说可以来问他的) : 结果每次都不管我 还会念说工程师自己要解决问题啊 : 不要一个口令一个动作啊 这个东西不该问啊 : 可是新人孤立无援真的很辛苦 : 请问一般什麽问题是可以问的? : 好比说框架官方文件看不懂 或是一个函式看不懂怎麽用? : 前人的程式码看不懂 bug解不掉 或是根本不知道专案怎麽做下去之类的? : 可是他刚进公司却又跟我说卡住就赶快问不要拖 浪费时间之类的 : 结果问他又不理我... : 什麽可以问什麽不能问啊?还是其实都可以只是单纯就被主管搞而已? 我以前在学校修课时，觉得要竭尽所能自己解决问题，等到真的确定自己解决不了的问题，才去询问同学或老师。结果往往是我自己长时间解决问题的过程中，就彻底失去信心，而课程进度往前飙，也不再有心去回头发问。於是问题就愈积愈多摆在那边，没解。 所以问题应该还是要问的。但应该怎麽问？什麽时候问？ 出了社会就决定转行的第一份工作，有个前辈带我，有问题我会尽快发问，而他也会在每次 code review 时教我更好的写法。那时候我还不会用版本控制，也常常分不清 delegate 模式的主客体。但回想那一个月後我成长的幅度，远胜过进公司前的三个月自学。 过了那一个月後，前辈就说自己很忙，也几乎不再 code review，从此只关心我的时程进度，很少过问实作细节。所幸已打下基础，那之後我就能自学与独立工作。 所以对新手来说，能有人解答问题，是离开新手村最快的方法。 後来前辈外派他国之後，我变成是小组内最资深成员，後续进来几位新人後，我决定以身作则，发起一种允许可以随时问问题的文化 —— 但若被问者正在忙碌，会鼓励他直接表示「正在忙」，而发问者可以决定，要自己继续尝试解决或询问别人。我发现除了分享经验与讨论解法之外，也经常发生的现象是，被问者忙完回头关心发问者，发现他已经自己解决问题了；或是发问者还在阐述问题时，就自己想到解法了（而被问者可能都还没听懂问题）。 「应该怎麽问问题」其实是一种团队文化，又因个人而异，很难有客观标准。发问的品质当然有技巧有方法，这点在素昧平生的网路上特别受到重视，但其实依据不同社群又有不同的发问文化，而在公司里这种面对面的团队合作模式，其实很适合鼓励直接互动、减少沟通摩擦。但这当然又因不同公司组织文化而异。 但更重要的是，你需要理解问问题只是「解决问题」的一种手段，公司真正在意的只有解决问题，而不要执着在钻研什麽能问、什麽不能问。如果接手了某功能要改很赶的功能，那你可以考虑提议转给当初实作的前辈做，开发效率可更快，自己再主动接其他不难或不赶的功能，或是你可以请求该前辈简单解释交接，又或是自己静下心来花上一天，好好把程式码读懂。 有太多种可能的解法，在不同团队不同时机点，适用状况都很难说，我觉得唯一准则是你感觉自身的学习有没有在「前进」。假若主管老是骂你不会自己解决问题，你可能很不服气而开始戮力自学成才，这也是一种好事；若主管极度包容你，经常帮你解决问题，以致你误以为自己适合个人主义盛行的资讯业，那也很可能是坏事。 -- 我最近写了一个叫作「工作咖啡馆」的 iOS App https://goo.gl/iBWJSs 我朋友拖拖拉拉也生出了 Android 版叫作「CaffeeTrip」 https://goo.gl/HnUQWQ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 219.85.42.133 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1495548087.A.38C.html