CTO到底应不应该写代码？听听硅谷大神们怎么说 - 全文

　　医疗社区丁香园的 CTO 冯大辉离职了，炸出了科技行业里的一个大问题：CTO到底应不应该写代码？

　　具体来说，CTO 在公司里是干嘛的？他/她到底写不写代码？该不该做代码评审（code review），亲力亲为给程序员做出榜样？还是把握一下大方向，设计架构，管管程序员，提供一些培训？抑或应该把首席市场官以及首席吐槽老东家官的岗位一并兼了？

　　在国内，大大小小的程序员们就这个问题已经吵成一团；那我们不妨去看看硅谷。带着这些问题，我们问了一圈硅谷大小科技公司的 CTO、VP Engineering、技术合伙人，以及其他各种高级技术管理职称上的朋友。

　　硅谷 CTO 写不写代码？

　　我们发现在硅谷，技术类公司比纯互联网产品公司多得多。大部分 CTO 不但会写代码，代码也是他们日常最重要的工作内容。

　　Movidius 是一家研发低功耗视觉处理芯片的硅谷科技公司，现在已经扩张到了400多人的规模。Movidius的 CTO David Moloney 在爱尔兰都柏林工作，他负责管理一支超过 120 人的技术团队，因此也设有一个 “CTO 小组”，每天花 10-15 分钟听取小组成员的报告并作出指示。他常用的沟通工具是 Slack。

　　尽管如此，David 仍然很享受亲力亲为的工作风格，也是公司的技术迭代的主要功臣。他告诉PingWest品玩，他的日常工作主要包括设计算法、写专利声明以及帮助解决成员提出的技术问题。

　　我们按照项目和任务分成小组工作，我本人经常写 Octave（Matlab）、C/C++ 来开发算法，日常使用 GCC 和 Visual Studio（两种编程工具）。我们使用 GitHub 来管理所有的代码。

　　除此之外，David 还会亲自撰写很多的专利声明，而非将其交给下属以及其他法律顾问。

　　

　　David Meloney　　其实不止David，采访中我们发现，在硅谷，撸袖子上阵写代码对于 CTO/技术合伙人/高级技术管理人员来说简直是家常便饭，几乎不分公司技术团队人数多寡。

　　一家由机器人 SLAM（定位、识别和移动技术）公司的联合创始人匿名接受了采访。他告诉我，因为是技术公司没有设立 CTO 的岗位，自己和另外一个创始人每天大约有 8 个小时在写代码，剩下 4 个小时做管理和沟通工作。

　　写代码是每天工作主要部分，语言包括 Python、Java、C++、C 等。

　　这家公司的技术团队目前有 8 个人，一半在开发算法，另外一半做开放系统。

　　看完小公司，让我们看看大公司是怎么搞的。一位前微软员工告诉我，“印象很深的是在微软，一个高级总监管理多于 300 个技术人员，还在坚持对核心部件进行 code review，时不时自己写代码，代码质量还很不错。”

　　微软现在不设 CTO 职位，每个主要业务单独设立部门，由资深的技术负责人担任SVP——这些大多拥有十年以上的微软工作经验。

　　Oculus VR 是世界上最知名的 VR 技术公司之一，在被 Facebook 收购后增长迅速，员工总数从去年的数百人增长到今年的逾千人，其中技术人员比例很高，但该公司的大神级 CTO John Carmack 仍是一副不写代码不舒服的样子。他讨厌管理，由其讨厌开会，曾经在 Twitter 上说：

　　没有什么比“取消： ”的邮件标题让我笑得更开心了。

　　

　　一位知情者告诉我，Carmack 超级不喜欢别人打扰他。他早年用过一些很奇怪的工具来提高自己的工作效率，比如工作的时候开始用 CD 机放音乐，但凡有任何中断（上厕所、收发邮件、被人闯进办公室）就暂停，然后记录一天下来暂停了多少次。著名游戏开发者 Richard Garriott 曾这样评价 John Carmack 在代码上的水平和造诣：

　　这个人啊，他的大脑分成两个部分，一块存储 Oculus 的所有代码，另一块存储他创立的那个火箭公司的所有技术——而且跟内存一样，他随时能调取出任何一家公司、下属项目里面的任何一个代码细节。他真是让我很没自信……

　　

　　John Carmack

　　硅谷CTO怎么看待不写代码这件事？

　　那家机器人技术公司的联合创始人向我表示，如果技术人员不多，比方说 10-50 名的话，CTO 不写代码是一件挺不可思议的事，“与一般技术人员不同，他们只负责一小部分，我们需要了解系统的每一部分。”

　　但是在那些拥有50名以上技术人员的中型甚至大型公司里，情况会根据公司而变化。

　　一个普遍的观点是，CTO 应该根据公司需要转变职能，甚至偶尔身兼多职。Peloton Technology 的首席网络架构师 Tony Li 认为，当公司需要扩张，那么 CTO 得设计好系统架构；如果公司需要一个技术传教者（比如在融资、招人或公关的时候），那么 CTO 也得是一个好的演讲者……

　　当然，如果公司还是需要好程序员，那 CTO 照样还得写代码。总的来说，CTO 应该撸袖子上阵的心态还是被大部分创立于 21 世纪的美国科技公司所接受。

　　Movidius 的 David Moloney 1985 年开始工作，曾在多家半导体业界知名公司担任工程师、主任设计师、技术总监等职位。他认为CTO 的确不用写代码就可以管理，有什么事情交给团队成员也行——尽管他强调那不是他的风格。

　　如果我这样做了，会感觉很不舒服。我认为作为 CTO，首先应该是一个技术问题上的破冰者。

　　集客式营销公司 HubSpot 总部位于马萨诸塞州，已于早年上市，现在员工人数也超过了500人。其 CTO Dharmesh Shah 2014 年曾经回答过“CTO 应不应该写代码”的问题。他认为 CTO 应该写代码，就像销售 VP 得去销售一样。

　　

　　Dharmesh Shah

　　除非那种已经很庞大的公司，在创业公司里，每个人都要亲力亲为。我从来不相信纯粹的管理职位。

　　不写代码的 CTO 就失职了吗？

　　或者：写代码应该成为 CTO 的核心竞争力吗？

　　这才是见仁见智的地方。大多数采访对象都会告诉我，他们认为 CTO 不写代码可以理解。比如有些经验丰富，任职于大公司的 CTO，确实应该花更多精力把握大方向，设计架构、分配工作、优化整体性能、确保系统的稳定和安全。具体的执行和实现，由下手来完成。

　　比如，有些大的公司不设 CTO 而是设工程副总裁 VP Engineering，但也能见到 VP Engineering 转岗 CTO（比如 Facebook），或者两个职位共存的情况。曾在多家公司担任 CTO 的 Vijay Venkatesh 认为，VP Engineering 更多负责现有产品，而 CTO 担负的是设计未来项目，让它与现有产品在技术上能够更好融合的责任。

　　在这样的公司里，CTO 应该有着比普通工程师更全面的技能和更大局观的视野。不可否认的是，CTO 的编程能力越强大，越能跑好把公司规划、业务需求通过技术落实的这个流程。编程能力是应该是让 CTO 庞大的技能树更好地生根发芽的养分，而不是树根本身。

　　CTO 应该会写代码吗？应该。写代码是核心工作内容吗？不应该是。用代码写得好不好评价 CTO 合适吗？不合适。

　　——这不是采访对象们说的，是我总结的。

　　事实上，无论在硅谷还是中国，不少小型创业公司的早期技术员工都面临这样的状况：移动端和 web 开发都得懂，平时还得维护自己的邮件/日历系统，公司网断了又要负责检修和给运营商打电话，拉条电话线都得亲自出马。这哪里是首席技术官，分明就是首席全栈苦力嘛。

　　而当公司发展起来之后，中美的情况却发生了变化。

　　硅谷这些 CTO（除了 Carmack 大神），要么一人扛起整个公司的技术运转，要么在投入巨大精力亲力亲为。他们会这么做的原因，也在最一开始提到过：技术对于这些公司的重要性，比技术对于中国大部分创业公司的重要性，都高得多；而CTO们需要考虑的技术之外的因素，也少得多。

　　而在中国，CTO 却往往没有办法这么去做了。中国科技圈太崇拜靠运营、靠打仗和修建城池获得成功的神话。微信、淘宝、微博，哪一个不是这样成功的呢？相比之前，技术的重要性太低，太不被外界重视。技术不会决定生死，产品做得差不多就行，靠推广甚至靠博眼球才能成功。这也是为什么在硅谷，创业公司的 CTO 们往往撸起袖子写代码，而在中国这样的环境里，一名合格甚至优秀的创业公司 CTO 却得去考虑代码以外其他很多事，他们的价值，也就不能仅仅用代码来衡量。

　　所以，对于，一个没有技术缺陷，擅长运营具备网红人格，还为其带来了巨大的影响力的 CTO，却用单纯用“写不写代码”来评价功过，并不太合适。特别是当我听说，整件事情幕后真相的讨论点已经从“匿名指责CTO 不写代码”过渡到“团队拒不兑现 CTO 期权”的时候，我就更明白了：

　　指责 CTO 不写代码不过是一盆泼出去用来转移视线的脏水，背后藏的，却是希望借着“代码之争”来达到其否定 CTO 价值、继而撕毁契约目的的厚脸皮和小算盘。