先搭框架、再填充。要先考虑总体的设计，然后：

• 根据大的设计，逐步向下推进、细化。
• 在考虑的过程中，分化出一个个可做的点时。
• 每做完几个点后，重新从更高的视角、从框架的层面来审视，看有没有问题、重新评估中接下来做什么。

如果一上来就沉迷在细节中，很可能发现不了架构上的缺陷、或者说可改进的地方。另外，会对总体缺少把控，这也是项目管理者不愿看到的情况。

当然，在最开始的技术可行性研究阶段，可以先着重研究没不确定的点。等整体上没有大的不确定的点时，就可以开始做总体设计了。

批评容易，建设很难。做人，大气一点。

不管是生活、还是工作，总会有很多让我们不满意的地方。找出其中不合理的地方、并骂之，容易。但要真的把你放到那个位置上、思考问题的解决办法，并不容易。

所以，给在那些位置上的人们多些宽容。多考虑如何解决问题、如何改进，和挖空心思考虑如何吐槽更刻薄比之，更有意义。

程序员总会碰到这样的情况：明明是对的，怎么就是不对？

这时候，通常已陷入一种困境。如果继续研究，会效率很低、浪费时间；更关键的，会让心情变得很糟糕，变得很烦燥、厌恶编程。

出现这种情况，可能是是思维陷入某种陷阱中，可能因为忽略了某个关键因素导致的，可能是由于知识盲区而没考虑到某一点，也可能是所依赖的环境的 Bug 导致的。

在这种情况下，建议是：换脑。要么让大脑彻底的放松，什么都不想；要么是做点完全不同的事情，让大脑不同的区域工作。等状态切换过来了，再去攻克这个问题。

其实，在你休息、或做别的事情时，大脑也会在潜意识里思考之前的问题，很可能给你带来意想不到的方案。即使没有，在换脑后，大脑会恢复敏捷；更关键的，心情也会平复下来，可以以更好的状态来解决之前的问题。

这样做，看似耽误了进度、浪费了时间，其实很可能不是。如果在思维的泥潭里继续挣扎，可能会浪费更多的时间，不信你回想下自己之前碰到过的类似事情。

下次再碰到这种情况：换脑。

相信大多数人都认同，未来是在向更大、更复杂、更网络化的方向发展。即使如此，依然会有小的天地。

• 比如刘慈欣的小说《微观世界》，就讲述了这样一个故事：一次地球灾难之后，正常人类死绝了、仅存一人。而演化出小到需要放大镜才能看到的新人类。这样的人类对资源的消耗极小，也就更容易生存。一瓶罐头，就可以够他们的一个城市吃一个月；他们的宇宙飞船也只有小木棍那么大。

• 《蚊人》这部电影中，也讲述了人在变小之后所具务的神奇力量。

• 就像地球上的氧气，绝大多数由海洋里几乎看不到的藻类所产生的。离开这些小小的藻类，看似强大的人类却会灭绝。

• 比如人类对于小小的癌细胞、艾滋病，依然无能为力。

这次在京东众筹，我也有点小感受。一个大的、复杂的产品，需要筹更多的钱，才能养活那个养活它的团队，才能让自己生存下去（换个角度，是我们在给产品加功能，还是产品自己为了生存下去，逼着我们给它加功能？）。而一个小的产品，甚至小到养活一个独立开发者的钱，就可以让其生存下去，并不断演化。

小和大，究竟谁的竞争力更强？要谈竞争力，首先要让自己生存下去。更具生存能力的存在，更具竞争力。更大，可能意味着更强，也可能意味着更脆弱。

从小的教育，使得我们追求被认可：做某某事，就可以得到小红花。

一旦没有了小红花，我们该做什么呢？做得对不对呢？

没有人一直能给我们判断，总归要自己判断。我们不能一直为别人做事，总要为自己做。

为了被认可而做事，是幼稚；
做事后追求被认可，是不成熟；

被认可，是别人觉得有用后的感叹。