这一年,学习的心态也发生了很多变化,小小地总结一下一些心得:
不纠结
技术层面,这一年很长一段时间内,我基本都是扮演着“哪里需要去哪里”的角色,到下半年才慢慢稳定下来,专注与相对后端、数据分析和运维。和很多人一样,一开始我也对语言这种东西很看重,有一段时间,也很喜欢看各个语言支持者之间的骂仗,不过现在已经坦然,特别赞同Coolshell那一句话:
“软件的精髓不在于你对系统底层有多了解,也不在语言层面,而是在于设计和架构,而设计和架构这种东西只能靠多想多看”(出处)
坦白说,相对于很多从高中慎重初中就开始接触计算机编程的人来说,很长一段时间,我是打心里自卑的,我初三开始接触计算机的时候,我们村拥有的PC机用手指就可以数出来,那个时候真是一个幸福快乐的小孩,没有人指导,书籍匮乏,就到二手书摊淘那些过期的计算机期刊,高考也就非常自然而然地选择了计算机相关的专业,那个时候也就是一个玩玩Linux、用Dreamweaver做做网页的小孩,进入大学,最先熟悉的语言是PHP,简单明了的语法让我印象深刻,并且最重要的是我可以用它去快速实现自己的想法,后来是Python,有一段时间都会很在意那些大家推崇的语言和技术,可能跟那份潜藏在心底的“自卑”有关,很幸运的是,这个阶段看了很多书,比如《Unix编程思想》,算是比较深入地学习了一个web框架(cakePHP),得益与那份自卑带来的对知识的渴望,订阅了很多博客,知识面得到了很大的拓展,也就不会纠结于语言和技术的问题,可以踏踏实实地去做事情。
这一年,由于性能方面的需要,用C写了一个Nginx模块,用C/Python写了一个任务分发系统(后来用Go进行了重写),在做这些工作的时候,写PHP的经验给我很大的帮助,很快地就可以完成另外一门语言的入门。
产品层面,不纠结竞争对手的节奏,不纠结竞争对手的抄袭或者干扰也是很重要的,跟随只会乱了自己的节奏,纠结也只是阻碍自己的进步,只有不纠结,坦然面对了,抓住自己的核心了,才能形成自己的节奏,一步一个脚印走下去。
只做核心的事情
对于技术型创业团队来说,采用成熟的技术方案还是自己开发,我们往往很容易陷入对这个问题的纠结。在构建我们系统的过程中,我们大量地采用开源或者其他现成的解决方案:Redis,MongoDB,AWS等等,将精力集中在最为重要的地方。我们也曾经纠结与是否构建自己的Hadoop集群,当时我和一位实习生研究了很久,尝试构建我们自己的集群,但是发现运维成本相当高,最后果断选择了AWS EMR。真的很感谢AMAZON这样一个伟大的公司,为我们创业者提供了一个伟大的平台。
技术选型要“只做核心的事情”,产品上面也是一样,最重要的是专注,最难的也是专注,我们也曾经头脑发热过,把大量的资源浪费在不应该的地方,但是没有磕碰过,也就不会知道专注的可贵。总结来说,做一件事情之前,一定要沉淀一下,不要头脑发热,可以把事情化解成一个个关键问题,解答好每一个关键问题,看看是否符合预期,是否符合大方向,再考虑做不做和怎么做。
停止抱怨,解决问题
在公司里面,对于低效的会议大家一定深恶痛绝,开会真的是一门艺术,组织得好则高效且富有成果,组织得不好不仅浪费时间且往往没有任何成果。我们也有这样一段开无效会议的时间,有讨论没结果,还好的是我们就是这样一群不安分的人,只要做的不对,就会有人站出来,提出解决方案,帮助大家改进,分享一下我们的例会经验:
- 每周都有人固定收集需求和反馈的问题,提炼问题,问题分为Q&A类,需求方案确定类,议题讨论类。
- 每周开会前提前收集内部和外部的讨论议题(比如晚上开会,则上午开始收集),议题要清楚且准确地要达到的目的。
- 开会前要提前把要讨论的问题整理成邮件发给所有参会人。
- 每次开会需要有一个主持人,会议顺序:
- Q&A问题开始:给出明确的答复。
- 需求方案确定类:给出各个方案的优势劣势,确定方案及实施方法。
- 议题讨论类:议题提出者需要阐述提出议题的目的,确立一些边界问题,最好是分解成具体的问题,再进行分问题解答。
- 会引起长时间争论或者暂时无法解决的问题则开邮件讨论。
- 总的原则是,对于Q&A,需求或者议题都好,描述一定要尽可能地清楚,讨论之后一定要给出总结,超过一定时间的问题都另开邮件讨论。
- 开完会之后主持人要把会议讨论的问题和达成的措施发邮件给所有参会人确认。
- 例会控制在一个小时内,可提前不可拖后。
这里以会议为例子,是想说明一个问题:对于存在的问题,除了抱怨,更应该想办法去解决它,很高兴能够在这样一个敏感的团队里面,在意思到开会的问题之后,大家就自觉的开始寻找方法去优化它,上面也算是我们的一点经验。所以“保持敏感”这一点我觉得很重要,当然,敏感之余,要做的是想想怎么去解决问题,而不是抱怨,抱怨是解决不了任何问题的。
———————
重读了一下,文字还是很稚嫩,希望大家见谅:)


