寫程式發生錯誤的時候,時常會聽到有人說:
- 唉唉!你知道為什麼這個 function 會壞掉嗎?
- 我記得剛剛數據還可以正確,怎麼現在都歸零了?
- 為什麼昨天還可以跑,今天就卡在這裡了?
這些只是工程師工作的日常而已,根本冰山一角。如果你的同事遇到任何 Bug 都先跑來問你,當作 Bug 策畫師,那又該怎麼辦呢?以下是我自己的一些個人看法,你可以參考參考。
在詳細說明之前,讓我打個小廣告。在我的方格子內主要會討論工程師的話題,偶爾會有一些心態或是網路行銷這類的話題。感興趣歡迎追蹤一下喔!
階段一:好心人做到底
寫程式遇到 Bug 難免,沒有遇到的話,會讓人認為是不是沒認真寫,或者說難度不夠。在公司職場上,若是同事遇到比較難的 Bug,起初我都是抱持著好心人做到底的想法,協助看看問題出在哪。
有一些資質比較好的同事,可能是暫時被一些外部因素影響,才會出現 Bug 的,幫忙看一下也不會佔用太多時間。例如:
- 資料庫剛才被重開了,所以 function 才會錯。
- 剛才那些電子表單被審核過,所以現在都歸零了。
- 因為昨天有匯入一些假資料,所以才會有資料卡住。
若是一些沒有積極態度的同事碰到問題,往往就是找是身邊隨便抓一個來問。這種的 Bug 都非常低階或是初級,往往也比較不容易想到,可能就會佔用很多時間。
當下有時間就會幫忙看,有時就會避開不碰。
階段二:以物換物
當碰上的 Bug 越多,似乎有越來越多同事慕名而來,甚至有些根本與我無關的電腦使用問題都會被問到。
若是這時有一些熟面孔,我可能會協助幫忙解決 Bug,但是就會連帶要求以物換物。例如:
- 今天午餐飲料給你請。
- 那下次跟你借文件時,別那麼不甘願。
有時候可能會被認為,開發程式是一個團隊合作的業務,所以彼此互相支援是應該的。不過只要有一定規模的公司,內部多少都會有比較投機的員工,總是會想著要如何佔到別人便宜。
因此,我認為以物換物算是一個最小程度的回報了。
階段三:Google 是你的朋友
當自己手邊的事務真的忙不過來,而且身旁的 Bug 同事又一直不斷的騷擾,並打斷思緒。
這時我都會說「等一下去看!」,或是有一搭沒一搭的,反正就是不會過去看就是了。神奇的是,往往等了一段時間,這些 Bug 同事的問題就會自己解決了。他們可能是去找其他人協助,或是自己想通了。
其實,我認為工程師遇到 Bug,最適合且最理想的解法應該是後者自己去找答案,要別人協助都是幫助較小的。
唯有自己找到答案之後,那就會比較有記憶點,而且也能夠避免下次再犯。現在 Google 那麼方便,不管人生大小事都可以問它,它都會給出一個適當的解答,只要你關鍵字寫對。
我曾在一本書看到一個論述問對問題比找方法還難,這也是我當工程師這幾年的體悟之一。
這句話是什麼意思呢?
想像一下你上次聽課程講座時的情境,當講者說到某些讓你感到困惑的論點時,你會舉手發問嗎?如果是,那運用精簡的文句提及剛才的疑問,這邊就會用到問對問題的技巧了。
寫程式也是一樣的,達到同樣功能的方法那麼多,哪個才是你要的?哪個效率比較好?這都是要搜尋正確的關鍵字問 Google 才能知道。這對工程師來說是一個必備技能啊!
看到這裡,如果你跟我一樣是個常常被 Bug 同事糾纏的人,也許你可以參考我的作法。如果你是一個喜歡與同事討論 Bug 的人,那我建議你可以多跟 Google 討論。
結論
職場上有許多同事關係需要處理,平輩之間相互討論是一件挺不錯的事情,但我認為碰上程式問題應該自我排除,增加自我學習能力。你身旁也有不斷提問的 Bug 同事嗎?你又是怎麼處理他們的呢?歡迎留言跟我一起討論喔!
不知道這篇的內容有沒有幫助到大家,有什麼想法都可以留言告訴我!若是有其他感興趣的話題,也歡迎跟我說,這樣我才有辦法調整撰文方向,甘溫唷!
除了平時寫寫技術文章,我自己也有經營一個攝影部落格,分享攝影技術、開箱以及旅遊,這些內容都不會放在這裡。感興趣的也歡迎去那邊訂閱喔!
◆ 攝影部落格:https://aidaidme.com/
◆ 歡迎來信:support@aidaidme.com
註:文中圖片源自 Pexel 或 Pixabay