前言

我自己覺得這篇跟leadership比較沒有關係，感覺蠻適合給正在尋找下階段目標（但不一定要換工作）的developer來看。特別是已經在同家公司待一陣子，對於工作上的事物已經得心應手的人，可以藉機思考一下你還可以帶來哪些貢獻。

演講總結

演講核心主旨就是：You can do beyond developer。

講者利用歷史帶入敏捷開發宣言（Agile Manifesto）進而介紹整個演講的主題：舊時代的工程師是specialist，但現在的工程師可以做很多事beyond developer。因為我們同時扮演著許多角色：

1. 工程師
2. 帶領團隊的開發者
3. 打造產品的開發者
4. 平台的開發者
5. 部門裡的開發者
6. 組織裡的開發者

以下是對於這些角色的簡單敘述。

作為工程師，你學習語言、學習使用函式庫（library）、關注工具發展、學習工具鏈（toolchain）、學習貢獻給community。

作為團隊leader，你學習了解流程、定義成員的角色、與大家合作（無論是team內還是team外）、保持團隊的健康程度。為了保持團隊的健康程度，作為一個leader你的核心責任就是團隊永續性（sustainability），要做到這點就必須要考慮到大家的身心狀況，利用同理心去理解每個人的想法。

作為產品開發者，你必須要去理解產品目標、更加了解這個領域、了解你的利益關係人（stakeholder），想辦法利用這些才能貢獻在這個產品上。

這裡講者問了個非常有趣的小問題：我們在開發寫log的時候，要怎麼判斷是要記成warning還是error？講者的回答是：如果你不介意早上四點起床被叫起來看這個error message的話。（我後來發現還真的有個stack overflow的答案是這個XD）他想表達的是，作為產品開發者，你必須要看到更大的scope，因為你的粗心大易或考慮不慎是可能會造成別人的麻煩，所以你要以更寬廣的視角看你做的產品而不只是關注在你做的任務上。

作為平台上的開發者（註一），你會從impact別人變成influence別人（註二）。由此你必須要知道在上線之前的的流程（post-production），要思考怎麼減少產品從製作到產品上線中間的交付時間（lead time），而不單只是考慮部屬流程（deployment）。此外你也要想到為了運行成本，包含on-call、包含修問題的成本。再來就是要考慮到自動化的價值，因為不是所有自動化的價值，只該自動化重複性高且無趣的事情。

作為部門裡的開發者，你必須要知道有知道更多的背景知識，以便做出對於team來說最好的決策。再者就是你也需要勇於分享知識給其他的team，這很有可能可以幫助到別的team，也能幫助到自己。

作為一個組織裡的開發者，你可以先問問自己這個問題：我對於在擁有某個核心價值的這個組織裡工作感到自豪嗎？你必須要去理解與認同組織的核心價值，並嘗試去體現他。就像是會聽到Spotify的員工自豪在Spotify工作並為世界帶來價值。再來就是你必須在乎公司的名聲，因為公司跟你其實是互利共生的生態，你做的事會影響到公司，而公司做的也會影響到你。另外一點就是嘗試對外分享知識。而作為這樣子的角色，你所有對外的言詞，也都將成為公司對外的宣傳。

講了很多內容，但總而言之講者想表達的就是，身為developer你其實可以做很多事情beyond developer。而且如果你的目標是要走的遠，那就必須要大家齊心協力一起向前邁進，自己一個人是不夠的。

If you want to go fast, go alone.
If you want to go far, go together.

註一：這個平台指的是你的產品是一個平台，有點像是PaaS（Platform as a Service）的意思。
註二：Impact是指你做的事情後果會直接強制的影響到別人，而 influence指的是潛移默化間接的影響到或改變別人（見解釋）

個人心得

自己覺得整篇真的講的蠻多的東西，有蠻多學習的點，特別是小故事的地方有些讓人印象深刻。不過我自己覺得整個演講有點冗長（對我來說啦），也比較難抓到想表達的重點XD。特別是主旨部分，用了歷史去帶入本文核心概念，但因為太長所以自己有點lost XD。另一方面也因為講的很精簡，所以很多地方我其實沒有很get到講者想講的點，就變成我要自己腦補。在分門別類的部份，我自己覺得像product跟platform其實分的就不太好，我自己是沒有感受很深這兩個差異在哪，因為platform那邊講的點我覺得product其實就都有提到了，抽象化來說我覺得兩者基本上是一樣的。

以下分享幾個我看到喜歡或特別有感觸的點：

1. 我第一次聽到有敏捷開發宣言，我覺得蠻酷的，因為這個宣言強調的還是以人為本，工具或流程其實都是輔助而已。自己是不太熟悉Agile的流程，但我覺得這核心價值蠻不錯的。
2. 在講leader的部份講到leader最大的責任是團隊的永續發展性，這部份真的是認同到不行。我們老闆曾經問過我說我覺得我的team是不是健康的，那時候就有想過這個問題，原本是想大家都能開開心心的工作就好，但這樣是不夠的，還必須要能持續長久，也要能因應變化才行（見上篇文Bus factor）。在這裡偷偷推薦Simon sinek的無限賽局（Infinite game），書裡寫道的想法跟此處不謀而合。我自己覺得自己在這點上受益的是，為什麼今天身為leader的我離開我這家公司可以這麼的無痛，某部分就是我從一開始就想著要栽培有能力的人才並且權力下放，平時也累積了許多我做事跟流程的文檔，自始自終都在想著sustainability，也就是今天為什麼我可以好好離開的原因之一（當然也可能是因為我太不重要了，所以有沒有我根本沒差哈哈XD）。
3. 在打造產品那部分講了logging的例子，我覺得真的是超級中肯的，常常大家在開發的時候都不會去想你做這些事情會影響到其他人，導致我們的錯誤常常需要他人來承擔，這裡的他人可以是你的PM可以是operators也可以是team裡面的其他成員。多為別人想一點，多為未來想一點，真的可以幫助別人人生過的開心一點。
4. 另外在產品部分講了很多點，我覺得這也是真的都是蠻重要的。有些人會覺得說這不是應該是PM要知道的嗎，為什麼我要參與這一部分？如果我可以做的話要這些PM幹嘛。我不能說有這樣的想法是錯的，因為專業分工的目的就是為了讓事情做起來有效率些。但我覺得這牽扯到你對自己的期望是什麼，如果你想要打造好的產品，即使你是工程師也必須思考這些問題，因為對產品跟用戶了解越深，提供的產品也能更好，不然我們工程師就只是一群寫扣的機器人而已。
5. 最後一點是關於他提出的問題：我對於在擁有某個核心價值的這個組織裡工作感到自豪嗎？我幾個月來一直都在想這個問題，也與老闆討論很多次。先不論我自己對公司的答案是什麼，但我是深信這個會影響到公司的聲譽，也完全會影響到我們自己招人。雖然現實是很多人來求職只是為了錢或比較好的生活，但我相信有好的工程聲望的公司對工程師來說是個很大的加分。或許對公司成長營運來說不是priority，但對我來說倒是個蠻重要的選公司的考量。

這位講者Dan North似乎是Behaviour Driven Development（BDD）的提倡者，之前在寫Ruby的時候有看到RSpec這個東西大概有看了一下，有興趣的讀者可以自己看講者的blog研究研究。