一个技术总监的忠告：精通那么多技术，你为何还是受不到重用？( 三 ) _技术

老田会在开会前一天，把会议内容和可能出现的问题都预先做功课。一方面是防止会议开着开着跑题；二是万一出现争议问题，老田可以列举出来事先准备的技术方案，这样也能加快会议进度。

还有，对于一些不那么重要的会议，老田一定会态度坚决的避开或者指派别人参加。

4. 版本控制工具的熟练应用这个问题是老田主动和大刘提出来的。
老田发现，对于版本工具使用不当，会耽误开发人员很多时间。而版本控制工具，即使一些工作多年的程序员，往往也经常会使用不当。
这些不当的使用，会造成许多问题。比如，各种各样的代码冲突、版本重叠，莫名其妙的代码丢失。
对此，老田每次负责一个新项目，都会严格指定版本工具的使用规范，会花时间对开发人员统一培训版本工具的使用。同时，也会把各种技巧、注意事项、常用命令整理好，放在内部的共享文档中。
老田的这些举措，在实践中，大大改善了版本控制工具不当使用造成的问题。
有一个项目组在规范使用之后，竟然比之前的开发速度快了三分之一。可想而知，这个问题有多严重了。
5. 不要把解决方案复杂化老田和大刘谈了谈关于技术和技术落地之间存在的问题。
老田和大刘都发现有些程序员特别喜欢炫技，这些炫技某些时候会导致整个系统复杂化，最终产出反而不尽如人意。
老田举了个例子，比如，一套内部使用的资产管理系统，中间有一个需要调用公司其他项目接口的小功能，这种简单的东西交给了一个比较年轻的程序员。
结果这个程序员又是考虑对方接口不稳定的情况，又是考虑这个功能会有使用过度频繁的情况，还使用了缓存去储存一些状态，防止频繁调用数据库。
对于这种情况，从纯技术角度，当然会鼓励人们想的越全面越好。但是，在实际落地的时候，你要明白这只是一个公司内部使用的小项目，没必要为了各种概率很低的风险，把明明很小的一个功能给做的很复杂。
针对这种问题，就需要技术 Leader 及早发现、介入，防止出现过度设计、过度开发。
6. 把任务安排的井井有条老田其实和大刘一样，每天杂事儿很多，每天的任务也很多。大家对这些任务的管理能力自然就有高有低。
老田对于任务紧急程度的判断都是经过深思熟虑、实际分析过的，任务之间的先后顺序，也和任务交付人认真沟通过。对一些根本没必要的任务，老田会态度坚决的对这些任务说 No 。
大刘自我总结，他这方面做的不好。首先，他安排任务容易被任务交付人的情绪影响，对方催的急，他就优先安排。其次，任何任务大刘都没有拒绝过，顶多是排期靠后。最后，大刘没有考虑任务和任务之间的关系，有些任务之间是关联的，完全可以融合一起搞定，大刘却没有思考，从而割裂开安排，这也是很大的问题。
比如上次，大刘接到两个任务：1、去掉 VMware；2、MQ 版本升级。
这两个任务都需要业务系统停服才能干，大刘当时也没在意，两个任务放在两天，连续两天停服，虽说每天停的时间不长吧……
这俩任务完全可以放在一起，利用一次停服集中解决。这样对用户影响更小，业务部门也不会那么不满。
7. 不要死板的写代码很多程序员知识面很宽，基本功也非常扎实。但是，有一种能力，是学校教不出来、面试也不容易看出来的，就是代码能力。
所谓的代码能力，有的是指写代码不出 Bug 的能力，有的是指算法落地能力……但这里想说的，是不写死板的呆代码的能力。
这是什么意思呢？
我们都知道，程序员少不了要维护老项目。在维护项目的时候，我们面对各种不断的新需求，经常要去修改代码。