Re: [心得] 無所適從

[qrtt1 (有些事，有時候。。。)]

※ 引述《qwer820404 (beans)》之銘言：
: 在某間資訊公司實習做了三個月了，這三個月大小事情不斷讓我很挫折。
: 上來分享一下我的心得，也許對以後想去打工或實習的人有幫助。
: 本文：
: 當初在面試的時候，有問了一下工作內容，說是處理Error Log之類的，等到主管
: 覺得你能力不錯，才會請你去試著寫一些程式。
: 那就抱持著學習的心態進去。
: 一開始進去，就先幫忙寫一些監控程式，也都順利交案，半個月交了二支出去。
: 後來，主管就要我幫忙處理業務相關的程式，我就也沒多想什麼，總不能拒絕不做。
: 接了之後發現從分析 (修改現有程式，中間不知道經過幾版了，連個文件都沒有…)，
: 開始就我負責弄，然後在業務邏輯不明的情況下 (沒有主動給我任何資料參考，只請
: 我看程式碼跟SQL，不懂再問)，我就花了時間看 (有時會帶回家看到半夜，同事說我
: 傻傻的)，然後就邊問邊弄，到連測試也是我弄，在這過程中其實問題就很大了…
: (1)業務邏輯一開始不明的情況下，去做分析的動作，必然無法全盤都顧到，即便程式
:    碼有判斷式，註解(其實也寫的零零落落的)，我不相信看程式碼可以了解到一支程
:    式他所要處理的業務面(也許是我太嫩，其實有人做的到之類的)。
: (2)在工作的人都知道，有些事情是不能明講，也要看面對到的主管是什麼樣的類型，
:    過程中其實當我一直不斷的提問題，我想暗示的是說，我改起來會有問題，因為
:    我不懂的東西(業務面)太多了，我用問的也是只能問我看到的，那隱含的部份勢必
:    會遺漏
: (3)我自己在處理這種有Deadline的Project，規劃上的能力還需要加強，我不會拿因為
:    我是Rookie的理由來逃避，遲早都要會的。
: 到了Deadline交出去後，隔天客戶就說有問題，正職同事介入處理，我變協助的角色。
: 在跟同事討論的過程中，才發現我遺漏掉了哪些部份沒考慮到 (有人會問為什麼在修
: 的時候不去跟同事討論，因為同事他們也沒看過程式，不知道牽涉的業務面有多廣)。
: 當程式上線又下線的時候，我其實很難過也很挫折。
: 難過是因為我覺得我責任心很強，沒有處理好是我的錯。
: 挫折是因為我需要文件沒文件；用問的卻受阻於他人；想認真做但是處處碰壁。
: 我要的不是答案，但是連工具都不願意好好的給，我真的不知道怎麼做下去。
: 我一度認為是我自己能力不夠，所以才沒有辦法事情做好。
: 回到家常因為這些工作情緒，使得有一陣子天天都很不快樂。
: 後來跟家人 ，跟同事聊聊之後，心情有比較釋懷了一些。
: 能讓我高興的事情是我有很好的同事會關心我的情況並適當的幫助我發洩情緒，
: 也很高興自己不是在出社會後才遇到這種情況，下次再遇到我也比較會處理了。

        所有的事其實不一定有對錯，

        但在順序上有可以調整的範圍，這樣整體的舒適感會差很多。

        原來的順序是：

        1. 收到指示處理業務相關的程式

        2. 收到一個業務邏輯不明的程式
           試著在沒有文件的情況下，要一邊摸索一邊改程式與測試

        3. 在過中不斷向主管提問，試著暗示他這不是你能輕易處理的問題

        4. Deadline 交出去，被客戶說有問題

        5. 正職同事介入處理，討論中知道哪些沒考慮清楚


        如果順序改成：

        1. 收到指示處理業務相關的程式

        2. 收到一個業務邏輯不明的程式
           試著在沒有文件的情況下，要一邊摸索一邊改程式與測試

        3. 在過中不斷向主管提問，試著暗示他這不是你能輕易處理的問題

        5. 正職同事介入處理，討論中知道哪些沒考慮清楚

        4. Deadline 交出去，被客戶說有問題


        我們先不改變做法，但單純換了 4. 5. 的順序，會有哪些差別。

        1. 即使最後的結果是有問題的，

           但我想有同事的介入問題的範圍應該在大家能控制的程度，

           或是能輕易理解的程度，同時也有人幫你背書。

        2. 基本上你不是正職，其實不用自己抗那麼大的責任。

           早點讓同事參與你的工作內容

           大家不會覺得怎麼不事先問清楚，而弄了這個包讓別人善後。

           來自同事的責難會少點（雖然不確定你有沒有被責難）

        3. 以上二點，主要的差別在同事是『事前協助』或『事發善後』。

           我想不用多說，你知道面對這二種不同的情況，『心境』這是有差別的。



        對於沒有文件又需要人 review 的邏輯應該如何？

        先讓我回想一下第一次被交付寫一個新的 feature，

        前輩用中文寫了像課本上的虛擬碼，只差翻譯成實作語言罷了。

        不管邏輯如何複雜，都是能寫成課本上虛擬碼的樣子的，

        有 input、有 precondition、有 main logic、有 post condition

        有 result，或是 rain case 的 exception。



        試著將你的理解寫下來，具現化的東西才能供人審閱。

        我想科技還沒進步到能直接看你的大腦內是如何想某件事情的。

        就現上面示範的，我列出經歷事件的步驟，並試著調整它的順序

        來推測什麼情況大家心情不致於太惡劣，當然包含了你的心情。



        另外，您得學習的是得試著在 Deadline 60% 前完成大部分的事，

        這時主要的邏輯在你的理解內，應該要正確了。

        但可能不包含 error handling，對 rain case 的考慮可能也還沒實作。

        測試可能也還寫不周全。剩下的時間，你就是得細心處理這些枝微末節的事。

        並且重複找有能力 review 邏輯的人，確定你沒有少做、白做、做錯方向。

        這並不是學校作業，Deadline 前一刻上傳成功也有屍體分數。



        你不用太灰心的。學生的能力其實不差，

        但大多被『作業模式』訓練壞掉了，作業模式的二個與現實不符的情況：

        自己的作業自己想、自己寫，即使是不完全也會有同情分。

        而為了在 Deadline 前能寫出作業，就開 IDE 亂寫一通，

        有些人根本沒想過這樣寫到底好不好，或是符合需要嗎？



        你得反過來

        1. 先確定需要實作內容，並確定想法是正確的。

        2. 計劃什麼事要先做，才可能來得及做完所有的事。


        確認想法正確，如同前面提的。我個人覺得較有效率的方式就是寫下你的想法。

        因為寫下來可以讓人 review 上百次，說一次別人聽聽就忘了，

        也無法放在心上替你繼續 debug


        計劃該先做的事，那就是先確定該會的東西都是能在期限內掌握的，

        若需求是要把東西存在資料庫，而不是文字檔，

        你當然得包含學習運用資料庫 API 的時間。

        因為現實世界不像作業，簡單到不用想就會做，不然就抄別人的。

        更進階的就是寫一些 Proof of concept 驗證某些部分的可行性。



        加油 :)




--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.43.119.186
※ 編輯: qrtt1           來自: 114.43.119.186       (05/15 22:37)
推 nobody1:推
※ 編輯: qrtt1           來自: 114.43.119.186       (05/15 22:45)
推 MrJerome:PUSH
推 Ting1024:push 3
推 qwer820404:謝謝你的分析，在同事詢問方面…因為有些原因被擋下來
→ qwer820404:在詢問上面有些困難，至於同事介入提前，因為大家都有
→ qwer820404:自己的case要處理，他們很想幫我，但是對我負責的東西
→ qwer820404:不熟，再加上很多事情要處理。所以就沒時間幫我了。
→ qrtt1:所以，把你的想法具現化，讓人能不花時間地介入是個方法 :)
→ qwer820404:至於我要加強的部份可能就是您所提到的具現化的那塊
→ qwer820404:嗯 在團隊裡面做事情   是我仍須努力的地方。感謝指教
推 roga:推這篇~
推 viper9709:推~~
推 laiis:推
推 b96090088:推!!分析精闢!