文章的名字我想了很久，备选项有“我再不推荐 Redux”，“Redux 为什么令我头疼”，“Redux 进化启示录”等等。通过这一系列名字我想你大概能猜到我接下来想聊的问题是什么，但这个问题放眼望去不是 Redux 独有，而是在做技术决策时经常会遇到的，即使对于非前端背景的开发者也同样成立。最后决定用一个带有开放式标题也许能够引起更多的共鸣。

javascript flux redux architecture

我们在这里不会谈社交媒体上的影响力，这需要动用种类繁多的运营和技术手段。本篇文章里要解决的问题非常简单：如何才能让他人跟随你的建议行动。

principle

“Talk is cheap, show me the code”

principle

“To err is human”

principle leadership

请允许我在这里以一种低姿态来讨论流程。流程当然可以被聊的高级且深刻，就像在《创新者的窘境》一书中谈论的那样，把流程与公司的文化还有价值，以及创新能力联系在一起。但我们不如来优先解决眼下日常工作中的流程问题。

principle leadership

上篇请访问这里做一个能对标阿里云的前端APM工具（上）

performance

我一直在考虑如何让这个公众号「像话」的运转起来，也许把最近接触到有价值的媒体内容分享出来是值得尝试做的一件事，于是就有了这个系列。

book

相比于技术路线而言，管理技巧难以被量化。更严重的问题在于，对于 leader 自己而言似乎也没有动力去给领导力做进一步提升，因为一方面大部分公司对于对于团队以及 leader 的绩效考核，永远是以业务指标为导向的（在 Thoughtworks 并不是）；另一方在公司框架的束缚和工作节奏的惯性带动下，团队工作表现也不太可能出现大的波动，似乎只要不犯错就是万事大吉。退一步说，没有胡萝卜仅仅用大棒来鞭策团队也是可以接受的，只要向上管理得当，没有人会关心你的管理工作是如何执行的。

principle leadership

APM 全称是 Application Performance Monitor，即性能监控

performance

在成为 Tech Leader 之后，有一件事困恼我相当长一段时间：我应该多大程度上干涉团队成员的工作？

principle leadership