raaaaaar

讲在实际工作中会遇到的问题，这样收获更大，和别人也容易交流，在交流的过程中也可以聊聊相关的技术实现，不一定非得聊上面的主题。

一定要和下面的交流，不要在上面自己讲自己的。

黄金圈理论，也就是 what why how 的方式去梳理思路，千万不要自己讲自己的，很多人一来就讲一些非常细节的东西，下面的人根本不知道它在讲些什么东西。

尽量讲高一点层面的知识，也就是说最好不要具体到代码细节，真要用到代码也要提前准备好。

讲前写好技术文档，注意排版，思路

总之就是，多讲大家都会用到，都能用到的实际工作中的知识，讲的人一定思路清晰，知道自己在讲些什么，要多和下面的人交互，就像平时交流一样，但是话题需要你自己来掌控。

其实如同上面的兄弟说的，交流会其实主讲人的收获最大，自己主动去了解知识，系统化，自己去表达知识，和别人交流，这些都是能很好锻炼自己的，尤其是以前没有这么做过的人。

如果你是老板，是管理层，你再思考这些问题，如果你就是个打工仔，那你应该高兴。

产品给原型图，后端自己琢磨写接口文档，写完之后大概让前端看一下，然后前后端并行一起写，写的过程中一般遇到问题就会交流，问需求自己理解是否到位，某个接口是否完善等等，之后写完后再对接。我自己的经验只是一些小型的产品，因此流程上肯定比不上那些大公司的，但是我认为最重要的是沟通，前后端之间的沟通，和产品间的沟通，遇到问题一定要问，看自己对需求，功能的理解是否到位，即时更改，这才是最重要的，因为无论什么流程都不可能一次性就完美的，肯定是不断修改，动态的一个过程。

没有 google 开发效率降低 80%

刷呀，只要硬件没问题，软件一般都能解决

写算法由测试驱动我倒试过，的确能梳理思路，不过开发也这么做的话，有些函数相互依赖实在耦合度大，而且总是实际做和理想中有很大区别。。
@monkeyk #1

在看的过程中我就大概猜到了，wiki，没有默认配置，终端，频繁更新，这几个关键点其实就已经在走不同发行版的分支了，然后结果果然是 Arch，我现在用的也是

你应该对自己的能力有基本的认知吧，我对自己就有很清晰的认知，知道自己的优缺点，所以别人对我的评价究竟是认真的还是情绪化的，我一下子就能判断了。