2wd4 Note

以最小代价解决问题

  • 已经三周了, "以最小代价解决问题"这句话看了几次, 可是之前一直没有那么深的感触. 可能是之前的任务相对比较容易, 没有付出什么大的代价.可是上周的GUI版本的极简日记交互系统着实花费了一些时间. 所以当再次看到这句话时, 马上在反省这一周为了解决问题而做的一些尝试.

    • 是不是代价大了点?
    • 为什么会觉得代价大?
    • 问题出在什么地方?
    • 该怎么解决?

      • 如果以时间长短来衡量, 确实代价大了一些.
      • 因为分析目前完成任务的代码(还在迭代中, 又有些新的想法要实现一下), 发现把时间过多的花费在了看官方文档上, 但是对于任务的帮助很小, 迟迟不能进入编写代码的状态.
      • 问题主要出现在虽然知道自己需要什么功能, 但是需求太多, 一头扎进文档里看啥都新鲜, 一时间竟不知道怎么下手, 花费了很多时间看了些暂时用不上的东西, 反而将最基本的功能置之不理.
      • 解决办法:
        1. 以功能为中心.在写文档的过程中, 通过输出明确功能点, 针对功能点有目的的看文档.(这也是大妈提到的, 笔记变成下一步的指令)
        2. 文档与实例相结合. 找到类似功能的实例, 结合文档搞清楚实现功能用到的函数, 思路等.
        3. 迅速完成基本功能,快速迭代. 不要想一下子弄成完美版本, 先实现基本功能, 吸收反馈, 快速迭代.

笔记-输出是更残酷的输入

  • 这个也已经是老梗了. 但老梗真的是越老越有体会, 越老越发现梗的价值所在.
  • 之前也一直在思考, 是写完代码, 复盘笔记, 还是边写代码边记笔记.
    • 目前的做法是:
      1. 首先写好功能需求, 然后根据功能需求找文档相关内容, 或者搜索实例.
      2. 编写代码, 运行, debug.
      3. 记录问题, 以及种种尝试+解决方案.
      4. 最后整理整个文档框架等其他修饰工作.
    • 但是现在写的还是很烂.
      • 很多应该详细交代的地方没有写清楚, 或者默认已知.
      • 写法不够丰富, 没法做到"有料, 有趣, 有种"
  • 经大妈的提示才意识到, 输出即是指令啊!
  • 最近看了Oliver Ding的文章, 也更进一步的认识到分享的重要性. 分享的最大收益者最终都是分享者自己.
  • 严谨, 认真, 有诚意的分享才能最大化自己的收益.
  • 所以, 有的时候可能在写文档的过程中会感到烦躁, 因为要照顾到很多细节, 但也恰恰是这些细节, 才让分享者收益.
  • 阳老在对人才的描述里, 不也有对细节的把握,这个一要求么?
  • Therefore, 不要放过任何一个输出的机会, 认真的做好每一个步, 做个靠谱的分享者!

提问

  • 其实这是我第二次写关于提问的感触.
  • 主要原因是: 我一直在思考为什么我不爱问问题!
  • 我清楚提问的智慧, 遇到问题也会按着提问的智慧中的逻辑去处理问题, 但很多时候我并不愿意去提问. 或者说我很慎重提问.
  • 我总是担心是不是我还没足够的努力去挖掘我的答案, 是不是还有自己解决的可能.
  • 而且, 还总是希望自己问的问题是很有价值的问题.
  • 这是不是好面子?
  • 不过大妈的话倒是点醒了我, 即, 慢慢的才会问出有价值的问题.也就是说这是需要过程的.
  • 我再思考思考...

更新

151101 沈浪编辑