摘要： 前几天同一个朋友闲聊，他说了个很有意思的观点：我们不招北大清华的。因为大家都经过高考的折磨，所以心里对考上北大清华的都还是有点敬畏的，因此就追问了下原因。他的回答很简单：我们得承认这两所学校的人非常优秀，但跑到二线城市来的大部分都不能踏实做事，招了也不能用。他说的踏实做事这点比较能引起我的共鸣，可能也有一定的代表性。学校本身提供了一个起点，证明的也是过去，毕业后想证明自己还是得用事实说话。但确实有些人陷在过去的光环里出不来，潜意识里认为自己天生就是干大事的，结果手里的工作做不好，也就没有了干大事的机会。这要多么疯狂的人，才会不根据表现，而只根据学校来决定一个人的职位。还有一种表现是脑子快的，学 阅读全文

摘要： 虽然CodeReview经常被提及，但就我个人感觉（一半从别人的博客，一半个人经历），CodeReview的实际境况大多时候还是比较难看的。更多时候，CodeReview很像被存起来的酒，用的时候拿出来看看，证明有这东西，但大多时候是不用来喝的。细究成因可能是来源于两个方面：一是时间压力太大。软件开发里可以安全打折扣的地方其实不多，文档不写很容易被看出来，代码不写程序就动都不动了。没办法下，很多时候就只好拿CodeReview开刀。毕竟CodeReview里少看两眼，多看两眼，用多少心思看，其实是个良心账，外人看不出来的。同时，CodeReview本身也确实是个费时间的活。另一种成因是看不见成 阅读全文

摘要： 经济形势一路走低，公司裁员的消息也偶尔听闻，其中闹的比较醒目的则是摩托罗拉移动的裁员。从报道来看，南京摩托罗拉移动的各位对这个公司还是很有些恋恋不舍的，甚至提出了希望再为公司工作一年的期望。具体情形其实不太了解，不妄发评论了，但这事再次提醒我们一个很本质的事情：职场如市场，本质上就是一场交换。员工可以跳槽，公司可以裁员，都是非常的正常。很多公司都会强调企业文化，希望能营造一种归属感，这没错，文化确实很重要，但也确实不是职场关系的支点。对外，企业有所产出，与客户交换获取收入；对内，则是员工有所产出，与企业交换获取工资等等。这是根本中的根本，在此之上才有五花八门的其他关系。这就引申出了一个话题：既 阅读全文

摘要： 我一直的观点是要对“难”做一点分解。好比说航空母舰的弹射器，我们造不出来，很“难”与一台机器有一千个螺丝要拧，保证3年中所有螺丝都拧对了，很“难”，这两种场景下“难”的含义是不同的。软件开发的难度更多的类似于后者，表现为繁杂，而不是类似于前者表现为“搞不定”或“做不出来”。总是有人喜欢把问题绝对化，所以这里补充一句，软件涵盖的范畴可以很广，因此确实有很难搞定的，类似于弹射器的领域，但应该不是主流。以前的很多提法，在这样一种大前提下就变的没有什么意义了，比如说：国产操作系统。当很多公司或组织标榜这类事情的时候，似乎自己更愿意认为这是一种技术突破。但实际上在开源如此发达的今天，这类东西的开发更需要 阅读全文

摘要： 软件架构师的定义乃至所需要的特质历来众说纷纭。下面从一些另类的角度来做点分析。从产生根源来看，程序规模越大，参与人员越多，越需要架构师；程序越小，参与人员越精英化，架构师存在价值越小。这不难理解，大军团作战，总不好一窝蜂就上去了，总要有些规则，总要有人把我全局。架构师就是在比较高的层面上把握全局的这个人。从这个角度来看，对架构师而言选择最重要，因为站的高，所以选择具有非常大的价值。注意不是UML，也不是对业务的理解，不是编码能力而是做出正确选择的能力。当下的开发环境下，考虑解决方案时，所面临的选择不是太少，而是太多。举个最简单的例子，我们要开发一个基于Web的项目管理程序，那么你面临的选择是： 阅读全文

摘要： 假设说一个人是个项目经理或部门经理，并一下子扎到了一个执行力不好的环境中，那么这个人能干点什么或者说应该干点什么？大多时候中层的人并不能左右高层的性格乃至种种选择，所以如果真有让人绝望的事情，又没有忍耐的的能力那就只能换个地方。这很简单，并不值得多谈，我们主要要关注的是事情积极的一面，即如何扭转这种局面。为了有所改善，第一关键的事情是要足够真诚。工程师组成的团队中其实并不需要很多政治，大多时候，大多事情是可以谈，并谈出以逻辑和事实为根据的最佳答案的。中层和工程师间的隔阂大多时候起于一些很简单的原因，如：工程师更贴近现场，如果中层总是把自己的位置摆的很高，喜欢居高临下，那么工程师会觉的这个中层很 阅读全文

摘要： 在考虑如何解决执行力问题之前，很有必要考察一下执行力为什么会败坏。现实中很本质的东西往往会被繁杂的细节所掩盖，因此我们来抽象出一个虚拟的公司，来看看执行力出问题的各种可能性。我们假设有一个小公司刚刚建立，其中高层2人，中层3人，一般员工30人。我们假设在公司营业的第一天，执行力是没有问题的。那么如果执行力最终出了问题，变成说了不做的状态，那么要么主要是高层问题，要么主要是中层问题，要么主要是一般员工问题。每个角色均摊责任这种事过于巧合，不太可能存在。假设一般员工应该负主要责任，那么假设成立的前提就是：招募的员工大部分是“***民”并且能够进行比较一致的行动来败坏公司制度以及中层的安排。缺乏这两点， 阅读全文

摘要： 如果让每个人选一个管理（包括项目管理和部门管理）中最可怕的事，答案想必不尽相同。有的人会老生常谈的选沟通不畅，有的人会选文化冲突，有的人会选资源不足等等。但就我个人感受，第一可怕的事是说了不做，流行点的词可能叫执行力。典型的场景是规则流程定义了一大堆，一到做的时候这些东西就都放在一边了。每个人都按自己的习惯来，各行其是。这很可怕，会导致无政府状态，做的人因为看不到改善而抱怨，管理者会因为看不到未来而绝望。比如说我们周围路总修不好，对此大概没人认为是个技术问题---偷工减料怎么也不是技术问题。总结之后可能发现，“啊，这和层层转包有关系。应该禁止。”接下来制作各种规则，禁止转包。但不去执行，或者说 阅读全文

摘要： 不知道多少人有这样一种经历：明明从技术上看是不对的或者说是不可能的，但还是要按照一种不对的方向做下去。至少我个人是有这种经历的。销售的和企划的定好了规格和日期，把他们都作为不可更改的目标发配给程序员。程序员明明知道不应该走捷径去赶进度，但给日程压的没办法，就只能赶啊赶。在限定场景下，一个人所能完成的工作其实是个确定值，因此这时候能采取的手段其实不多：一个是加班，一个是降低代码质量。最终产品仓促上市，在市场上发现了很多问题---最终很可能仍被归结为程序员的问题。不知道大多时候，面对这种场景，工程师（包括开发和测试）会做什么样的选择？我猜由于在这种多方博弈的时候，工程师的声音总是最弱的一个，所以大 阅读全文

摘要： 在软件这个行业里，怕是没有任何一个其话题域像开发语言这样引起争议了。对开发语言是非的争论，不单旷日持久，且深度亦是与时俱进。实现要强调下的是，在这里我们要专注的是开发语言的选择而非开发语言的优劣。从不同的视角对开发语言进行选择，其结论可能大相径庭。从项目的角度看，语言自身特性的多少，强弱往往并不成为一个关键选择因素。好比说某语言支持多重继承，而某语言不支持多重继承，但对大多项目而言多重继承这一语言特性并不成为选择的决定性因素。从项目角度看，某些通常被考虑(或不得不考虑)的因素有：历史的原因。维护升级类项目这类没有选择的选择自不必提，这里说的历史的原因是指这样一类情形：完成某个项目需要某一图形算 阅读全文