Re: [轉錄] 這幾句話，輕鬆惹火程式設計師

看板Soft_Job作者 (楊宗緯)時間12年前 (2013/04/04 13:01), 編輯推噓16(16推 0噓 57→)
留言73則, 14人參與, 最新討論串5/6 (看更多)
※ 引述《TonyQ (自立而後立人)》之銘言： : ----------------節錄------------------- : 在軟體行業接近10年了，有很多話是不能對程式設計師講的，而這些你可能從來沒有留意 : 過，以下是我跟朋友們討論後歸結出來的幾個經典台詞： : 這個應該很簡單，下午應該可以給我吧 : 對方的心裡正在想著：「用嘴巴講最簡單，如果用嘴巴可以寫程式，你應該是天下第一的 : coding高手了。」，其實在我們不熟悉的專業面前，永遠不要說簡單。 : 你這是技術人員思維 : 對方的心裡正在想著：「意思是我不懂囉？」，這句話聽在程式設計師的耳裡或許帶有一 : 些諷刺的意味，意味著對方思考侷限、狹隘，可能你沒有這樣的意思，但若有人跟你說： : 「你這是設計師的思維」、「你這是業務思維」，是否也代表著對方在否定你呢？ : ......詳細請點回原文觀看 XD 要是我有時間的話，我一定會跟他解釋，為何要花那麼多時間。 別說主管與PM了，就連工程師也一堆這種思維， 這功能很簡單，我寫只要1小時，為何你要寫兩三天，而且過幾天才能開始寫。 我通常都會說，你覺得你只要一個小時， 你就去寫，而不是花幾個小時跟我爭這種問題。 我手邊有更重要的專案要做。 但通常的結果都是，大家花幾天工時一直叫我寫， 不然就是開會討論為何要花那麼久， 然後自己沒事做了就跟同事聊天，自己卻不動手。 很多人寧可浪費部門整體效率， 也不願意自己動手去做事，這是我自己常遇到的現實，不知道大家是否都這樣? 另外，同樣一個要上線的功能，有經驗的人反而需要比較多的時間，也是常見。 -------------------------------------------- 舉例，一份文字檔 csv，轉存資料庫： 沒經驗的人： 設計資料庫 10分鐘， 寫程式 30分鐘。 --------------------- 果然不到一個小時就寫完。 有經驗又有良心的人： 考慮資料量成長速度與規模，欄位形態要用什麼才有效率又有擴充性、 資料庫會用多久，每天會增加多少紀錄? 建立索引Index。 這些事情，至少花有經驗的人30分鐘起跳。但沒經驗的菜鳥早就寫完程式了。 寫程式 30 分鐘。 寫測試程式 (產生大量csv資料，輸入程式，輸出資料庫，驗證正確性與效能是否可上線) 至少兩個小時。 -------------------- 完成同樣功能，至少三個小時起跳。(我還是低估與忽略很多事情) ---------------------------------- 以上還是很簡單的功能，若是系統更複雜多變， 有經驗的人和沒經驗的人，所耗費的時間會差更多。 但是，在台灣阿，很多"技術人員"，只學學表面的東西， 就到處放話這東西很簡單啊，幾個小時就能寫完了。 連技術人員都一堆這種人，就別怪 PM、長官也這樣了。 ※ 編輯: YunJonWei 來自: 61.58.177.60 (04/04 13:04)
→
04/04 13:06, , 1F
還有一種是沒經驗的....30分鐘過後...... 還在想怎麼作.....
04/04 13:06, 1F
→
04/04 13:06, , 2F
還沒想到
04/04 13:06, 2F
推
04/04 13:15, , 3F
還滿佩服那些光是動張嘴就可以完成事情的人
04/04 13:15, 3F
→
04/04 13:15, , 4F
不過這種人不能太多 否則組織肯定會崩潰
04/04 13:15, 4F
推
04/04 13:52, , 5F
推~也推一樓~考慮得越多~就越難動手~就像同樣是Server~撐
04/04 13:52, 5F
→
04/04 13:53, , 6F
50人和上千人的設計是大大的不同...
04/04 13:53, 6F
推
04/04 13:53, , 7F
我公司前輩寫很快，但是一堆不符合W3C的語法、傳入的參數
04/04 13:53, 7F
→
04/04 13:55, , 8F
這個很中肯,當經驗越多考慮的就會越多
04/04 13:55, 8F
→
04/04 13:55, , 9F
也不檢查，相比之下，我產出的速度自然就跟他差滿多的
04/04 13:55, 9F
→
04/04 13:56, , 10F
但是常常上級都只會認為這個很容易
04/04 13:56, 10F
推
04/04 13:59, , 11F
在主管眼中就變成我效率不好，動作慢
04/04 13:59, 11F
→
04/04 14:00, , 12F
我這邊也是...主管就會說你不要把事情想的這麼複雜
04/04 14:00, 12F
→
04/04 14:00, , 13F
我心裡OS:那這個程式最後出包責任難道你要扛嗎?
04/04 14:00, 13F
→
04/04 14:18, , 14F
樓上講的很有討論空間~一個是事情到底有沒有這麼複雜~一個
04/04 14:18, 14F
→
04/04 14:19, , 15F
是自己是不是想得太複雜...印象最深刻的是某次專案用到系
04/04 14:19, 15F
→
04/04 14:20, , 16F
統內的某個檔案~前輩在考慮如果這個檔案不見了~該怎麼辦?
04/04 14:20, 16F
→
04/04 14:22, , 17F
當時心裡OS是:檔案被砍~作業系統自己都不見得能救回來正常
04/04 14:22, 17F
→
04/04 14:23, , 18F
運作了~還想要自己補上檔案讓自己程式能跑?這...
04/04 14:23, 18F
推
04/04 15:36, , 19F
推樓上 有時候是真的複雜 有時候是自己沒想清楚
04/04 15:36, 19F
推
04/04 15:40, , 20F
有同感，我也是被認為想太多，但事實上就是需要想這麼多
04/04 15:40, 20F
→
04/04 15:40, , 21F
少想到的，到後來通常還是要補上，不見得比較省時
04/04 15:40, 21F
→
04/04 15:41, , 22F
有時候寫程式就是「出來混的，遲早都要還」
04/04 15:41, 22F
→
04/04 15:42, , 23F
只是看誰來還，什麼時候還而已，還是還使用者的觀感(無形)
04/04 15:42, 23F
→
04/04 15:44, , 24F
另外就是防呆機制，也是花時間的項目
04/04 15:44, 24F
→
04/04 15:45, , 25F
防呆跟錯訊處理、異常處理，其實都滿花時間的
04/04 15:45, 25F
推
04/04 15:56, , 26F
難免還是會遇到認知差距,管理的人會覺得,你決定要花比較多時
04/04 15:56, 26F
→
04/04 15:57, , 27F
間考慮適當的寫法,是因為你沒經驗. 往往雖自己決定做對的事,
04/04 15:57, 27F
→
04/04 15:58, , 28F
卻會被其他人隨口批評比較. 遇到嘴雜的團隊真是難做事.
04/04 15:58, 28F
推
04/04 16:47, , 29F
簡單版Facebook 簡單版Amazon 簡單版Google ...
04/04 16:47, 29F
→
04/04 16:49, , 30F
主管無法賞識也是問題~尤其是根本沒看過你的source code~
04/04 16:49, 30F
→
04/04 16:51, , 31F
只會以花費時間來懷疑，甚至批評你的能力...誰受得了...
04/04 16:51, 31F
推
04/04 17:20, , 32F
推樓上，我老闆最常講的一句話:不用看Code就知道你寫錯了
04/04 17:20, 32F
推
04/04 21:05, , 33F
慢慢來比較好 寫快只會被人加工作而已...
04/04 21:05, 33F
→
04/04 22:47, , 34F
若以寫程式的快慢來評斷能力，那麼我應該是沒有能力
04/04 22:47, 34F
→
04/04 22:49, , 35F
但往往事實可以證明，常常還是會被追討少寫的部份
04/04 22:49, 35F
→
04/04 22:50, , 36F
若老闆或客戶堅持，那麼我會說可能那個部份我會沒有處理到
04/04 22:50, 36F
→
04/04 22:51, , 37F
若接受，那麼我就在這次不做這部分的處理，以後有需要再加
04/04 22:51, 37F
→
04/05 16:08, , 38F
不過溝通的部份還是最好是年資最老或是經驗最久的才這樣做
04/05 16:08, 38F
→
04/05 16:09, , 39F
資淺的人還是不要做那麼多確認，要不然可能會被認為難溝通
04/05 16:09, 39F
→
04/05 16:12, , 40F
老闆可能會認為叫你做個工作就回幾十句話，推三阻四的
04/05 16:12, 40F
→
04/05 16:13, , 41F
馬上就黑了XD
04/05 16:13, 41F
→
04/05 16:15, , 42F
只能默默的刪減一些工作，或準備逃難XD
04/05 16:15, 42F
→
04/05 16:19, , 43F
通常被刪減的工作就是測試、防呆的處理
04/05 16:19, 43F
推
04/05 16:22, , 44F
另外就是一些架構、彈性、規劃的時間也是會被刪減
04/05 16:22, 44F
→
04/05 21:03, , 45F
@@要看狀況吧?我反而會覺得新人不懂就要問~但是最好問前先
04/05 21:03, 45F
→
04/05 21:04, , 46F
想過~避免再問一次~規格也是~把認為不合理或有疑問的地方
04/05 21:04, 46F
→
04/05 21:05, , 47F
都記下來一次問~只要稍微覺得有點奇怪的都要~千萬不要自己
04/05 21:05, 47F
→
04/05 21:06, , 48F
認為沒差就算了~如果不清楚人家的明白就埋頭苦幹~到頭來還
04/05 21:06, 48F
→
04/05 21:06, , 49F
是要再改掉重寫~倒楣的是自己...
04/05 21:06, 49F
→
04/05 21:35, , 50F
能確認多少東西要看公司的風氣
04/05 21:35, 50F
→
04/05 21:35, , 51F
我就待過一家公司因為確認需求而黑掉
04/05 21:35, 51F
→
04/05 21:36, , 52F
雖然那家公司後來有再找我回來，但我已經不想回去了
04/05 21:36, 52F
→
04/05 21:39, , 53F
不是只有新人會確認需求，有經驗及良心的人也會確認需求
04/05 21:39, 53F
→
04/06 07:17, , 54F
現在的老闆大多有速食主義..要泡麵能吃到佛跳牆..這種速食主義
04/06 07:17, 54F
→
04/06 07:17, , 55F
難保有一天泡泡就爆炸...
04/06 07:17, 55F
→
04/06 07:41, , 56F
呵~我也曾讓人覺得"我是不是都聽不懂"~可是我寧願多問~也
04/06 07:41, 56F
→
04/06 07:42, , 57F
不要做了才換來一句"我要的不是這個"~做到流汗又被嫌~不過
04/06 07:42, 57F
→
04/06 07:43, , 58F
確認個幾次就會被罵~這樣的職場不皮一點~很難待得下去...
04/06 07:43, 58F
推
04/06 11:48, , 59F
推astt88的「看公司的風氣」
04/06 11:48, 59F
推
04/07 01:46, , 60F
我覺得最主要的問題還是溝通，今天若是主管，能五分鐘
04/07 01:46, 60F
→
04/07 01:46, , 61F
交代完的事，為何要花半小時把每個細節講一遍
04/07 01:46, 61F
推
04/07 01:52, , 62F
這中間是要陪養溝通默契的，否則規格書訂再細還不是有洞
04/07 01:52, 62F
→
04/07 01:52, , 63F
鑽，是我也不會希望PG浪費太多無益的時間
04/07 01:52, 63F
推
04/07 02:15, , 64F
新人應該要不怕犯錯，錯了就想辦法改，才會有辦法磨合，
04/07 02:15, 64F
→
04/07 02:15, , 65F
而不是什麼都一定要問，什麼都要請示，到最後沒講所以沒
04/07 02:15, 65F
→
04/07 02:15, , 66F
做變得理所當然
04/07 02:15, 66F
→
04/07 11:50, , 67F
另一方面也是領域知識的問題~新人並不具備這種東西~很難不
04/07 11:50, 67F
→
04/07 11:51, , 68F
問吧?再者~我總覺得有點誤會~我強調的是自己覺得不合理和
04/07 11:51, 68F
→
04/07 11:52, , 69F
有疑問的時候要問~而不是青菜蘿蔔隨便問~隨便問當然惹人嫌
04/07 11:52, 69F
→
04/07 12:00, , 70F
而且~就算資深了~還是有機率沒搞清楚人家的明白之外~他反
04/07 12:00, 70F
→
04/07 12:00, , 71F
而可能一聽就問得更多~因為太多不合理...XD
04/07 12:00, 71F
推
04/08 12:19, , 72F
大部分案子沒空讓新人有時間在那裏犯錯..不知道就要問
04/08 12:19, 72F
→
04/08 17:46, , 73F
我也是傾向不懂、不清楚就要問，公司文化問題就XD
04/08 17:46, 73F
‣ 更多 YunJonWei 的文章
文章代碼(AID): #1HNGaTZx (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 5 之 6 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共6篇)
‣ 更多 YunJonWei 的文章
文章代碼(AID): #1HNGaTZx (Soft_Job)