他从来都是一个“自作主张”的人，对于别人的“标准答案”，他会坚定不移地反驳，“为什么只能这样”？像他这种性格，从小到大都在吃“语文”的亏。小学100分制，毕业时他语文得了89分，还能算“优秀”；初中120分制，中考时他得了88分，还能及格；高中150分制，高考时他只得了87分，没错，是不及格。对于阅读理解，他始终不服气的是，为什么只能这么理解而不能那样理解，得到的回复却是：标准答案没有这些“关键字”。从此，当然就没有从此了，他在IT专业的班级以每年一挂的成绩倒数前三远离了“铁饭碗”职位并勉强只能当上一名“程序员”。但幸运地是，他进入了一个没有技术组长、没有技术经理、没有技术总监更没有什么技术规范的高科技企业，因为那里根本不存在什么标准答案，而真正的答案深深地埋藏在他的内心深处。
作为技术人员
在一个全新的没有标准答案和评分标准的环境里，他无须为谁负责，他写的每一行代码，只有一个客观的虚拟环境来验证：能否运行。在项目过程，他那蹩脚的两个月培训班技术受到了项目经理的无数次鄙视，甚至系统一度无法正式上线而不得不求助于以前经常在培训班上让我们陪他打dota的培训班老师，但远水救不了近火。因此，连续“三天三夜”的前线战斗打下了他程序员生涯的第一个里程碑，并在系统正式上线的那一刻他转过头对他的项目经理说，我是在“鄙视”中长大的。
作为技术组长
严格来说，自从他被面试进入公司的那一刻，他就是技术组长，因为他是公司的第一个“Java程序员”，源于公司拿到了第一个需要用Java作为主要开发语言的移动互联网科研项目，并在面试官口头给出offer的那一刻，他就成为了这个公司的面试官。项目初期包括他在内一共有两个半后端开发人员（外包算半个），他们负责的范围包括架构和功能的设计、开发、测试、实施、维护和一系列的运营数据统计，这种场景算是普遍的典型小项目模式。虽然是小小的科研类项目，但对于这班菜鸟来说，系统故障是家常便饭，各种不熟悉和漏洞更是“毫无破绽”。对于一个科研类项目，其实领导关心的不是系统能否正常运行，更多是钱花了没有。当然，这些都是后知后觉，也幸好是后知后觉，如果他当初知道了这个真相，我想他就没有了那股边在公司开发边跑客户现场运维的冲劲，他花费了别人数倍的“努力”为的就是让系统的正常运行时长能更长一点。一个多小时的来回路程一天跑几趟也是常有的事，无论白日黑夜或日晒雨淋，但他毫无怨言，因为他始终认为自己写的代码自己负责。
作为技术经理
“小项目不关注”也许能容忍系统88.88%的可用性，但对于一个千万级用户的系统来说，系统的高可用已经不仅仅只依赖于他的每一行代码，而是整个团队的每一行代码。他时刻让他的团队意识到他们写的每一行代码都会以每秒数万次甚至数十万次被执行的速度在奔跑。但他意识到系统能否高效和稳定地运行跟他在团队强调这些细节的次数无关，而是跟他对“整体”负责任的态度有关。他沉默和深思，静静地聆听着系统每一行代码在运行过程的各种咆哮，默默地感受着每一句代码交互所产生的情绪。聆听和感受只是第一步，他还需要去解读和理解，但他自身功力的不足让各种外在和内在的情绪纠缠不清，各种混乱的思绪一度让他无法呼吸。面对这种情况，他可以抱怨缺乏一个好团队而另寻东家，他同样可以埋怨自身能力的不足而打退堂鼓。但他并没有这么做，并且强制不让自己产生这种念头，因为他始终认为，他一直在为自己打工，而不是别人，放弃当前就是放弃自己。
作为部门经理