上班编码，加班编码，回到家倒头就睡。别人给结婚同事包红包，他们却从来不用，因为很可能明天就跳槽不在同一家公司了。结婚前衣服都是妈给买，结婚后媳妇包办，自己从没买过衣服，因为不知道该去哪儿买什么牌子。但是他依旧被广大程序员羡慕着，因为……哥们儿成功脱单了呀。

    记我那些可怕的职业经历.

    我刚刚工作的时候，面试官曾经跟我说：好好干两年，可以迅速从程序员成长为工程师。当时我觉得太诧异了，从很多招聘启示来看，“程序员”不就等于“工程师”吗，只是“工程师”更好听一些而已。等我工作久了，才知道“程序员”和“工程师”真的是不一样的——程序员只写程序，工程师写能在现实世界中创造价值的程序。 可惜，很多软件开发人员未必清楚两者的差别，甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验，谈谈程序员和工程师的差别。 第一，工程师不写黑箱程序。 “程序=数据结构+算法”，这个著名的公式大家都知道，不幸的是，它不适合描述工程领域或者现实世界的程序。有很多程序，数据结构和算法都写得很棒，功能足够强大，系统足够复杂，但是——它很难调试，一跑起来就无法停止，而且谁也不知道程序现在到底在干什么，里面发生了什么。

    考虑一种新产品的过程，最初是想了解软件应该做什么，那么，就从定义问题的解决方案开始。这里有个假定，问题本身被正确地定下来了，但它经常不是这样的。这些需求经常体现为用户故事和线框图，它们定义了用户要做的事情和具体的界面，用户将借助该界面来完成那些目标。

    最近，一个大二学生在微信上与我交流，提出了以下问题： 我是学软件工程的，但是对其发展方向并不明了，至今只学了c和java 没有学c++，老师只是上课，其他都是自己去了解的，想知道如何才能成为一名软件工程师等等这些。  

    本来发微博的，越说越多，算了，发篇博客把，说点工程师如何取得进步的问题， 1：描述和记录问题要精确，数字化，“负载很高，连接很多，速度很卡”这种描述都是不对的，负载uptime值多少，连接数具体有多少，平时正常多少，高峰多少，访问延迟有多大，全部要数字化，而且要有问题状况下和平时的对比，养成这样的习惯，技术分析能力才会有进步。 2：分析过程要有条理，出问题找不到原因，不奇怪，我也经常找不到；但是你为找...

    也谈：PM与工程师看了纯银写的《PM与工程师》，也参加了PMCAFF深圳3月份的活动聚会，就这个话题聊聊自己的感想。PM与工程师最容易产生冲突的地方在于需求和进度：产品需求变更折磨工程师、项目进度延迟、产品质量不过关，影响到产品的上线和运营。大体上，可以通过下面几点来避免：(1) 认同，归属感在产品规划阶段，跟工程师多聊聊，聊一聊项目背景、市场机会、我们做这个产品对公司有什么好处、以及很关键的一点是产品的成败对我...

    不久前我写了篇日志《PM与工程师》，讲我的一点经验，PM如何与工程师协作。但是知易行难啊，最近我们的工程师也有点小抱怨，认为需求变动较多，太折腾了。我听到以后很警惕，查了一遍，发现变动的需求大部分还算合理。半年多来一直强调敏捷，敏捷，有什么想法就快速发布出来，再根据上线效果进行调整。因此“一步到位”的方案是不可能的，而快速调整是必须的。这时工程师就有意见了，觉得后续的修补太多，浪费时间，希望发布第一个...

    过节前看到一篇文章，讲产品项目就应该由工程师来主导，但国内让PM去驱动项目，搞得乱七八糟，很恼火，怎么可能做出一款好产品来呢？很显然，写这篇文章的是一位愤怒的工程师，Angry Engineer！我跟他至少有两点共鸣：1、国内的PM确实常常折腾工程师，甚至不乏“把工程师当工具对待”的情况。2、如果工程师有开阔的产品视野与全面的设计素养，知行合一，由工程师来驱动项目是一个完美的选择。可惜由于教育环境的问题，国内通才太少...

    facebook 的工程师文化

    同样是写程序，不同的岗位工作内容不一样，对程序质量以及工程师的要求也不一样。程序开发大概可以划分成两类：开发和研发，相应也就有开发工程师和研发工程师。很多人觉得做开发和做研发没什么区别，“都是一样对着电脑写程序啊”，但其实这两者是完全不一样的，下面我想抛开公司对员工的期望、社会对工程师的需求等其它因素，单纯从国内互联网行业“工程师个人发展”的角度来说一下我个人对这两类工作的看法。

    今天金山的刘鑫老师在邮件里谈到了“工程师思维”（工程师的思维能力，就是一种可以把想法实现出来，一步步的变成现实的思维和实践训练），借题发挥一下吧。 我上高中的时候，学校算是本市最好的中学，班主任物理老师也是特级教师，但我一直不是觉得，他讲课说不上多好，无非是循规蹈矩的套路，甚至有点死板――就拿受力分析的题目来说吧，多简单的题目，都要画坐标系，而且就只有那么几个力：重力、摩擦力、牵引力等等，来来去去...