????樂(lè)天投資（Rakuten Ventures）主理合伙人Sae Min Ahn的回答

????我認(rèn)為，以下這些錯(cuò)誤并非軟件工程師的專利，所有滿懷希望，剛步入職場(chǎng)的年輕人都很容易犯這些錯(cuò)誤。

????愛(ài)公司多過(guò)愛(ài)工作：這或許是我犯下的最大的錯(cuò)誤之一。我當(dāng)時(shí)堅(jiān)信，只要我進(jìn)入那家我心儀已久的公司，最終就一定能找到適合自己的崗位。更痛苦地是，我還放棄了另外一家公司提供的一份好工作，只是因?yàn)槲蚁矚g當(dāng)時(shí)那家雇主的品牌。

????相信上司知道所有問(wèn)題的答案，并且總能提供正確的指導(dǎo)：這是我得到的最殘酷、最令人失望的一條教訓(xùn)，但很快我意識(shí)到這也是最寶貴的教訓(xùn)。有一位上司深得我的信任，我對(duì)她深信不疑。不論她告訴我什么，我都奉若圭臬，認(rèn)為她的話絕對(duì)可靠。結(jié)果證明，她與我一樣愚蠢，在面臨混亂或棘手的難題時(shí)，她甚至?xí)霈F(xiàn)精神虐待傾向。

????堅(jiān)信應(yīng)該持有黑白分明的商業(yè)立場(chǎng)：曾幾何時(shí)，受大量韓國(guó)公司的影響，這真的是一個(gè)問(wèn)題，但愿它現(xiàn)在已不復(fù)存在。他們會(huì)向剛畢業(yè)的學(xué)生灌輸這樣一種思想：競(jìng)爭(zhēng)對(duì)手是“敵人”，甚至不理性地將他們描繪成“邪惡的”一方。這種做法確實(shí)能獲得短期的忠誠(chéng)，但就我所知，許多人養(yǎng)成了一種壞習(xí)慣，他們?cè)谇楦猩贤度胩鄷r(shí)間去“憎恨”競(jìng)爭(zhēng)對(duì)手，而沒(méi)有充分考慮大局。

????相信在工作首日，自己就開(kāi)始做“很酷的事情”：這是我一生中非常可笑的一段時(shí)間，因?yàn)槲耶?dāng)時(shí)認(rèn)為自己可以挑戰(zhàn)整個(gè)世界，可以讓公司的收入曲線顯著上升。我很快就意識(shí)到，自己掌握的技能幾乎為零，必須學(xué)習(xí)如何規(guī)劃、安排優(yōu)先事項(xiàng)和執(zhí)行。每走出一步就像拔牙一樣痛苦，但那又如何，我已經(jīng)走到這一步了，不是嗎？

????雅虎（Yahoo）軟件工程師Allen Wu的回答

????我記得畢業(yè)后從事第一份軟件工程師工作時(shí)曾經(jīng)犯下兩個(gè)錯(cuò)誤。但愿我的經(jīng)歷能夠鼓勵(lì)剛畢業(yè)的大學(xué)生們更謹(jǐn)慎地避免這些常見(jiàn)錯(cuò)誤。

????第一個(gè)錯(cuò)誤是，嚴(yán)重低估完成一項(xiàng)功能所需要的時(shí)間。業(yè)務(wù)要求規(guī)定，功能在技術(shù)上不能太過(guò)復(fù)雜，而且要易于操作。最終結(jié)果是，跨團(tuán)隊(duì)協(xié)作、對(duì)其他人的依賴性，以及不斷更新的要求，占用了大部分時(shí)間。而不斷更新的要求常常導(dǎo)致許多重復(fù)的開(kāi)發(fā)工作。軟件工程領(lǐng)域有一句格言是這樣說(shuō)的：90%的工作會(huì)用去90%的時(shí)間，剩余10%的工作還需要90%的時(shí)間，最終結(jié)果是，開(kāi)發(fā)時(shí)間將是預(yù)估時(shí)間的180%。即便在軟件開(kāi)發(fā)行業(yè)積累了一些經(jīng)驗(yàn)之后，我依然很難準(zhǔn)確估算一項(xiàng)任務(wù)的開(kāi)發(fā)時(shí)間，盡管現(xiàn)在的情況有所好轉(zhuǎn)。

????Answer by Sae Min Ahn, managing partner at Rakuten Ventures

????This is not specifically for software engineers but I believe this applies for the many young hopefuls walking into their first company.

????Falling more in love with the company than the job:Probably one of the biggest mistakes I made. I truly believed that if I got into the company I wanted, I would eventually find the role that was right for me. What was more painful was that I gave up an amazing role in a different company because I liked the branding of my-then-employer

????Believing that my manager had all the answers and provided consistently right guidance: One of the hardest and disappointing lessons I had to learn but soon came to realize was the most valuable. I had a manager that I truly trusted and believed in. Whatever she told me I believed was canon and infallible. It turned out she was just as clueless as I was and had a tenancy for emotional abuse when things got hectic or too hot to handle

????Believing that having a black and white viewpoint on business execution was the right path: This was actually an issue – I hope it isn’t anymore – with a lot of the Korean companies at the time. They try to indoctrinate the new grad into thinking that their competitor is “the enemy” or even portray them as “evil” in an irrational mantra. I’m sure it was to gain short-term loyalty, but for a lot of people I know, they picked up a really bad habit of emotionally expending too much time “hating” on their rivals and not thinking enough about the bigger picture of things

????Believing that I would start doing “cool stuff” day one of my job: This was a funny time in my life as I thought I could take on the world and make the company revenue chart hit a neck-breaking hockey stick vector. I soon came to realize I had little applicable skills and had to really learn how to plan, prioritize and execute. Each step was like pulling a tooth but hey, I’m here aren’t I?

????Answer by Allen Wu, software engineer at Yahoo

????Two mistakes I made during my first job in software engineering as a new grad come to mind. Hopefully reading about my experiences will encourage new college grads to be more cognizant of these common mistakes.

????The first was grossly underestimating how long it would take to complete a feature. The business requirements suggested that the feature was not very technically complex and would be straightforward to implement. What ended up being responsible for the bulk of the time was cross team collaboration, dependencies on others, and evolving requirements, which led to many iterations of development. There’s an aphorism in software engineering that says that 90% of the work takes 90% of the estimated time, and the remaining 10% of work takes another 90% of time, resulting in a total development time of 180% of the original estimate. Even after some experience in software development, it is still really difficult for me to accurately estimate the development time of a task (see Jan Christian Meyer’s answer to Software Engineering: What is the hardest thing you do as a software engineer?), though it’s getting better.