寫程式發生錯誤的時候，時常會聽到有人說：
- 唉唉！你知道為什麼這個 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
