老师傅告诉你，学校学的编程知识，和工作所需要的差别有多大！

工作和在大学学的知识是不一样的，我已经从事C/C++编程开发十多年。当初也是计算机专业毕业。这一点算是深有体会

我在面试很多计算机本科甚至硕士毕业生时，他们很难向我们展现出实际的项目经验和工作能力，因此我们只能考验他们对某门编程语言的熟悉程度，也就只能是语法和算法。因此也不可避免地让他们做些算法题。说实话，我觉得这种方式很傻，有谁会在纸上写程序呢？但你会有更好的选拔方法吗？

不夸张的说，一切学校学习的目的是为了通过考试。因此在学校学习编程无非是通过期末的考试。考试是在卷子上写程序，还是在机器上写程序并不重要，因为无论哪种考核方式，都和你将来是否成为一个合格的程序员没有什么卵关系，它仅仅就是纯粹的考试。但是，我想说编程的能力不在于你对这门计算机语言语法背诵以及几个算法的记忆。在实际工作中，更多在于你怎么组织你的代码。 语法是可以百度的，算法前人早已经给你写好了，你只需要知道怎么调用。但是新手和老手写出的程序是很容易就能分辨出来的。

有些人面试的时候很厉害，但到后面，你会发现他/她并不适合也不想成为一个程序员。因为真正的编程工作是如何理清一大堆代码，而不是在几个烧脑的算法上玩智力游戏。如果你刚入行接手的是一堆糟糕的代码，那么我只能遗憾的告诉你，你的程序员生涯有了一个糟糕的开始。第一次糟糕的体验是会影响一生的。所以我希望你一开始接手到的是一堆高人留下的代码，这对你的发展以及培养你对编程兴趣是起到至关重要的作用的。当然，如果你天赋好，你最好有能力选择好的代码堆，或者自立门户。毕竟自己挖坑总比填别人的坑要来得爽。

我这里有点小小的人生经验要分享，就是你看一个人适不适合编程，就得看他是不是喜欢把事物整理得井井有条。在学校里你看他的床铺，看他的写字台，看他组织集体活动的能力，等等。不要以为程序猿都是胡子拉碴，脏里八稀的，那些都是电影小说杜撰的。就算有时候会出现这种情况，那也是为了短期的冲刺工作。程序猿就是艺术家，虽然很多人不这么看，就连很多程序员自己也并不这么认为。但实际上，程序员就是艺术家。语法和算法，还有程序组织能力，那些都只是基本功，就像画家的画功一样。厉害的程序员是要有对现实世界抽象的能力，是要用系统性的思维去理解世界，并有可能模仿上帝去创造自己世界的人。因此，你会看到许多高阶程序员写的书和文章都像哲学家写的一样。

看一段糟糕的代码就如同你走进一间脏乱的房间，你会闻到不好的味道，你会看到东西被放在不该放的位置上。新手写的代码就如同一间不知道整理的小孩的房间，被子团在床上，玩具乱扔，墙上乱画.....你暂时是不会指望他能把整个家都收拾好的。因此，很多情况下我带新人更多的是会告诉他们代码应该写在哪里，而不是i++和++i的区别。

实际的编程工作中，你做的事情往往是一个大系统中的一个组件。完成一个大系统的开发工作是一个团队的事情，因此你必须学会如何团队开发。而这点上和学校学习的编程是有本质区别的。学校的编程课教授的东西是点状的，它教你如何写出可以编译过去的一小段代码，它教你一些经典算法，但都没什么实际卵用。举个例子，比如排序算法，教科书上一大堆。有些同学硬是能将各种排序算法默写出来。然而他们永远不会想到关系型数据库是如何实现排序的，因此我一问他们如果内存装不下所有数据的情况下，怎么排序，就个个傻眼了。因为他们只知道在内存中排序数据，不知道多了硬盘后怎么处理；他们只知道冯·诺依曼这个名字，并不理解它在计算机架构中的本质。

这些点状的知识点对于一个不接触实际的学生来说是很难串起来的。团队开发是个很搞的课题，涉及组织理论。虽然很多人都能意识到这样一个事实：人多未必能办好事。但真正联系到实际，就是如何发挥一个团队的最高组织效率时，往往对自己的认识是估计不足的。很多想当然的事情是行不通的。编程工作是纯粹的脑力劳动，是很难量化的劳动。咨询公司乐此不疲地发明各种指标（如：代码行数）和各种团队编程模式（如：SCRUM），但也是基本没什么卵用的。永远记住程序员是艺术家，不要试图用管理指标来衡量艺术家的工作，这只能靠尽可能发挥程序员的主观能动性来提高效率和质量。