您现在的位置:首页
--> 乱象,印迹
技术领导要不要写代码?这是一个问题。
我刚工作的时候就听说,程序员(那时候还没有“码农”的说法)是吃青春饭的,到30岁就熬不了夜写不动代码了,所以要尽早转管理岗。相应的,如果你走上管理路线成了技术领导,自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多,技术能力增长很快,但总感觉有点别扭。那感觉就像,你能把车开得又快又熟练,最终只是为了能按时到达机场赶上飞机。然后,你就再也不用开车了。
不过无论如何,赶上飞机看来是更高级的选择,为了它,放弃苦心修炼的车技也可以接受罢。
对程序员来说,学好“英语”而不是“专业英语”是非常重要的。只学好专业英语,看得了技术文档,但那一大堆专业术语和概念可能会像陨石一样,没来由地坠落下来,只能生吞活剥地硬背。如果学好英语,你才会有融会贯通的感觉,知道那些术语和概念原来是从地里长出来的,底下连着根茎。
我刚刚工作的时候,面试官曾经跟我说:好好干两年,可以迅速从程序员成长为工程师。当时我觉得太诧异了,从很多招聘启示来看,“程序员”不就等于“工程师”吗,只是“工程师”更好听一些而已。等我工作久了,才知道“程序员”和“工程师”真的是不一样的——程序员只写程序,工程师写能在现实世界中创造价值的程序。
可惜,很多软件开发人员未必清楚两者的差别,甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验,谈谈程序员和工程师的差别。 第一,工程师不写黑箱程序。 “程序=数据结构+算法”,这个著名的公式大家都知道,不幸的是,它不适合描述工程领域或者现实世界的程序。有很多程序,数据结构和算法都写得很棒,功能足够强大,系统足够复杂,但是——它很难调试,一跑起来就无法停止,而且谁也不知道程序现在到底在干什么,里面发生了什么。
对程序员来说,学好“英语”而不是“专业英语”是非常重要的。只学好专业英语,看得了技术文档,但那一大堆专业术语和概念可能会像陨石一样,没来由地坠落下来,只能生吞活剥地硬背。如果学好英语,你才会有融会贯通的感觉,知道那些术语和概念原来是从地里长出来的,底下连着根茎。
• 简历的重点是抓人
我有时会帮朋友们做些工作引荐,所以经常见到一种可惜的情况:有些人明明素质很好、专业很过硬、经验很丰富,偏偏简历做得太过敷衍潦草,一眼看去泯然众人、毫无亮点,甚至让希望引荐的我感到汗颜。看来,有必要认真谈谈简历这件事情。
就我所见,把原有系统“推倒重来”的喜好不只程序员有,使用者更有。拿我几年前的那份工作来说,刚入职老大们就来跟我讨论系统重做的打算:需要多少人,多少钱,多长时间,能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛:速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头,来个干脆的彻底解决。
人的一生,当然有很多的时间去自己摸索和探究,做出自己的选择;其他人的教诲,很多时候并不会干涉选择,反而会让人少走弯路,更快捷抵达自己的目标。下面,我列了自己印象深刻的教诲(或者说“建议”),既是对各位的感谢,也希望通过分享让更多人受益。
• 软件开发的硬约束
在超市结帐的时候,收银员都会给我们打一张小票。有时候同样的商品我们会买两三件,打印在小票上面,有时候只有1行记录,数量是3,但也有时候有3行记录,数量都是1。这个现象很有意思,也引起了我的兴趣。据我观察,后一种情况明显更多。分明是前一种做法更节省纸张,为什么更少采用呢? 我曾经设想,是因为收银的机器性能太差,内存很少,只能维护简单的数组结构,不能维护集合,也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现,这个说法站不住脚——现代的收银机性能足够很好了,甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢?就在我百思不得其解之际,一个偶然的机会解开了我的疑惑。
2011年前我写过一篇文章,讲到自己发现的两大趋势:第一是人与人之间的沟通越来越少地采用“同步”(电话)的方式,而更多采用“异步”(邮件、短信等,当时还没有微信);第二是有越来越多的人“实名上网”,不一定用自己的真名,但是希望在网络上建立通行的“身份”。当时我也好奇:随着时代的发展,我们的生活还会发生哪些变化? 后来我才逐渐认识到,这些变化都只是表象,实质是两个字:互联。
抱着了解的心态,我第一次来到了张江,参加了一次创新院的计委会例会(计划委员会?)。后来我才知道,这个会议定期召开,对内部和外部的项目进行点评,参会者包括固定成员和报名参加的创新院员工,大家都可以畅所欲言。如果说非要有什么等级的话,大概就是把最后的点评机会留给创新院的院长大年(陈大年),他的点评没有咄咄逼人的气势,而多是以温和的方式托出自己的思考,大多数时候都让大家信服。相比小公司的会议,设施更好,准备更充分,也更严格;相比大公司的会议,少了仪式感和官僚气,多了活力。结果,2010年3月我加入了创新院。
“丰田生产方式”给我印象最深的要求是,员工必须同时对工作和工艺负责。自从福特发明了“流水线”之后,工人似乎成了机器的附庸,只是完成机器暂时无法完成的工作。生产的终极形态,就是把一切工作变成简单重复劳动,用机器执行。所以,工人的工作也应该简单机械,比如每天按照生产线的运作,以一定节奏拧紧某个螺丝,就是一种典型。而在丰田生产方式下,工人不但要完成简单机械的本职工作,还必须对工艺负责,也就是理解该工作的意义,思考并不断思考改进自己的工作过程——他们既有这个义务,也有这个权力。结果,整条生产线就好像具备了不断改进的活力,而不再由少数专职的“专家”负责优化(实际上专家也负不了那么多责任)。
程序员的发展,长期以来都是大家关心的问题。通常程序员的发展有两大方向,深度和广度。深度发展,就是精深自己的本事,研习新潮尖端的技术乃至学会“屠龙之术”,以绝招打遍天下;广度发展,就是拓宽自己的技能种类,比如学会更多的语言,以完成更多种类的任务。除去这两大方向,其它能选的发展方向似乎就只有“改行”了。
上周五到周日,72小时内连续参加了北大、武大两场校园招聘会,笔试面试了一百多位同学。见到很多很不错的同学,在学校里就积累了相当的见识和经验,也见到很多很可惜的同学,因为这样那样的问题,没有走完招聘流程。下面我结合公司的校园招聘安排,给各位找工作的同学一点建议。
上周在深圳见朋友,聊天时仍然把“正则表达式”和我联系在一起,这真让人惭愧,因为我已经很久不写正则表达式了,甚至有些生疏。估计是Jeffrey Fridel的《精通正则表达式》写得太好,身为译者的我也沾了不少光,收获不少虚名。为避免误解,撇去虚名,有必要专门写写我和正则表达式的故事。
最近因为工作的缘故,接触了TokuMX,尝试下来感觉不错,值得介绍给大家。
事情的起因是要解决MongoDB的问题。系统中需要保存程序输出的运行信息,这类信息比程序语言的log更高级,但又不如业务操作日志高级,是某些时候发现问题的关键证据,所以必须保存。因为格式不太规范,又需要方便检索,所以文档型NoSQL的MongoDB是比较好的选择。
TokuMX的一大创新在于,它打破了一条长久存在的关于数据库的规则:要保证好的写入性能,索引的工作集应当能够放在内存里。标准答案是这样的:如果索引的工作集比内存要大,写入就需要执行I/O,I/O就会成为限制因素,性能就会下降。所以,要么让索引小到能全部放进内存,要么提供一种索引写入模式,避免工作集过大,比如MongoDB所采用的,内存中只为最近插入的数据保存索引。
领导必须更懂技术吗?这是个问题。做了领导以后,因为工作的关系,许多人都不那么熟悉基础的技术了,结果自己心里没底,更怕遇到问题时在下属面前丢脸。所以,有些人选择了双管齐下——既不放弃领导的工作,又不放弃原有的技能,结果疲惫不堪。还有人干脆选择不当领导了,因为有手艺,才有安全感。
不少朋友都提到,手下的员工离职往往是让人非常头痛的事情。这大概是管理岗位经常需要面对的一种麻烦,这个问题也困扰过我。为了帮助仍然被困扰的各位同仁,下面提供我的经验给大家参考。要说明的是,因为我和朋友们几乎都在IT行业,“员工离职”的大部分情况也就直接体现为“程序员离职”,所以我主要讲的还是应对程序员离职的经验,其它行业的朋友可以自行参考。
说起翻译,许多人都有兴趣。但真正能动手去尝试的人,只占其中的一小半;能熬过尝试阶段的煎熬,真正入门的人,更是少之又少。这种现象给不少人造成了错觉,认为翻译是件看起来容易做起来难的事情。但是根据我自己的经历和其它做译友的反馈,这话其实只说对了一半,翻译“做起来”并没有那么难。翻译之所以给人“做起来难”的感觉,很大程度上是难在入门阶段,难在一些基本问题没有解决。所以,这篇文章来谈谈大家关心的两个基本问题:第一,翻译是怎样的工作;第二,直译更好还是意译更好。
读了本文如果有人觉得这还不满足,希望知道程序员有了产品意识还有什么别的好处?且让我讲个故事:我有个做金融的朋友,从小参加过不少信息奥赛培训,业余也自己写过不少小工具。有一天他问我:“你说程序员的工作有那么高级吗?不就是写写代码?你看我也会不少编程语言,也写过不少程序,所以程序员没什么了不起的吧。”我回答:“那么,你有没有写过给别人用的程序呢?”他想了一会儿说:“好吧,你赢了。”
近3天十大热文
- [66] Oracle MTS模式下 进程地址与会话信
- [66] Go Reflect 性能
- [65] 如何拿下简短的域名
- [59] android 开发入门
- [59] 图书馆的世界纪录
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则
赞助商广告