give praise
不只Josh Lockhart在topic上提到，在QA的時候Sebastian Bergmann也完全同意這個觀點，有時候工程師在忙碌中，聽到一句「 good job!」、「 nice work」的時候，其實就也夠了，在Josh寫slim的時候，其實也有很多負評，但當一些使用者不管是用email或twitter之類的跟Josh表達感謝的時候，Josh覺得完全可以取代千千萬萬的負評，從而有動力的繼續維護。
Josh Lockhart維護的slim framework、Sebastian Bergmann維護的PHPUnit，是完全沒有得到任何薪水的，支持他們繼續維護的最大動力，就是來自人們的感謝。
Do not punish mistake
犯錯時不要責備。
Josh提到，即使是他，在NMC的時候也犯了一堆錯誤，工程師們都會犯錯，但重要的是了解犯錯的原因，在下一次的時候避免掉，而不是一昧的責備，犯錯了，針對問題修復，學起來，別再犯，繼續往前邁進。
Don't use obviously
沒有「 很明顯地」這種事情，每個人都會有思考盲點，所以這才是團隊合作的價值，大家能彼此用不同的角度去解決問題，共同激發出彼此想不到的角度去切入，也許你看到另外一位工程師卡在一個地方很久，然後你一過去就看到並解決了，但這時候但這時候千萬不能說「這地方出錯的很明顯啊，你怎麼解不出來？」、「很明顯的，你似乎走神囉」。
或許你真的比這位工程師厲害，但或許也是因為運氣好，或是思考角度不一樣，但無論如何，在這個時候用obviously會達到負面的效果。
welcome feedback
永遠歡迎回饋。
無論你接到語氣多差的負評，只要裡面提供的feedback是有價值的，就要接受，認為自己的專案已經很好了是不可行的，永遠都還有更好的空間，必須要接納各種可以讓專案變得更好的意見。
這也跟上一段一樣，如果真的有個語氣不好的工程師指出你的錯誤，也要虛心接受，畢竟我們從這位工程師身上學到了新東西，幫助我們的技術更上一層樓，所以應該要心懷感激，當然，自己除了學到新東西之外，也記得教別人的時候，態度要好一點。
兩位大神在QA的時候著墨在上面幾項很多，而對於open source的看法卻有點不太一樣。
Josh Lockhart說open source不是一個人可以做得起來的，slim也是信任了幾位好朋友，把一些核心開發權交給他們一起維護，所以Josh說信任非常重要，如果一直巴著不放的話，slim不會像現在一樣這麼受到歡迎，運行的這麼好。
而Sebastian Bergmann剛好相反，如果給他重新選擇的話，可能不會這麼快交給其他人共同維護，到了後期，Sebastian在PHPUnit上維護的工作幾乎都是翻修code，讓可讀性變得更好，而這個工作非常無聊，佔用了非常多的時間而且無法全心全意開發新功能，PHPUnit內部的程式碼品質參差不齊。
Sebastian最後說了一句：「 Could have been better. 」
不只Josh Lockhart在topic上提到，在QA的時候Sebastian Bergmann也完全同意這個觀點，有時候工程師在忙碌中，聽到一句「 good job!」、「 nice work」的時候，其實就也夠了，在Josh寫slim的時候，其實也有很多負評，但當一些使用者不管是用email或twitter之類的跟Josh表達感謝的時候，Josh覺得完全可以取代千千萬萬的負評，從而有動力的繼續維護。
Josh Lockhart維護的slim framework、Sebastian Bergmann維護的PHPUnit，是完全沒有得到任何薪水的，支持他們繼續維護的最大動力，就是來自人們的感謝。
Do not punish mistake
犯錯時不要責備。
Josh提到，即使是他，在NMC的時候也犯了一堆錯誤，工程師們都會犯錯，但重要的是了解犯錯的原因，在下一次的時候避免掉，而不是一昧的責備，犯錯了，針對問題修復，學起來，別再犯，繼續往前邁進。
Don't use obviously
沒有「 很明顯地」這種事情，每個人都會有思考盲點，所以這才是團隊合作的價值，大家能彼此用不同的角度去解決問題，共同激發出彼此想不到的角度去切入，也許你看到另外一位工程師卡在一個地方很久，然後你一過去就看到並解決了，但這時候但這時候千萬不能說「這地方出錯的很明顯啊，你怎麼解不出來？」、「很明顯的，你似乎走神囉」。
或許你真的比這位工程師厲害，但或許也是因為運氣好，或是思考角度不一樣，但無論如何，在這個時候用obviously會達到負面的效果。
welcome feedback
永遠歡迎回饋。
無論你接到語氣多差的負評，只要裡面提供的feedback是有價值的，就要接受，認為自己的專案已經很好了是不可行的，永遠都還有更好的空間，必須要接納各種可以讓專案變得更好的意見。
這也跟上一段一樣，如果真的有個語氣不好的工程師指出你的錯誤，也要虛心接受，畢竟我們從這位工程師身上學到了新東西，幫助我們的技術更上一層樓，所以應該要心懷感激，當然，自己除了學到新東西之外，也記得教別人的時候，態度要好一點。
兩位大神在QA的時候著墨在上面幾項很多，而對於open source的看法卻有點不太一樣。
Josh Lockhart說open source不是一個人可以做得起來的，slim也是信任了幾位好朋友，把一些核心開發權交給他們一起維護，所以Josh說信任非常重要，如果一直巴著不放的話，slim不會像現在一樣這麼受到歡迎，運行的這麼好。
而Sebastian Bergmann剛好相反，如果給他重新選擇的話，可能不會這麼快交給其他人共同維護，到了後期，Sebastian在PHPUnit上維護的工作幾乎都是翻修code，讓可讀性變得更好，而這個工作非常無聊，佔用了非常多的時間而且無法全心全意開發新功能，PHPUnit內部的程式碼品質參差不齊。
Sebastian最後說了一句：「 Could have been better. 」
沒有留言:
張貼留言