1%的灵感最重要和改进沟通-理念

我必须记录自己的一些事情，总结一些感悟，这样，回头过来，我才知道原来我在某一段时间真真正正地活过。我从9月份才开始写博客。我发现，9月份，是我收获知识，收获思想最丰富的一个月。坚持总结对我来说是个好事，不管是技术的，还是思想上的。

 

第一部分

 

爱迪生说过一句话，有一部分是，99%的汗水和1%的灵感。还有一部分是，“而那1%的灵感是最重要的”

 

刚开始以为自己理解这句话，现在才知道自己没有理解好这句话。所谓真正的理解，都是建立在经历上面的吧。

 

99%汗水用来步人后尘，模仿学习别人的东西。

我花时间学习how tomcat works，尝试实现一个服务器。我花时间去模仿几个网站的UI和布局。我花时间学习JAVASCRIPT，学习Crock Ford的思想。

99%的汗水，换来一些性能的意识，架构的意识，换来一些自己的库、组件和工具类，换来一些解决问题的固有方法。

 

每个人对问题的理解不一样，可以产生不同的解答。这就是1%的灵感。编程珠玑对数组旋转（向左移动N位）的几个方法，就是一个很好的例子。说个自己的，当我看了编程珠玑的位图排序，想起当年面试的一条题目：

有两个整数数组，O(N)时间内找出不同的数字。

我终于找到了解答。这也是1%的灵感。灵感，也许是人生最有趣的地方了。我甚至不知道灵感从何来，但是好像读得书多，经历越多，总结越深刻，思路就越广、越清晰。

 

山寨个几个页面，大致熟悉了BOX MODEL,POSITION,FLOAT，总结了一些套路。当自己需要做一个数字键盘的时候，从之前的练习中找到了布局的方向。假如我之前山寨或读过了CSS禅意花园，肯定可以构思出更精妙的方案。这也是程序有趣的地方。程序可以不仅仅是产品，而是艺术品。期待自己成为大师的一天，享受那创造的乐趣。

 

学习了一部分how tomcat work，再看个遗留的通讯程序，没有什么难度，都知道是那么一回事了。99%的汗水，可以让自己用别人的知识解决自己的问题。

 

“而那1%的灵感是最重要的”。

读书没有用。解决问题，为人提供服务，创造价值，才是最重要的。那些知识都没有用。

国庆去香港，看了一本书，介绍IPAD的，但是真正吸引我的是作者对上帝的信仰，对人生的一些概括。人生要处理7样事情，

时间 健康 金钱

知识 记录（例如写篇技术博文） 

资产（资产可以是一部IPAD，一部电脑，它不仅仅是财富，也是制造财富的工具）

行动

 

7样东西，构成一个产生价值的环。

我们为了得到更多的金钱和资产，需要投入时间、健康，需要学习更多的知识，需要时还要投入金钱和资产。单单投入时间按，健康，知识，这个环产生的价值很有限，能够突破的，就是人的创造力。知识没有用，除非有创造力地运用。乔布斯，并不需要没日没夜地加班，不需要去耗费大量的健康和时间，不需要去大量地学习知识。是他的创造力制造了区别于常人的巨大财富、。

 

有时候，我自己为了一些小的技术细节问题纠结，却忽略了大局——对需要解决问题的理解和思考。解决什么，如何解决，为何这样解决...。近来和小麦聊过几句，他跟我说，互联网公司几乎无视框架，因为应用框架都不能解决最迫切的问题——性能，高并发，海量。他建议我学好基础，操作系统、数据结构、算法、网络。他说，并不是不知道这些知识就不能做业务开发，而是知道这样能够对自己的写的程序更有把握，知道怎么提高性能。然后说到面试，我想向他请教，对于互联网公司，C语言那些类库比较重要，有没有什么性能调优的书介绍，等等，就是说我该学什么比较好。然后他回答我，知识没有用的，看书的话，基础的当然要看，NIO,THREAD的那些。他建议我，把做过的东西，好好总结一些，有些深度和闪光点，再看看一些笔试题和面经，就很容易了。其实我觉得，自己虽然不是重头开始搭起公司的整个业务框架，但是许许多多的地方，我可以思考、实验，总结出技术框架的设计理念，如何兼顾对问题的解决、对开发人员的友好（易用，开发快）方面。这不仅仅局限于所谓的技术知识了，而是对问题的多方面理解、不同的理解，对知识的灵活运用。说到多方面的理解，99%的汗水可能比较有作用，基于别人的经验学习和自己的实践总结，遇到新问题，总有更广阔，更清晰，更肯定的思路。而且我觉得，坚持读书和练习，能够保持对问题理解的敏感度。即使学的是C，也对JAVA的理解有帮助。

 

对于一个数字键盘控件，可以对外提供9个回调函数，每个按钮一个，也可以只提供一个整体的回调函数——点击键盘事件，而不是点击按钮事件，这就是对问题思考的不同。

 

 

====

 

第二部分

 

最近发现，最大的成本不是开发，而是沟通。一直扯，一直开发，一直修改，没完没了。改进沟通，比改进开发更有必要！

 

0 要超级细节形象的沟通！许多时候，双发说一个文字表达的概念和思想，一致认同，实现后总会发现有不对的地方。不要只沟通思想，最好做到有一个具体的原型产品的基础上沟通！没做出来也要有张图片，有数据说明！

 

通常这不可避免"思想沟通"。唯一降低风险的方式就是开发到一定阶段的时候马上确认一下，防止越陷越深。有问题马上问

 

1 能够直接沟通的直接沟通。3个人，间接沟通总有不少误差。

2 能够马上沟通的马上沟通。

3 开发需要快速迭代，沟通过程中总有各种各样的修改，不要到什么问题都解决完了再发。不要对程序考虑太远的需求，搞好现在再说。

4 努力提高自己的水平，知道需要沟通的要点，知道要问哪些关键的问题。这一般人做不到。刚开始不知道问什么的话，记得反复沟通。沟通一次之后，自己学习理解，并说下自己的理解，以求确认；学习研究后通常会有新的疑问，再问，直至清晰为止，不要留下模糊的地方。