简介
技术人是天然的“技术控”
笔者是计算机科班出身，从高中到研究生，接受了十几年的理工科教育，对技术的追逐是天然的。加上很多新技术通常发端于国外，传入国内且热度上来已经是一两年之后的事儿了，因此对很多新技术的产生往往认为是天经地义的。对技术的“来龙”懵懵懂懂，“去脉”更是走哪算哪。
对于很多刚入行的小伙伴来说，业务问题从产品经理、项目经理、架构师到达自己手中的时候已经是一个明确的技术任务了，接触的都是技术/工程问题，用技术去解决天经地义。然而对于很多非技术问题，是否也可以用技术去解决呢？
举两个例子
去snapshot 化
背景：公司很多同事有一个不太好的开发习惯，二方库线上使用时没有去掉snapshot 标记，有时候改了代码也不升snapshot 的版本，进而导致不同的打包机器 打出来的包有可能不一样。所以，有必要在公司推动“去snapshot化”。
那么推动这件事，常规方法就是开个会，跟各个大佬说一下这个事儿，但我们知道日常的技术开发工作本来就很忙，靠人的主观能动性来推进很难保证进度的，因此要有一个量化工具，拿到一份儿带snapshot 后缀的二方库名单，根据名单的变化来判断“去snapshot”的进度。
为此，笔者写了一个简短的golang程序，扫描磁盘，可以统计到带snapshot的二方库的名单。
同时，为了规范儿二方库的发布行为，可以隐藏maven私服后台页面，对外提供一个系统，规定所有的二方库发布时，必须在该系统中填写版本、负责人、使用手册等信息。重要的是：系统可以拒绝对带snapshot 二方库的发布。
使用协作工具代替IM
背景：日常的工作协同，大家习惯上使用IM，由此带来的问题是：开发人员被频繁的中断。 因此，项目管理部门一直在公司推项目协作工具，产品经理将任务填在协作工具上，开发人员通过协作工具查询任务，完成后将进度同步到协作工具上。问题是：大家习惯用IM沟通，操作协作工具对大家来说是一个额外的事情，因此进展不大
对此，我们可以换个思路，假设我们可以根据协作工具自动生成“周报”，并规定日常周报以该周报为准，则操作协作工具对开发来说便不是一个额外的事情了，由此可以加快协作工具的推广。
什么是“技术人员的能力”
笔者已经工作三四年了，平时会面试很多人，包括自己闲下来也会学习很多技术，一直以来，脑海里都会有一个困惑：什么是能力？很多时候周末去公司看书，不知道看啥，感觉不会的很多，但真去学一个具体的技术又感觉意义有限，更何况坚持学习本身就是一个蛮难的事情。
极客时间有一个《数据结构与算法之美》的教程，在教程最后有很多人分享自己的学习体会，有一个人总结的特别好，调整一下是：技术人员，首先要能分解并给出一个实际问题的有效解决方案，然后给出（或交给小伙伴完成）高质量、可维护、接口化代码实现。
所以，能力笼统的说就是解决问题的能力，但问题经常不是以技术问题的形式表现出来。我们要培养将非技术问题转换为技术问题的能力，才有机会创造性的解决日常工作中的很多”效率“问题，让技术为我所用。