前段时间，我和老板有一次关于我接下来工作方向的“探讨”，他的一些话让我开始思考这个问题，到底什么叫技术？
对于程序员来说，可能会常听到这样的忠告，或者是自己对自己的期望：踏踏实实学好技术。但以前我从来没有认真去想过这个问题，学好技术，到底是学什么。在我思考这个问题之前，我基本上把所有和计算机科学相关的东西都叫技术。写代码，搞算法，运维，测试，都叫技术。但是这天和老板的聊天让我不得不认真把所谓的技术做个定义，因为在聊天的过程中，老板说了一段话：
你重构这部分代码，其实就是把这些代码分别写到不同的地方去，其实没多大改变，你应该把精力花在别的方面，比如怎么让图片传输得更快…每次发送大概多大的tcp包….为什么每次发送x大小的包…这才叫技术。
说实话，当时我真被他说得哑口无言了。为什么，就因为他这一句，这才叫技术，直接戳到伤口的感觉（当然主要还是因为自己不够强不够自信！）。原来我一直做的只是码代码的工作，算不上技术。我是个半路出家的程序员，没有学过基础的大学计算机相关课程，所以这一直以来都是我的短板（也许主要是心理上的短板），虽然我一直也在断断续续地努力补上这些科班知识，但平时主要做的还是码代码的工作，我基本上主要关注的点就是怎么把代码写得漂亮，结构模块设计得合理，让程序跑得更稳定，让程序易读好改。这是我的追求。
所以，当时我心情很是沮丧的，我们老板是在百度待了多年的工程师，一般来说都是被划入大牛级别的，所以他的话让我郁闷了好久。虽然当时我知道自己并没有被他说服，但我也没能找到说服他的理由，于是接下来的时间，我一直在想这个问题，关于技术，关于写代码的意义。我很庆幸自己有过这样的思考，因为如果以后再有这样的情况，我就能做到既不妄自菲薄，也不会自以为是。
大体上我把“技术”划分为三类：1.编码，调试，设计能力。2.对某个技术理解程度。3.算法，性能优化。
1.这类能力基本上就是指写代码调代码的能力，如何把模块设计得合理，把代码写得优雅，不容易出错，结构灵活，耦合性小。这种能力我觉得主要是对软件系统的稳定性有非常大的关系，关于这点，我是不太赞同我老板的观点的，我觉得如果设计得合理，代码写得好，是能极大提高系统稳定性的，而不一定非得需要一点一点地调试修改。当然只要是代码就有bug，但是代码的合理性能让bug产生的可能性极大的减小，而且如果设计合理，模块化做得好，相关的错误报告和日志记录科学严谨，还可以分模块测试程序，让出现完全不可定位的bug的可能性减小。而且好的代码不可能一次就写成的，所以得不断重构不好的代码。相对其他两种能力来说，我觉得这类能力，是比较需要天赋的，就好像作家写作一样，需要有类似灵感的东西，而这种东西并不一定是可以学得来的。
2.这种能力我觉得其实是一种认知能力和学习能力。主要是对某种计算机技术的广度和深度的了解。比如对linux的了解，对ios的了解，api等等的了解，对android及其api的了解等等，这些都可以同学日常工作和自我提高中慢慢积累，基本上没有特别难理解的地方，主要的区别是知道不知道。所以我觉得这块能力的提升不是最难的，因为这些东西都可以通过阅读或者搜索获得和增长。但是说它不是最难的，要真正得到这种认知能力也不是那么容易的，特别是深度的积累。因为虽然是只要认真去学习，总能掌握，但一般人都不能做到真正静下心来，长期耐心地学习积累。
3.其实这部分应该属于前两部分，我之所以把这种能力专门提出来，是因为，我觉得这种能力是在技术初期不用也不该考虑的问题，因为我觉得你得首先利用足够多对某项技术的掌握，运用编码能力，写出满足基本需求且足够稳定的软件，再来考虑优化的问题，如果一开始就过多深入地考虑这个事情，会让项目进展看起来非常缓慢和不实际。而这种能力，其实又非常依赖前两种能力，因为你得非常了解代码，了解计算机，才能做好这个事情。
以上3点就是目前我对技术的理解，这篇文章虽然很短，但断断续续写了很久，所以现在看起来零零散散，有点没有重心，但我其实是比较想表达一个观点，就是写代码在技术中不应该只是类似于体力活的角色，代码很重要。