PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   七嘴八舌異言堂 (https://www.pcdvd.com.tw/forumdisplay.php?f=12)
-   -   工程師,您也患有「冒牌者症候群」嗎? (https://www.pcdvd.com.tw/showthread.php?t=1143017)

moronNZ 2018-03-01 10:22 PM

引用:
作者PM
https://medium.com/@p5d12000/%E5%B7%A5%E7%A8%8B%E5%B8%AB%E6%87%89%E8%A9%B2%E6%94%BE%E5%BF%83%E5%A4%A7%E8%86%BD%E5%9C%B0%E5%89%B5%E9%80%A0%E6%8A%80%E8%A1%93%E8%B2%A0%E5%82%B5-a8022d85810


這篇很寫實 :stupefy: 但其實角度不一樣,管理階在乎的根不是你的程式碼,他只在乎能不能交差、能不能快速解決、與單子不要掉而已。舉我老闆為例,都已是工科出身的,他就講過這沒啥很容易,卻不想容易為何bug滿天飛,人力要求越來越多。但記得看過linus對google演講,他就說過寫好的程式真的很難很難,也難怪他有這名言:talk is cheap, show me the code. 不過這也是現實的不同,一個是要生存,一個是要做到最好~

引用:
作者tommy84566
看過某晶片廠的code,這間後來被應呆兒併購,裡面的code亂七八糟,還有一大堆空格,換行,簡直傻眼,這一定是包給印度阿三寫的 :unbelief: :jolin: :think:

好的程式碼是需要定期維護的,這樣之後接手的才好上手易修改,不會花太多時間trace程式碼

一般面試是無法看出一個工程師是否有架構的組織構思與改善的動力。再說要動,還有人與商業上的現實問題,真的很難像opensource那樣想改就改,想丟掉就丟掉,想不玩就不玩。

灰長羊 2018-03-01 11:11 PM

https://www.ptt.cc/bbs/Oversea_Job/...5769.A.6C6.html

poenxu 2018-03-01 11:34 PM

引用:
作者老飛俠
另外出問題想出方法解決的是英雄,但是在開始時就用巧思避免將問題發生的可能性這種不會被列入功勞。

大家都把預防勝於治療的道理掛在嘴邊,但現實社會是成功預防問題不會得到任何感激

善戰之將,無赫赫之功

sutl 2018-03-02 12:23 AM

引用:
作者moronNZ
這篇很寫實 :stupefy: 但其實角度不一樣,管理階在乎的根不是你的程式碼,他只在乎能不能交差、能不能快速解決、與單子不要掉而已。舉我老闆為例,都已是工科出身的,他就講過這沒啥很容易,卻不想容易為何bug滿天飛,人力要求越來越多。但記得看過linus對google演講,他就說過寫好的程式真的很難很難,也難怪他有這名言:talk is cheap, show me the code. 不過這也是現實的不同,一個是要生存,一個是要做到最好~

去年日本新幹線轉向架斷裂差點發生重大車禍,原因就在川崎重工現場作業人員為了組裝交差,把7mm厚的鋼板磨薄來裝配,最多磨掉2.3mm,現在統計303個轉向架,有100個被磨薄,未來幾年要陸續汰換。

其實這在設計上也有問題,任何工業製品都會有公差,體積越大的產品公差越大,而且該轉向節上下還有焊接,熱漲冷縮下尺寸更難以控制,但顯然畫設計圖的人沒有現場經驗,結果就是現場只能磨薄來組裝。

如果設計不要那麼剛好,接觸面裝個墊片的話,就可以透過墊片厚薄來調整間隙了。

工業設計最忌諱剛剛好或完美,那幾乎注定完蛋。

Earstorm-5 2018-03-02 05:46 AM

引用:
作者PM
https://medium.com/@p5d12000/%E5%B7%A5%E7%A8%8B%E5%B8%AB%E6%87%89%E8%A9%B2%E6%94%BE%E5%BF%83%E5%A4%A7%E8%86%BD%E5%9C%B0%E5%89%B5%E9%80%A0%E6%8A%80%E8%A1%93%E8%B2%A0%E5%82%B5-a8022d85810


... 好久沒看到這麼直白的說明, 我啞口無言可以回, 因為完全符合現實!

所謂的工作成效就是上級要的, 公司要的"顯性結果," 而不是自己理想中的.

不只是寫程式, 任何工作都可以符合這個觀點.

PS. 即使你有能力同時擠出公司要的成果以及達到自己的理想, 太容易被接手也是問題.

roger214 2018-03-02 08:40 AM

我寫程式的理念是程式碼本身就是最好的註解,所以我寫的程式讓別人接手時,其實加的註解不用很多也很容易看懂。

我也替人擦屁股過很多次,很多只上過高階語言課程的程式師,寫出的程式就越容易出現邏輯錯誤,甚至很多明顯就是急就章的時候,才可能出現除0錯誤等類似的小學生錯誤,有時候真的有些無言。

更慘的是,這樣的程式竟然已經work很久了,想全部大改根本不可能,接手後幾乎大多時間都花在修改類似的錯誤,真的很沒效率。

Nicole1120 2018-03-02 08:48 AM

引用:
作者moronNZ
talk is cheap, show me the code

我也是這種個性的人,被我看code 的人會非常不好受.
但要能讓我忍不住要請過來review code 的人,工作上一定出很大的問題.

A級黑豬肉 2018-03-02 10:43 AM

引用:
作者PM
https://medium.com/@p5d12000/%E5%B7%A5%E7%A8%8B%E5%B8%AB%E6%87%89%E8%A9%B2%E6%94%BE%E5%BF%83%E5%A4%A7%E8%86%BD%E5%9C%B0%E5%89%B5%E9%80%A0%E6%8A%80%E8%A1%93%E8%B2%A0%E5%82%B5-a8022d85810


其實... 根本不必要擔心創造技術債的問題...
光是時間壓力就會有足夠的技術債要未來解決。

bigdatasmallapp 2018-03-02 10:47 AM

引用:
作者PM
https://medium.com/@p5d12000/%E5%B7%A5%E7%A8%8B%E5%B8%AB%E6%87%89%E8%A9%B2%E6%94%BE%E5%BF%83%E5%A4%A7%E8%86%BD%E5%9C%B0%E5%89%B5%E9%80%A0%E6%8A%80%E8%A1%93%E8%B2%A0%E5%82%B5-a8022d85810

我個人完全支持這樣的論調

這年頭你替別人想這麼多,真的太累了

而且做些工作不會讓你的價值提高

Earstorm-5 2018-03-02 11:20 AM

剛剛這類事情又發生了, 我要開始順順處理, 同事們反對, 只因為"他們了解老闆習慣."

然後就是A延遲, B跟著延遲, C會延遲更多, D準備下周再來處理的模式下去, 拖一天算一天..


所有的時間均為GMT +8。 現在的時間是07:05 AM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。