最近和某人聊天，谈论一些工作上的环境等等。谈话中让我想起来以前的主管问过我的一个问题：你想做偏技术的项目呢？还是偏业务的项目？这种问题估计在程序员的面谈中并不少见，而且有变体，比如问你之后想做什么类型的项目等等。对于很多偏技术的程序员，比如喜欢看技术类杂志，参与技术类活动，甚至无时不刻不在学习最新技术的人来说，选择偏技术向的项目更多一些。按照自己的兴趣正面回答这个问题固然很好，但是有些时候需要审视一下这个问题的背后主管的意图。

猜测主管的想法并不是说主管对你有猜忌，只是像做题时理解出题者的出发点一样分析一下主管为什么会这么问，期望得到什么样的答案。从主管角度来说，他除了要完成自己的任务之外，理论上还需要引导自己的下属。具体可能是帮你解决一些问题，辅导你工作上的成长，甚至推荐你升职等等。而从公司层面来说，一个能解决问题的员工比一个不能解决问题，或者花了更长时间解决问题的员工更好。更现实一点，一个代码平平或者还相对差的人比一个代码比他好甚至高一个等级却花了几个星期解决一个中小问题的人更受欢迎。这是一个比较残酷的公司潜规则。比较常见的是，你在某个需求中为了让某个功能更通用自己造了某个小的框架，但是开发时间比其他人要长。代码质量上你确实比其他人高，甚至bug也相对其他人少，只是很少有人会在有代码问题时问你问题，组外的人也不理解你的代码能力，主管面谈时甚至被”虽然你写的代码在组内相对不错“等评价，过了一段时间之后你就会觉得苦恼，对这样一种不被认可的环境所困扰。

对于本应在程序方面最拿手的程序员来说，参与各种项目，解决掉负责的需求，通过自己的技术给公司带来价值，公司给予相应的薪酬，还有阶段性的升职。但是现实情况是，你所看到的公司代码很多都是一种被同化的平淡无奇的有时候违背最佳实践的代码，偶尔会有一些可能会造成性能，安全问题的代码会被CR出来改掉，而你所做的优化，改进，框架等并没有受到主管或者其他人进一步的期待，特别是他们自己对于代码要求不高的时候。负责任的主管可能会适当的时候与你交流下代码的关注度问题，引导你关注一下其他方面。比如系统发展，业务前景等等。如果你在让项目顺利进行上还有所欠缺的话，可能还会要求加强那些方面。此时的主管如果问你这个问题，主管会综合你的回答和你的现状来进一步阐述他的一些想法，换句话说，面谈时候的这个问题，你的答案并不重要，特别是在半年评价的时候。

大部分项目，都是有具体的业务需求，配合代码上的修改来实现的，少部分升级安全，性能等自发的技术型项目。后者在基础开发组比较多，但是偏基础的组肯定不会问让你在业务和技术中选择的问题。所以大部分时候，你要明白，公司层面期望的是越快越好地完成项目，并不关注你的代码。理解这一点，之后很多事情就可以轻松一些了。