前言

我自己觉得这篇跟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研究研究。