我爱上的最难的一次IT面试

 

我把IT面试的最爱,献给了最难那次

转眼间,开发者、架构师、咨询师,我已在这些职业中游荡了超过30年,其中包括经营自己的咨询和软件定制研发公司的九年。总觉得是时候改变一下了。 有了这个决定后,我开始寻找高度匹配我的技能、志向和个性的公司,即使不能三个同时满足,那么至少也要满足其中两项!

在做了超过30年的开发者,架构师和咨询师后——当然这其中也包括经营自己的咨询和软件定制公司的9年——我觉得是时候改变一下了。有了这个决定后,我开始寻找与我的技能,、志向和个性高度匹配的公司,即使三者不能同时满足,至少也要达到其中的两项。

在接下来的日子里,我面试了很多公司,包括Borg、生存于市场缝隙需要不停做维护的小公司、非常无聊的咨询事务所、平庸的开发车间 、毫无建树的创业公司 、离岸外包公司,以及几个极度无趣的漫画公司。

只有ThoughtWorks脱颖而出。

为什么ThoughtWorks 与众不同

ThoughtWorks是与众不同的,但在我未深入面试流程前我都不能准确地描述这种不同。越到面试后期,我就越喜欢这个过程和这家公司,最后也明白了这种不同在于他们对人的重视,这种重视远远超出了地球上那些普通水平的敏捷公司和其他所有咨询公司号称的”以人为本”。TW是这样说的,也是这样做的,并且在他们的面试过程中很好的证明了这一点。

为什么大家都认为ThoughtWorks的面试“难”

在美国,ThoughtWorks的面试的难度是数一数二的,究竟是第一还是第二,取决于你所看的是哪一份调查或者哪一篇文章。比如他们有可能来自于:

  • Business Insider
  • Forbes
  • Glassdoor.com
  • Boston.com
  • Chicago Sun-Times

其实也完全取决于你自己的看法

网上都说ThoughtWorks的面试困难,其实这有一些误导。也许她只是看起来很难,因为大多数其他公司的面试都很片面,缺乏人文关怀,且有些肤浅,甚至还有一些会让你愤怒!

对我来说,ThoughtWorks的面试不是故意“那么难”,与其他公司相比,他她只是看起来比较“难”而已,其实他只是互动比较多,让双方互相了解得更彻底:

  • 电话面试考察我们的技术知识以及推理过程
  • 比较落地的编程作业; 以你自己的风格去完成一些核心问题

其中现场面试环节还包括:

  • 一起讨论问题(考察你如何思考)
  • 限时智力测验(考察你的智力水平)
  • 与语言无关的限时编程测试(看你是否掌握一定的基础知识)
  • 一个关于道德的深入讨论(看你是否坦率,豁达,善良)
  • 两个技术/架构/设计/咨询的讨论(考察你的想象力和反馈能力)
  • 一次结对编程(考察你如何工作,以及如何与其他小伙伴一起合作)

现场面试整整持续了7个小时左右,并且所有环节都由两个面试官一起进行。说实话,我很享受,因为我的确是非常享受做测试题以及和聪明人对话,如果不是为了赶时间到机场,我是真的很不想离开。

我为什么喜欢她

我参加过的其他公司的面试,他们会预先设定一个工作岗位,然后寻找适合这个岗位的特殊技术型人才。在这个过程中,有时候他们不惜把明明是方形的桩子(人才),钉进他们预先设定的圆形的洞(岗位)。有些公司甚至自己都不知道想要招聘什么。 而TW的英明之处在于,他们真的是试图在了解我,搞清楚我到底是怎样的一个人,我到底能做些什么,而不仅仅是走过场,照本宣科地一条条过招聘要求。TW的不同之处还在于,她也想让我去了解他们,明白他们到底是谁,他们在做的是什么,以及他们为什么要这样做。

与其看面试的时长,不如看面谈的质量

其实ThoughtWorks不是唯一一家面试环节很长的公司,例如,Borg的现场面试与TW的面试一样长,但它的长没有一丁点吸引力。 由于每个讨论都是一对一的,如果遇到一个不好的面试官,就很容易影响发挥。所以随着面试的进行我对她们的印象是一直在减分!面试结束后,我已经觉得非常的疲惫和厌倦。

然而,当ThoughtWorks的现场面试结束后,虽然我也觉得累,但更多的是对于刚刚经历的那场独特面试的激动和兴奋。

在飞机上我一直在回味刚刚接触的那些人,以及那些有趣的讨论。我在憧憬这家公司可能给我带来的成长和提升技能的机会,不仅仅是专业上的,还有非专业上个人魅力的提升越想越激动。虽然是午夜航班,但我毫无睡意。

与其说面试的是工作,不如说面试的是人

在面试过程中遇到的那些人们极大地增加了我的激情, 每个人都是那么的聪明、礼貌、有趣、真诚。他们让我感到被欢迎,被需要 — 这与之前的Borg以及其他公司形成了鲜明的对比。与我经历的其他面试相比,TW的面试更高效。

回到家后,TW对我又进行了一次面试,这次是两个高管对我的视频面试,目的是确保我就是他们想要的那类人,并向我确认是否对他们的岗位依然感兴趣。

当然!从过去到现在对他们我是一直充满着激情和兴趣的!  几天后,我接受了他们的offer。

现在,我已是一个ThoughtWorker。

虽然才入职短短几个月,但到目前为止TW和我的预期完全一致,甚至他们比我预想得还要活泼有趣、乐于助人。

是的,面试是困难的,但也是值得的。如今我已顺利通关,你要不要也来试一试?

译者语

ThoughtWorks是我一直喜欢的公司,在翻译此文时,我完全能体会作者的那份心情,让我不由自主地想起那次懵懂的校招经历,不管最终是否和TW在一起,都感谢她带给我的影响和成长。TW一直是我的初恋,还没有分手的初恋。
Share

十年

初识

第一次听说ThoughtWorks是在2004年平安夜的朋友聚会,正在和L公司西安办公室的小林聊天。远远地,好友Lims带着一位高个儿、着西装的男士走过来。小林碰了碰我,“这人是ThoughtWorks的”,“什么公司?”我问,小林又大声重复了一遍。“你好,我是郭晓,ThoughtWorks的,总部在芝加哥,我们正在西安筹建中国分公司”。Lims告诉我L公司和ThoughtWorks在合作一个软件园数字园区的项目。他跟郭晓提到我在一家大型ERP软件公司的西北区负责人力资源管理,在西安认识的人多,以后有要帮忙的,就直接联系我。

终于知道这个公司名字怎么写了,百度上的第一条便是Martin Fowler的介绍,他的著作以及他参与撰写的敏捷宣言,论坛中为数不多的几个贴子和回复中充满了对这位技术大牛的仰慕。但对ThoughtWorks的介绍却很少,中文网页上只有寥寥几条。完全没想到,这家公司跟完全没有IT技术背景的我能有什么缘分。那以后,郭晓打过几次电话,如何面试销售人员,哪儿的饭馆招待人不错云云。

要么沉下去,要么学会游泳

ThoughtWorks人才甄选中对文化适应性和价值观很看重,尤其当他们计划招聘中国区第一位人力资源管理人员的时候。该角色事关公司文化建设和价值观传播,这两项自然成了面试评估中丝毫不能妥协的维度。面试了若干应聘者、猎头推荐和我自己推荐的候选人,仍未找到合适人选。对ThoughtWorks的文化和扁平式管理,我是有很多好奇心的,于是试探性地向郭晓表达了我对这个职位的兴趣。郭晓已经认识我多时,除了英文,其他两项都没有担心。最终,他们决定在价值观、人力资源管理经验和英文技能三个主要维度中,降低对英文的要求,向我发出邀请。于是几乎一句英文都不会说的我就在2005年9月13日加入TW,开始承担People Lead(人力资源总监)角色,成了中国区本地招聘的第七位员工。

被Sid Pinney(时任中国区总经理)和郭晓(时任中国区副总)面试时的窘境一辈子也忘不掉。郭晓在尝试着逼我挤出了两三句英文后,还是不得不当了翻译。期间没有聊太多HR相关话题,就记得Sid听到我在第一家公司八年的工作经历后说,我保证你在ThoughtWorks会超过八年。Sid对我的印象是,尽管不太会说英文,但一点也不象大多数中国人那么shy,于是他愉快地对我的加入表示欢迎。

Sid说,以后他会回美国,我的工作主要向郭晓汇报,所以不用太担心英文。Too young too naive,入职第一天就面临阅读和回复英文邮件的尴尬。Sid还经常直接找我谈话,实在聊不下去了,就上Yahoo IM打字,有时两个人坐在办公桌对面却打字沟通的样子真心滑稽。英文写作以及口语这两项的快速通关过程相关惨烈。最初的几个月里,每天晚上一两点钟入睡都是常态。把一本商务用语背的烂熟,动画片《Monster Inc》和《Shrek》也看了无数遍。

入职第一天,刚设置好电脑,Sid和郭晓就迫不及待地把手上的HR工作扔过来,一份在其他公司看起来是机密的全员薪资表径直交给我处理,出人意料的没有考查期。Lims说,外企就是这样,招你进来做这个职位,就默认你是胜任的。

有在第一家公司时行政、财务、运营、信息化管理等各岗位的锻炼,以及随后第二家公司的HR工作经验积累,使得我在ThoughtWorks的People Lead工作能很快进入角色。入职第二周,开始准备校园招聘宣传和面试。第一次宣讲,相当忐忑,都不敢在最后环节设计Q&A,担心给出错误的答案,抹黑TW形象。

大多数情况下,办公室里只有负责行政的陈慧和我两个人,加上刚入职暂时没项目的几位程序员,我们一起做招聘。郭晓偶尔回到办公室,解答一些问题,工作几乎没人指导。随后,Sid又在我的职责里加入了优化行政和财务流程、提升效率的工作。那时候,除了写代码,我什么都做。没有培训、没人辅导、工作方向不清晰、克服各种困难的这段经历,常常让我想起这么一句话:“要么选择沉下去淹死,要么选择学会游泳”

招聘难度随着公司的发展而不断增大,品牌不够响亮,又地处西安,工作遇到了瓶颈,不时面临着招不来人就没办法接项目的僵局。直到两位具有猎头背景的招聘专员入职,招聘速度才逐渐跟上了业务的发展。但随之而来的,人力资源管理难度也直线上升。没有现成套路,使用其他国家分公司的方法有水土不服的风险,以前任职公司的方法更不能照搬。只能一边做,一边摸索,在为中国区建立各种体系的同时,小心翼翼守护着我理解的ThoughtWorks文化和价值观。偏偏官方的文字描述只有三个词:“Attitude, Aptitude, Integrity”。加之TW组织结构扁平,官民平等,发挥空间较大,反而常常使得我在处理一些事情的原则上有些犯难。

只有多学习,多理解体会。在现场与项目上的同事们交流学习我们中国区既有的文化,在公司与来中国支援的外国同事沟通探讨他国TW管理的方法。两位老大也创造机会促进我跟其他国家的同事接触。2006年,参加了在芝加哥的Away Day;2007年,在英国担当了三个月的HR Manager角色。通过这一系列的交流学习,我加深了对TW多年来沉淀下来的文化的理解和运用。

转岗到底难不难

担任People Lead近三年时,中国区成员已过百,办公地也迁址到北京国华大厦。ThoughtWorks中国区很年轻,资深成员少,我有幸被选入到第一期全球领导力培养计划(Global Leadership Development Program)中,美国人Matt Simons是我的导师,他在TW任职多年,先后担任过业务分析师,印度区总经理,全球人力资源总监等职务 。Matt非常认真的辅导我,通过定期沟通,帮我完成优势分析、360度反馈、领导力发展计划,还联系他国资深成员提供指导,我受益匪浅。Matt建议,要想在ThoughtWorks有更大的发展空间,同时促进自己有更大的能力提升,就必须进入主营业务中,深入到客户业务往来的一线,所以可以尝试转岗Business Analyst(业务分析师),然后Project Manager(项目经理),再后Client Principal(客户管理总监)。这,完全出乎我的意料。有几位LD Program学员已经是CP了,而我要再发展几年才可能到CP,公司这么培养我,付出也太多了吧,况且我能不能胜任?Matt却不以为然,你要是成功做了CP,再加上已有的运营类角色经验,对于公司的业务发展会有更大的助益。随后我也跟郭晓谈了这个计划,他更是举双手赞成。在这个事业发展的岔路口,两位老大就这样帮我做了一个重大的选择。

转BA就要直面其带来的挑战、压力。放弃熟悉的People Lead角色,软件开发是白丁,从零学起,难度可想而知。 心里还有个小算盘,招聘新人接替People Lead职位,我万一失败也回不去原来的职位。中断了HR的工作经验积累,再找个好工作也不容易了…… 各种风险一闪而过。但这已经不是第一次,在前任职公司时就有两次换岗位后从零做起的经历。也许命中注定,闪念之间,这次也没有太多犹豫。

内部系统Jigsaw开发是我做BA的第一个项目,从Shadow资深BA亢江妹开始。再一次进入大部分私人时间都用来读书、学习的苦修模式。最焦虑的时候,完全不能集中精力。遂向老大申请休假来寻求暂时的逃避。老大回复,“休假与否,问题依然在那,不如直面”。我也想过撑不住了就离开ThoughtWorks,还为此杜撰了一个悲情的场景,已经卸任回美国的Sid出现在我面前,我叹了口气说:“对不起Sid,我做不到八年了,辜负你的期望了“。

放弃就等于承认自己是loser,心有不甘,决定再咬牙坚持一段时间。两个月后,原来的PM,BA都被安排到了别的项目,随即接过了BA和PM的全部工作。此时的我已经学会梳理需求,写用户故事,画mockup和管理发布计划,算是跃过了第一道门坎。八个月后,我加入到一个真正的客户项目(国际派遣业务相关软件)中做BA,后来也同时担任PM,应付高标准严要求的美国客户,在频繁的沟通、谈判中,逐步地有了对此项工作更专业、更明确的把握和掌控。

打第二份工

中国区成员过百后,信息被充分的上传下达开始变得困难。有人提议成立一个组织,作为桥梁,一方面听取广大ThoughtWorker的意见与建议,一方面做为一个额外的渠道,分享和解读来自老大以及TW Global的重要信息。

于是3C(China Consultant Council)诞生了,由当时各项目团队里主动性强,对TW文化、价值观高度认同的十几位成员组成。大家轮流负责,收集运营中遇到的问题、区分优先级、组织讨论、汇集意见和建议,并研究解决方案。通过这样的形式,我们这些人被纳入了中国区的管理体系中,毫无怨言地接受了8小时billable之外的第二份工。

中国区老大郭晓开始思考领导梯队的建设,3C则提供了一个绝好的实验田。于是他悄悄行动起来,每月布置2~3篇Harvard Business Review,McKinsey Insignt英文商业文章的阅读任务,让之前只关注技术和项目的这群人开始学习企业管理。成员当中有徐昊和熊节,两位据传看书快于吃书的大侠。而且熊节还不断写博客、发表文章,对读过的商业文章撰写评论。这种来自同伴的压力,使得原本不爱读书的我也养成了阅读习惯。加之要在项目上应对挑剔的客户,多数晚上和周末都在学习、工作。想着在这样一个斗志昂扬、蓬勃向上的公司里,能持续得到业务的锤炼和能力的提升,多花点儿的业余时间也值啦。也许,痛并快乐着吧!

把走出舒适区当成习惯

在舒适区待的时间长了,生产力会下降,因为没有了因期限和期望造成的不安,可能会心安理得,自然就没有成长了。必须迈开步子,走出去。

grow comfort zone

继西安有了两位兼职Office Principal(办公室负责人)几个月以后,北京公司的OP选择了肖然和我,当时我俩都在北京公司天字一号项目中忙的不可开交,本身工作已经饱和。但这些年来,待在拓展区、挑战焦虑区已经养成一种职业习惯。所以担子来了,也就接着了。2011年底任职,最初的10个月里,项目少,运营复杂度低,又有经验丰富的老大主导,没觉得有什么困难。随着业务结构复杂度增加,规模变大,老大的工作重心又转向全球,肖然和我在运营分公司的重担才真正显现出来。由于此时我俩都被客户项目缠身,遂商议由肖然多花精力在客户项目,而我则更多负责公司运营。

此前每年绩效评估时收集的反馈中总少不了“工作效率很高”这一条。但自从真正承担OP职责后,发现时间管理变低能了。不但工作量大,而且棘手的事情接踵而来。肖然离开公司以后(8个月后又重新加入),不但得把他负责的项目管理工作接过来,还要管理整个北京公司,日子更加艰难。硬把负责本地客户交付业务的施韵涛拉入伙,而他也早已分身乏术。我个人的技能不足、时间又严重短缺、再缺乏得力的人分担,把我推到焦虑区的火焰上反复炙烤。同时,自己负责的项目上,成员间沟通不畅、客户抱怨交付进度…… 公司里,项目人员安排出现了冲突,面试官意见不一致,坚持自我原则时把同事说哭了,有人要求特殊照顾,有人找我谈离职,TechOps团队被物业刁难…… 常常被各种难题压得喘不过气儿来。每天勉强控制着情绪,徘徊在崩溃的边缘。以至于有两三次跟老大谈话时,刚就一件事情被追问了几句,眼泪就夺眶而出。屋漏偏逢连阴雨,慢性胃炎、颈椎病也接连来袭。医生诊了诊脉,一边写药方一边说:“工作压力很大吧?吃药不解决根本问题,心情调节好,病才能好。”

2012年岁末的一天,从早到晚经历了十三件棘手的事情。晚8点,结束最后一个电话会议时,已经不想再说一句话。默默将那十三件事情写下来,放在电脑的桌面,起名叫”What a shitty day!”。安慰自己,下次再遇到困难时就看看这篇日记,只要能比这一天强一点点,就应该开心。当然了,万一真的比这天还糟,那就再写一篇把它替换掉吧。

不记得在焦虑区待了多久,大概几个月之后吧,不再每天工作到很晚,救火的事情也逐渐减少。转眼看看身边,有了一群能干的小伙伴,他们能自如地做好团队建设,处理好跟客户的关系,更多地为公司的发展做切身的考虑并认真的履行职责。终于又逐步回到了拓展区,开始有纪律地安排自己的时间。睡眠充足,精神抖擞。摸爬滚打中技能提升自不必说,关键是悟出了怎样从这类困境中走出来,如何从被动解决问题,到腾出脑力和精力去主导方向、规划。秘诀就是:不要一个人战斗,要培养出很多跟你一样强,甚至比你还强的同伴。很多时候,即使自己快被压垮了,仍然要鼓足精神去鼓励、推动其他人走出舒适区。

我辅导的Leader如果正在遭遇跟我当年一样精疲力尽的境遇,我就会分享这样的经验:越忙越累的时候越要培养接班人,这才是你从出困境的真正希望;想在技术或领导力上攀登新的高峰,也要培养接班人,这样放手时才够负责任。要识别多个培养对象,因为不是所有人最终都愿意承受拓展区和焦虑区带来的压力和挫折。不幸的是,强势风格也会产生负作用,有几位较资深的同事由于承受不了我的期望、鼓励、压力,甚至是逼迫和责备而选择了离开ThoughtWorks。

自信    勇气    坚韧

Sheryl Sandberg的《Lean In》对我最大的帮助有两个:假装自信,直到变得自信;指望每个人都能够喜欢你,将会阻碍到你的脚步。

自信分为两个方面,一方面来源于“Knowledge, Experience和Exposure”。想象你要与客户的十几位资深高管开会讲解方案,如果你从来没经历过这个场面,自然容易焦虑、不自信,见多识广是让自己提升底气和自信的不二法门。另一方面,谦逊也会导致不自信。在一个跨国公司里,你会发现与其他国家的同事相比,中国人过度的谦逊会妨碍你展示优势,同时也会错过你本可以得到的机会。所以,在一个机会来临的时候,即使当时的能力不足,只要是拼命跳起来就能摘到的果子,就要去争取,争取到了就要苦练,出色地完成任务。而在ThoughtWorks这样一个结构扁平、发展空间大、快速成长的组织里,最不缺的就是机会,就看你够不够主动。

2013年5月,在公司的一次新兴市场领导力培养计划(EELD)见面会议中,每个人用五分钟分享过去半年以来在领导力发展的历程。我选了三个关键词:Confidence, Courage, Resilience(自信、勇气、坚韧),没有什么比这三个词更能描述我过去半年的心路历程。

自信问题容易克服,而勇气和坚韧却是知易行难。承担领导角色,在拥有影响力的同时,也伴随着损耗人品的事情发生。进行艰难的绩效改进谈话,辞退绩效改进失败的伙伴,推动别人走出舒适区,做出让部分人不开心的决定。也有在沟通工作任务时,失去耐心爆出责骂之言。感知到自己开始变得不被很多同事喜欢,我的心情低落到谷底。在信任的人面前哭泣发泄了几次后,我开始隐藏自己,把艰难的事情都推给韵涛和郭晓。2013年3月,郭晓升任全球CEO,中国区有了胡凯、张松两位新的总经理,我转向Head of China Operations的角色,负责中国区运营效率,顺理成章的由一线躲到幕后。几位领导在面对艰难和阻力时做决策、沟通、推动执力的勇气时时刺激着我,但我依旧低调行事,小心翼翼不敢发表不同意见,晃晃悠悠在这个角色上找不到方向。为了让自己显得还有价值,把更多精力转向客户关系管理,接过了一个大客户的CP职责,绕了好大的弯子,给我四年前制定的领导力发展计划划了个句号。

2014年9月的一天,在美国拜访客户,跟在客户现场工作的于晓强聊天,他问我:“你不像以前敢做敢说了,为什么不做回自己?” 我惊讶地盯着他,不知该说什么。晓强是那种很有主意、从不妥协于权威的典型技术大牛,曾经坚定地以为强哥也属于讨厌我的那群人中的一员。这次意外的谈话移走了我心里的最后一块阴霾。是啊,我需要拿出勇气,恢复斗志,做正确的事,干嘛过于在意是否被喜欢。

Head of Operations角色只在北美和印度两个区域有先例,而各国家市场和业务重点各有差别,几乎无法参考。好处是发挥空间非常大,坏处是你可能不知道应该做什么,优先级是什么,什么才是这个角色的价值。但这一次没有再进入焦虑区,因为舒适区已经足够大,所有的挑战都只落在拓展区。

2005~2015。

整整十年,停留不是因为拒绝变化,而是因为在这里每天都不同。

整整十年,伴随着中国区从区区几名成员,到如今600多人的豪华团队,我们同心协力、栉风沐雨,披荆斩棘,一路走来。

十年里,开心和顺利的日子真的很多,也把挫折赐予的成长和拼搏赢得的成果作为回忆深深的藏在心底。

谨以此文来感谢ThoughtWorks带给我精彩的十年。

十年后的今天再会!TW不老,我亦年轻。

 

Share

技术人员如何写一本书?

我在过去的几年中,写了4本书。有传统意义上的两本实体书:《JavaScript核心概念及实践》《轻量级Web应用开发》,还有两本电子书《3周3页面》《函数式编程乐趣》。当然对我而言,主职工作是软件开发,写作是个副业。

在写作的过程中,有一些有趣的心得。

  • 写作本身是一个很好的学习过程(至少是一个驱动你学习的动力)
  • 写书非常枯燥,特别是校对的时候
  • 写作不会让你变得富有,但是有时候会让你开心(不总是)

写文章 vs 写书

写博客/文章和写书还是有很大差别的,一个明显的差异是写文章会比较随意,而且应该尽量保持精简。一篇文章提供一些信息即可,应该尽量远离细节(如果写一篇教程,则另当别论)。而写书则应该尽可能的深入细节,尽可能可以让读者依书自修。

投入与回报

首先要明白的一点是,不要指望用写书来赚钱,至少前4本是这样的。粗略的算一下:我的第一本书卖了3000册,每卖一本我可以得到4元RMB,一共就是12,000元RMB。而这本书我断断续续写了三年。那是很多个周末,很多个假期,很多个夜晚的付出换来的,如果真正要计算投入产出比的话(纯粹金钱上),这显然是一个毫不合算的事情。

作为一个参考,IBM developerWorks的投稿,千字200元,一般写5,000字以内,也就是800元RMB左右。而要写一篇这样的文章,我只需要一天(当然需要数周/数月的积累)。12,000元RMB需要写15篇文章,如果每周写一篇,不到4个月就可以写完,而且写文章比写书容易多了,毕竟篇幅比较短小,易于校对。而且对于大部分开发者来说,固定在一个主题上的难度要比15个独立的主题简单的多,因为无需特别深入。

所以根据经验,要抱着公益的情怀来写书。也就是说为了让知识更好的分享,让你学习到的先进科学技术来帮助更多的开发者,提高他们的开发效率,让他们可以在周末多休息一天。而至于翻译技术书籍,那基本上就是免费的了,完全是一个公益活动(耗时数月,斟酌字句,推敲表达方式,但是价格极为低廉:千字60元RMB),所以下次见了技术书籍的译者,就多少给他捐点吧,他们才是在为人民服务

知识的诅咒

“知识的诅咒”是指人们在获得了某种知识之后,就无法想象没有这种知识的情况了。这种现象随处可见,比如一个你到了一个从未去过的陌生城市,遇到以为当地人,然后向他问路。当地人觉得已经说的很清楚了,但是你还是不知道该怎么走。另一个例子是:假设你不认识泰文,然后你打开任何一本泰文写的小说,你只能依稀感觉到这是一种文字,除此之外你并不能从中获取任何的信息。但是当你学习了一段时间泰文之后,再来看这本小说,之前的那种感受就再也没有了。

curse-resized

写书的时候,你首先需要具备某种知识。但是写书的目的是将这些知识传递给那些不具备此知识的人,而根据“知识的诅咒”,你又无法确知那些初学者会遇到哪些问题!解决这个问题的方法就是找初学者来试读。而且为了保险起见,还应该找尽可能多的人来试读。

写作方式

一种方式是自下而上的,写一些独立的文章,最后发现可以串起来,然后形成一本书,另一种方式是自上而下,但是又会逐步调整。根据经验,不论是写一篇简单的博客,还是写一本书,都需要按照自上而下的方式。随心所欲的写下去,基本上都收不住,而且整个文章支离破碎,貌似有很多内容,但是不成章法,读者也无法轻松的获取知识。

先列出大的章节,然后逐步细化,但是未必是按照顺序来写。先编写自己最熟悉的部分,然后逐步完善。例子的选取需要精妙而恰当,最好有图例来说明。

配图制作

一般而言,我在书中会使用两种图:流程图和一些截屏。截屏通常使用Mac OSX自身的功能就已经足够,而流程图我会采用一些额外的工具如:

  • graphviz
  • keynote/sketch

cgi

用Graphviz画图的好处就是可以将图像代码一样放入版本库来管理。

除此之外,我还学习了一些设计软件的基本用法,事实上只需要用一些简单的元素就可以做出非常专业的配图:

  • 字形/字体(大小,粗细的变化)
  • 颜色(基本的配色理论就可以做出很舒服的配色)
  • 层次(尺寸,位置,颜色的深浅)
  • 阴影

mock-server-resized

代码格式

书中实例需要很多代码来说明,如果是制作电子书的话,可以使用Markdown预处理器自带的功能来高亮。另外如果需要RTF格式,可以使用这些工具:

  • highlight工具
  • intelij中的插件copy on steriod

这里有一篇博客来说明如何将你的代码带着格式拷贝到剪贴板中,拷贝之后,就可以将这些内容粘贴到Word或者Keynote中了。

jest.dontMock('../components/headline.jsx');

describe('Headline', function() {
  var React = require('react/addons');
  var Headline = require('../components/headline.jsx');
  var TestUtils = React.addons.TestUtils;

  it('#render', function() {
    var text = "this is a title";
    var headline = TestUtils.renderIntoDocument(<Headline title={text} />);
    var title = TestUtils.findRenderedDOMComponentWithTag(headline, 'h4');
    expect(headline.getDOMNode()).toBeDefined();
    expect(headline.getDOMNode().textContent).toEqual(text);
  });
});

一些潜在的坑

在写作的过程中,会有一些潜在的坑。这些所谓的坑是新人可能无法想到的。相对于言之无物,不知如何下笔,最痛苦的其实在于平淡。大部分时候,你可能很容易就能写出开头,但是很难坚持到最后。即使好不容易写完了第一版,后续的重读和修改,会让你苦不堪言。

内容写好之后,样式是下一个重要的问题,好的内容需要有与之匹配的排版。在中国,作者不但要负责内容,还要负责一些排版的事情。这一点非常奇葩,但是又是实情。这也是我更推荐电子版的原因(排版更加美观,选择更加多样,而且一旦有问题可以更容易的修改)。

另外一个问题是错别字检查!检查错别字对于作者来说,是一件非常困难的实情。而对于读者来说,则是一件很容易的事情。这跟知识的诅咒的道理一样。

typo

发布方式

实体书

传统的出版方式有一些明显的问题,这些问题已经和现代的知识传递方式产生了冲突:

  1. 时滞性(新技术的更新速度远远超过审批,印刷等流程的时间)
  2. 排版(如何低成本做到语法高亮,或者彩图)
  3. 更新频率(当技术更新之后,如何更新,是传统纸质书无法解决的问题)

传统的出版方式有点像传统的软件开发,一本书从开始写作到最终出版,要经过很多环节。忽略掉写作过程,从交稿到出版会经历很多次审核和校对,可能会历时4-8个月,着这个过程中,很多东西都可能发生了变化,一个典型的例子是《用AngularJS开发下一代Web应用》,原版为英文版,翻译成中文版再到出版之后,书中的很大一部分内容已经过时。读者拿到书之后,会发现书中的内容已经和当前的版本/文档不匹配了。这种现状随着技术的更新速度和频率还会再加剧。

第二点是排版。我听说国内有些出版社已经开始接受Markdown作为稿件的格式,但是大部分还采用Word或者WPS等格式,这样排版就变成了一个大问题。以我自己为例,我的原稿用Markdown写,但是写了几章之后不得不切换到Microsoft word上,而我自己的Mac OSX下的排版到编辑的Windows下就会变样,而且还会涉及字符集,字体,Word版本等等问题的影响,最后导致印刷出来和原始稿件出入很大。

最后一点是更新频率,如果发现了错别字或者错误的地方(即使之前检查过多次,仍然会有漏网之鱼),由于实体书的特殊性,一般需要等到再次印刷才能解决。这意味着先购买的读者会承担一些风险,更新后的版本又如何让读者看到呢?总不能又买一本吧。

但是这些问题都可以通过电子书来很好的解决。首先,电子书可以随时更新,最低限度的降低时滞性。排版上来说,作者可以使用Markdown来编写,而展现则可以应用一些预定义的模板来完成。最后,更新频率完全可以控制,对读者来说风险更低,因为电子版书籍的可以很容易的追踪交易记录,从而得到免费的更新过的版本。

电子书

目前已经有很多的渠道可以发布电子书,比如gitbook知笔墨。这些应用的出现,大大降低了发布书籍的成本,我的《函数式编程乐趣》,用了3天就完成了草稿,而发布只需要数秒。

另外一个问题是书籍的价格和作者的收入。一本书定价50元RMB,出版社给作者的版税是8%,也就是说,没卖出一本,作者可以得到4元,如果你的书非常畅销,这还是一个不错的价格。但是可能90%的书籍都不会是畅销书(就好比每个班级都会有优等生,但是他们仅占全班人数的10%一样)。这对作者是一种浪费:你需要耗时数月甚至数年来写一本书,然后市场的反馈又非常慢(毕竟你无法出版一本未完成的书)。

我在selfstore.io上有两本电子书:《3周3页面》《函数式编程乐趣》《3周3页面》定价为16元,每卖出一本,扣除掉交易费之后,我可以得到14.7元。

对我来说,这样可以得到更多的回报,对于读者则可以更加快速的得到更新,而且由于有预览版和一系列的其他信息,还可以在很大程度上降低读者的风险(更不用说快递费,等待时间等问题)。我在gitbook上的统计显示,《3周3页面》已经被累计下载了28,861次,实际的读者也将近5,000。而且没有任何的审核流程,也没有排版的时间浪费,我只需要关注内容即可。

Share

IT小小鸟生存指南-学习起步篇

经常跟公司的年轻人聊天(说起来好伤悲),他们大多在充满激情的同时表达出自己对于学习的迷茫。面对快速发展的技术被迷晕了双眼,不知道学什么,也不知掉怎么学,不知道从哪开始,也不知道学到何时为止。前两天也在知乎上回答了一个类似的问题,想想应该把自己的一些经历和问题以及对于这些问题自己的思考梳理一下,分享出来。

小小鸟们需要面对的第一个问题往往都是不知道该学什么?面对扑面而来的各种技术,框架,术语,各种三个字母或是四个字母的天书一样的单词,感觉一下就被淹没在浩瀚的技术海洋中。看着大牛们的各种口吐莲花,对于各种技术信手拈来,运用自如,羡慕之余也不禁畅想着自己何时才有这么一天。

为了实现心中的目标,很多人捧起了各种神书,什么设计模式,什么算法导论,什么编译原理;而有些人则搞起了各种新潮的技术,什么Angular、ReactJS、Go、Node、Swift、Spark,他们都以为自己已经拿到了通往成功的钥匙,不过看了一阵发现,该听不懂的还是听不懂,书看的进展缓慢,狗熊掰棒子一样忘的比记得还快,技术淘汰的速度超过了自己学习的速度。怎么破?我给的建议其实很简单,就是:

1. 工作用什么学什么;2. 先上手后学习;3. 无目标不学习,学到够用就停止

1. 工作用什么学什么

为什么建议从工作入手?因为这样可以最大化的借势,达到事半功倍的学习效果。曾经有只小小鸟做着一个C#的工作,但总觉得没有搞Ruby啥的高大上,用着IDE,总觉得没有用Emacs&Vim高大上,所以就白天硬着头皮用IDE搞C#,晚上下班后风风火火用Emacs搞Ruby。一年过去,累的跟狗一样,结果工作也没有干好,自己想学的东西因为没有使用场景也总感觉停于表面。后来痛定思痛,决定集中火力专心学学C#,将自己的学习与工作的方向调整到一致(而不是像之前总是忘两个方向使力,结果都相互抵消掉了)。最后发现反而事半功倍,工作也出成绩了,对于编程语言本身的理解也深度了许多。再去看Ruby或是其他更新的语言,反而轻松了很多,对,这个小小鸟就是我。

说起来简单,但是很多人还是会很纠结,生怕站错了队伍,选错了方向,选错了语言,选错了技术,输在了起跑线,就像我当年一样。走过来我才发现,其实作为当时的自己,无论学什么的效果应该都是差不多的,所谓殊途同归,触类旁通。而对于现在的自己,我已经有能力做出对于自己正确的选择,反而不会纠结。所以做不出选择只能代表自己不够强大,也代表此时的选择可能对自己的意义也没有那么大。念念不忘必有回响,学什么都是有用的,但一个重要的前提是学习的驱动力是兴趣而不是简单的作为一个挣钱的工具,引用罗辑思维里说过的一句话:“没有兴趣你将一事无成”。所以,我的建议是:

结论:工作用什么,学什么,以点带面,顺势而为,将自己学的东西与工作契合,利用所有时间学习。

2. 先上手后学习

很多计算机知识都非常抽象难于理解,什么模式、内聚、解耦、架构、分层、并发、异步、静态、动态、过程、对象、函数、逻辑,还包括各种各样的语言和原则。这些抽象的概念是很难简单的通过“学习”可以完全理解的,因为它们都是从问题中来的,都是人们为了解决某一个问题想出来的解决方案。但是就像猴子定律中的猴子们一样,我们已经慢慢忘了最开始不能去拿香蕉的原因,已经忘了问题,而将解决方案视为圣典,而后来的猴子们(小小鸟)在完全脱离了问题的前提下,单单去学习这些解决方案自然会觉得很抽象也很痛苦。

所以,作为勇敢的小小鸟,应该多问几个为什么(参考5why分析法),甚至勇敢的去摘一次那只香蕉,就当自私一点为了自己,知其然也要知其所以然。记住,那些“约定俗成”、“就应该这么干”、“大家都是这么做的”、“我们一直都是这么做的”都是狗屎,除非能说出问题给出原因,否则任何脱离问题给出的解决方案都是耍流氓。

结论:直接上手实践,遇到问题,先尝试自己解决,再带着问题去学习,这样的学习才会更有效率,理解也才会更深刻。

3. 学到何时为止?

大牛们经常会指点我们学什么,但是一般不会告诉我们学到何时为止。而面对一本本厚厚的书,和外面各种新技术新框架的诱惑,我们不禁自问,这得学到什么时候啊。我们知道在设计上有种说法叫过度设计,那如何避免过度学习呢?过度设计是指去设计那些现在用不到的功能或结构,而过度学习则是指去学习那些现在掌握运用不了的知识。

TDD(测试驱动开发)是一种可以一定程度上避免过度设计的实践,追求刚刚好的实现和设计,无测试不开发,无味道不重构。而对于学习,为了避免过度学习,追求刚刚好的学习,可不可以引用TDD的思路,无目标不学习,一旦目标实现,这次学习就停止了,这个时候可以对这段时间的学习进行归纳整理,然后再制定下一个目标,由此持续的学习。

测试驱动开发:写一个测试 => 实现让测试通过 => 重构优化 (不断重复这个过程形成环路)
目标驱动学习:定一个目标 => 学习让目标实现 => 整理总结 (不断重复这个过程形成环路)

结论:无目标不学习,学到够用就停止

最后

其实大牛们也是从小小鸟成长来的,自然也曾面对过同样的问题。但他们凭借对于技术的兴趣和热爱,禁得起诱惑,耐得住寂寞,守得住自我,日积月累自然就成就了自己。所以地球是圆的,技术也是圆的,无论那个方向,都会走到你想要的那个点,只要你在不停地一直往前走,正所谓可以十日不将军,不可一日不拱卒。

准备的很多内容其实还有很多问题没有展开,比如学习的深度与广度如何协调提高;如何面对层出不穷忽上忽下的新技术;时间如何管理规划;知识如何整理沉淀;要不要做计划,怎么做计划;如何走向大牛之路。一篇肯定写不完了,所以准备来个系列,慢慢写吧,欲速则不达,第一篇就算是学习起步篇,希望能有所帮助,未完待续……

Share

学习的逻辑 2: 职业半山腰

galaxy

<<学习的逻辑: 知识经济学>>中介绍了基础的逻辑. 本文是其姊妹篇, 进一步从不同角度来阐述.

我该学什么? 这是一个错误的问题

这个问题可以有很多出发点. 今天讨论基于的假设是对工作方向的迷惘, 即不知道自己下一步努力的重点是什么, 但又不想时光虚度, 总觉得该学点什么, 又不知从何学起.

想学习是好的, 但考虑下面这种场景. 你走进领导的办公室说: “我要加薪, 因为我参加了两个培训, 看了三本书”. 你觉得领导会答应吗?

再考虑第二种场景. 你走进领导的办公室说: “我要加薪, 因为我搞定了两个项目, 解决了三个问题”.

显然第二个场景比第一个更可能一点. 因此我们应该关注的, 是我可以有什么样的贡献, 什么样的产出, 而不是我应该学习哪些知识. 你的身价是由你表现出来的知识决定的, 不是你掌握的知识决定的. 就算我们的目标是学习, 让自己更强大, 一条更具可操作性的途径是以终为始, 先设定自己想做成什么事, 再反推需要什么样的知识.

另外一个类似的思考角度是, 你希望别人怎么介绍你.

  • 一种是这位是xxx, 他这一生看了很多书, 学富五车.
  • 一种是这位是xxx, 他是 yyy 产品的设计者 / zzz 书的作者…

你更希望是哪一种?

你对世界的认识和世界对你的认识都只能通过你可观测的行为来进行. 你的老板, 你的同事, 他们不可能知道你都看了啥想了啥学到了啥, 他们只能看到你说了啥做了啥. 换句话说, 你是个黑盒, 外在的行为定义了你. 如果你所知所学不能反映在外在行为上,则你的内部状态不会对世界产生可观测的影响. 也就是说, 如果你学了某些知识, 但行为没有任何变化, 那跟没学是一样的. 从这一点上,你的行动, 你的产出才是你知识和智慧的反映,所谓知行合一.

所以我该学什么, 是一个不恰当的问题. 更合适的问题是: 我该做什么, 我该对外界产生什么样的影响?

这里的讨论是在工作的上下文中, 不涉及哲学和宗教, 人生意义等.

有时忙得要死, 有时无所事事? 其实无关时间

有没有过几件事找过来, 你不知道该接哪个的情景, 最后只好只要时间排的过来就都接了, 结果搞的自己过载? 而有时忙完手头的事, 发现没什么可做的, 只好无所事事上上网?

有人会求诸于时间管理. 但其实原因不在于你的时间管理技巧, 而在于你根本就没有明确的目标, 无论是短期的还是长期的, 尤其是长期的. 没有目标, 时间管理就没有依据.

没有目标, 你就排不出优先级. 当一堆任务涌过来的时候, 你就不知道哪个对你重要, 哪个不重要, 哪个必须做, 哪个可以不做. 当你有多个项目可以去做的时候, 你不知道该挑哪一个, 该拒绝哪一个. 没事的时候, 你也不知道该看啥学啥.

有个项目可以练习你的产品设计能力, 另外一个可以出国练几个月英语, 还有一个当下最火热也是公司未来方向的大数据项目, 而你只能选一个, 你会选哪个? 你业余时间打算看本书, todo list 里面有三本, 但时间只够你看一本, 你如何决定该看哪一本?

比如你觉得要去学iOS开发, 是时代潮流, 可为什么不去学习智能硬件呢? 你觉得要去学数据结构和算法, 往基础知识层面走, 可为什么不去学习操作系统, 数据库原理呢?

不是从目标分解下来的学习任务, 更像是随机的碰运气, 恰好碰对的可能性很小.

一旦确立了真正的目标, 这些问题就不再是问题, 就不会时忙时闲, 也不会选择恐惧, 因为你知道忙时拒绝那些对目标没什么帮助的工作以削峰, 而闲时主动补充对目标有帮助的知识而填谷; 最契合目标的就去做, 无关紧要的就拒绝.

不善交际, 没有话题? 其实无关性格

周围总是有资深的人, 但你跟他们在一起的时候, 想要聊些什么, 又不知从何聊起. 有人会求诸于社交技巧. 但其实根本的原因还在于你没有明确的目标. 没有目标, 也就没有深入思考, 因此也就没有问题. 跟周围同事, 业界大牛聊的时候, 仅仅是泛泛而谈, 止于人云亦云, 网上遍地都能找到的一些讨论. 并且你也不会主动挑起话题, 因为你没问题嘛.

一旦有了目标, 在你向目标前进的时候, 一定会碰到很多具体的, 实际的问题. 此时你会主动去找资源, 找人聊, 也会聊的比较深入, 比较有成效. 你会突然变得积极主动, 谈笑风生起来.

同时你会发现, 几乎每个人身上, 你都可以学到你关心的知识. 所谓当学生准备好时, 老师自然会出现.

什么都会, 但又都不突出, 通才? 其实是学霸综合症

李敖有段时间一三五学法语, 二四六学德语, 别人问他哪一门强, 他说要看是星期几问. 与此类似, 你要问我有什么特长, 擅长什么, 那要看我当时是在哪个项目. 做过很多项目, 什么都知道点, 但依然没什么擅长, 当时在做啥, 就相对擅长啥. 但这并不能称之为通才, 仅仅是善于快速入门而已.

究其原因, 还是没有目标, 只知低头干活, 不知抬头看路, 转来转去都离原点不远. 最慢的步伐是徘徊.

以终为始. 反馈是学习的唯一途径. 输入只是娱乐, 输出才是学习.

Share