汇报工作只占了一个员工全部工作的20%，但却决定了他80%的工作效率和工作成果。以前对这类人情世故不以为意，认为都是溜须拍马，看了「向上管理：如何正确汇报工作」后，收获颇丰。在工作中遇到的问题，往往在技术层面都有办法，难就难在人上。第一次阅读这类职场书，摘录了书中的目录和要点。

自从用了微信读书后，就喜欢上了看书，利用通勤时间，多学习点知识。

其实知识的了解只是学习的一小步，转化为能力才是关键的一大步。如何才能让学习更有效果，真正做到能力的转化呢？

「结构思考力」是本很棒的书，比「金字塔原理」精简，书中的案例更符合国内环境，可以学到做报告和沟通技巧。这里摘录了书中的目录和要点。

最近一个月感觉很明显，需求迭代明明都排足了时间来开发，然而最后都是赶工完成。原因是经常被一些事情打断，一天到了傍晚时候才开始真正做当天的需求。

Q: 感觉我们前端能做的事情很少，前端真正的技术难点是在哪里？

今年做过3次比较重要的演讲，最近正在看关于演讲的书，借此机会对自己的演讲做一次复盘。

最近看了「演讲的力量」，是一本专门介绍演讲技术的书，摘录了一些笔记，对自己很受用。

最近知乎一直看到「为什么强如“死月”在阿里也只有 p6?」问题链接戳 https://www.zhihu.com/question/326940670

让我陷入沉思和不安的是玉伯的回答

一个考量维度是一个人的思维模式。具体到技术岗，很重要的一点，是去看一个同学会不会去思考事情背后的 WHY，会不会去深入了解 WHY 所处的大环境，会不会在想清楚 WHY 后，去分析思考解决路径，在有多条路可选的时候，敢不敢去做取舍权衡，能不能去找到最佳路径和实现策略。WHY - HOW - WHAT - DO 的思维框架下，DO 是最后一步，很关键，但前面三步如果思考不清，光有 DO 是很难拿到优秀结果的。—— 玉伯

最近做了一个C端H5项目，嵌在一个App里，上线前都测得好好的，上线后就暴露出各种问题。于是记录这些经验，希望以后启动新项目时能够顺利一些。

React 文档陆陆续续看了两三遍，但一直没有真正做过业务，每次都只记住个大概。这回跳出舒适区，主动在业务里用 React，记录一些文档中的关键点。