ThoughtWorks 工作小结

刚从 ThoughtWorks 北京离职。小结一下这几个月的工作与生活。

我是在宣讲会上看到 ThoughtWorks 的。做了几道奇奇怪怪的逻辑题以及两道编程作业，然后有了一个面试机会。面试过程也比较顺利，就是把自己的编程作业 review 一下，然后根据新的需求改一下代码，再顺便重构一下。面试的时候，面试官觉得都没啥可重构的了，我也这么想。。。然后就 HR 面，然后有了一个 offer。

还有一个去哪儿的 offer，package 还高点。但感觉搬砖很没意思，最后还是去了 ThoughtWorks。高中同学 sei 哥内推我，还拿到一个杭州的不错的创业公司酷家乐（做在线装修、家居渲染）的 offer，但我不想去杭州。。。。。。（后来 sei 哥一直问我北京的雾霾好不好吸。。。。。。）

TWU

6 月份刚弄完毕业设计答辩，就参加了 #56 期 TWU（ThoughtWorks University）。这是一个在印度的为期 5 个星期的体验课程。一方面会讲编程技巧、敏捷实践，另一方面会关注于经济和社会上的不平等现象。总体而言，ThoughtWorks 的创始人 Roy Singham 是个很有情怀的的共产主义者，这家公司也在赚钱以保持商业运转的同时投入了大量的精力去让世界更美好。

TWU 全英文授课，学生（trainer）和老师（trainee）都是 ThoughtWorks 全球各个办公室的员工。

整个过程有大量的游戏和互动，体验相当不错。

第一天互相认识，通过做游戏来记住彼此的名字（左二是我）

小伙伴们都比较热心。比如左一的 David，看到我的笔记上写了个 team kadle 写了一个问号，还告诉我这个是 cuddle。相对而言，我英文听力相当靠谱（我会说我都成了大家都听不懂的时候，就会来找的翻译么），但和 native speaker 比起来，还是有很多可以提高的地方！

很多中国人对印度口音很不适应，而欧美人听起来压力不大。除了多听听去适应之外，我觉得这个差异是永远会存在的，毕竟两个半桶水的集合交集不到半桶水，在文化背景和学习环境大不相同的情况下互相理解到对方的点是有难度的。

外，学口语的一个有趣的方式就是模仿印度口音。一方面可以提高你对印度口音的辨识力，另一方面你也能注意到自己发音的一些问题。

一味吐槽人家口音带有咖喱味，是不能提高自己的水平的。（更何况人家咖喱味的英语能表达出自己的意思，而你没有咖喱味的英语可能只能“I'm fine”）

一个有趣的地方是我在一次和自己 tutor 交流的时候，不小心教了大家“一个大西瓜，一刀切两半”的太极“歌”。于是课余大家都在学太极。。。

yue 在教大家太极，我在录像

TWU 还有一些奇奇怪怪背景的人。比如最后一天要走了，在酒店轰趴（我不懂为啥外国人觉得在酒店住一天就放松了。。。。。。），发现 Team A1 的 Gesa 很奇特。她是一个海德堡大学国际概念学（global concepts）博士，在台北交换了好几年，中文特别溜。

Gesa 的中文水平岂止是高

来过好几次大陆的样子，还去了几次新疆。然后趁走之前，我人生第一次采访了他人（用的英文）。

采访 Gesa

TWU 之后，回学校收拾了一下自己的东西，然后就去北京入职了。

Beijing

到了北京，入职啥的都很顺利。最开始在公司提供的公寓（在万国城 moma）住了两个星期，待遇太高。（啥时候能自己租得起这样的房子，就算小有成就了 Orz）后来自己住到了望京华彩边上的一个小区。离上班地方近。

去了 * 项目组，不久换到了 * 组。这小一年，都在望京 Soho。

ThoughtWorks 的新员工，一般也不直接往项目上放，但几年不知为何，有一些毕业生直接上了项目。铺面而来的各种新的东西，比如我原来会一点 Java（找完工作，觉得需要 Java，看了基本 Java 书），但框架相关的都没用过，而项目上使用的是 Spring Boot 来做微服务。整个过程还是比较蛋疼，只不过我这个人总是忘记不快乐的那些部分，所以。。。我现在也说不出来那感觉。

就说说我觉得 ThoughtWorks 最让我很喜欢的点吧。

Code Review

Code Review 是每天下班前的例行公事。大佬们也会讲代码，但这个环节更多地关注在毕业生上。所以，整个过程是：打开你的 IntelliJ IDEA，查看今天（或最近几天）的代码提交，先介绍一下上下文，说一下自己做的事情，再一行行过代码。大佬们的眼睛时刻盯着你的代码，指出你哪里写得有问题。。。。。。

我在的项目组，大概有 10 个 Dev，除了三个毕业生基本都是 Senior，阵容比较强大。大家提出来的反馈都很有建设性。我最喜欢的一个反馈是：你的函数命名应该反映你要实现的东西，而不是具体怎么实现的。

守破离

Shuhari (Kanji: 守破離 Hiragana: しゅはり) is a Japanese martial art concept, and describes the stages of learning to mastery. It is sometimes applied to other disciplines, such as Go.

Shuhari roughly translates to "to keep, to fall, to break away".

• shu (守) "protect", "obey"—traditional wisdom—learning fundamentals, techniques, heuristics, proverbs
• ha (破) "detach", "digress"—breaking with tradition—detachment from the illusions of self
• ri (離) "leave", "separate"—transcendence—there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical

守破离（Shuhari）这个概念是在 TWU 上第一次听到。很震撼。

我很喜欢张五常的《吾意独怜才》，里面有一篇就是《学习要从假设大师是对入手》。和守破离不谋而合。我还激动得翻译了这篇文章的几句话给我的 mentor。

简单说，守破离的“守”是一个初学者应有的态度。如果你是要学习它，就不要上来就做杠精。除了嘴巴上爽，精神上傲娇了一把，对自己没啥好处（没有增益/gain）。（再往上一层说，守破离是在告诫你不同学习阶段该设置什么样的关注点。dq 有一句很有意思的话可以概括，叫“练球不打球，打球不练球”。硬广：优越性 vs 一致性 - 简书）

这个论述也不错：建立框架包括接受偏见

比如 TDD（Test Driven Development），我觉得也是有它的问题的。但初学的时候应当关注它做的好的方面：比如 TDD 可以保护自己的代码；可以让一门严谨的语言给你一种类似脚本语言通过 repl 调代码的畅快感；还有助于你从使用者的角度看问题，写出更好的 API；还有助于分解问题，明确这个函数需要达成的几个层次的效果。

等你 TDD 熟练了，就可以根据实际情况控制 TDD 的粒度。这时候“离”也不迟。

有一个概念叫 NFL：no free lunch theorem，就是“天下没有免费的午餐”。用 Alan Perlis 的话说，是：

Lisp programmers know the value of everything but the cost of nothing.

事物都有两面性，TDD 也有它的问题，比如写起来麻烦。项目太小（从代码量和开发人员数量的角度）或者逻辑太简单的时候收益不明显。而且掌握 TDD 需要很多练习，经验不足的人使用起来会觉得很麻烦（顺手了之后你会觉得很。。。顺手）。

从这个角度，在 ThoughtWorks 可以有时间专门练习这些编程实践，真的是特别棒。

就是这样，感谢 ThoughtWorks。明天搬家去五道口了。

Bye, ThoughtWorks.