2wd4 Note
以最小代价解决问题
已经三周了, "以最小代价解决问题"这句话看了几次, 可是之前一直没有那么深的感触. 可能是之前的任务相对比较容易, 没有付出什么大的代价.可是上周的GUI版本的极简日记交互系统着实花费了一些时间. 所以当再次看到这句话时, 马上在反省这一周为了解决问题而做的一些尝试.
- 是不是代价大了点?
- 为什么会觉得代价大?
- 问题出在什么地方?
该怎么解决?
- 如果以时间长短来衡量, 确实代价大了一些.
- 因为分析目前完成任务的代码(还在迭代中, 又有些新的想法要实现一下), 发现把时间过多的花费在了看官方文档上, 但是对于任务的帮助很小, 迟迟不能进入编写代码的状态.
- 问题主要出现在虽然知道自己需要什么功能, 但是需求太多, 一头扎进文档里看啥都新鲜, 一时间竟不知道怎么下手, 花费了很多时间看了些暂时用不上的东西, 反而将最基本的功能置之不理.
- 解决办法:
- 以功能为中心.在写文档的过程中, 通过输出明确功能点, 针对功能点有目的的看文档.(这也是大妈提到的, 笔记变成下一步的指令)
- 文档与实例相结合. 找到类似功能的实例, 结合文档搞清楚实现功能用到的函数, 思路等.
- 迅速完成基本功能,快速迭代. 不要想一下子弄成完美版本, 先实现基本功能, 吸收反馈, 快速迭代.
笔记-输出是更残酷的输入
- 这个也已经是老梗了. 但老梗真的是越老越有体会, 越老越发现梗的价值所在.
- 之前也一直在思考, 是写完代码, 复盘笔记, 还是边写代码边记笔记.
- 目前的做法是:
- 首先写好功能需求, 然后根据功能需求找文档相关内容, 或者搜索实例.
- 编写代码, 运行, debug.
- 记录问题, 以及种种尝试+解决方案.
- 最后整理整个文档框架等其他修饰工作.
- 但是现在写的还是很烂.
- 很多应该详细交代的地方没有写清楚, 或者默认已知.
- 写法不够丰富, 没法做到"有料, 有趣, 有种"
- 目前的做法是:
- 经大妈的提示才意识到, 输出即是指令啊!
- 最近看了Oliver Ding的文章, 也更进一步的认识到分享的重要性. 分享的最大收益者最终都是分享者自己.
- 严谨, 认真, 有诚意的分享才能最大化自己的收益.
- 所以, 有的时候可能在写文档的过程中会感到烦躁, 因为要照顾到很多细节, 但也恰恰是这些细节, 才让分享者收益.
- 阳老在对人才的描述里, 不也有对细节的把握,这个一要求么?
- Therefore, 不要放过任何一个输出的机会, 认真的做好每一个步, 做个靠谱的分享者!
提问
- 其实这是我第二次写关于提问的感触.
- 主要原因是: 我一直在思考为什么我不爱问问题!
- 我清楚提问的智慧, 遇到问题也会按着提问的智慧中的逻辑去处理问题, 但很多时候我并不愿意去提问. 或者说我很慎重提问.
- 我总是担心是不是我还没足够的努力去挖掘我的答案, 是不是还有自己解决的可能.
- 而且, 还总是希望自己问的问题是很有价值的问题.
- 这是不是好面子?
- 不过大妈的话倒是点醒了我, 即, 慢慢的才会问出有价值的问题.也就是说这是需要过程的.
- 我再思考思考...
更新
151101 沈浪编辑