Follow me on GitHub Follow me on Twitter

工作学习周总结#3

 

  本周工作背景:本周正式加入了TEAM,时间真快,4周了。

浅阅读与深阅读:  

  本周谈到了这么个故事,在美国教书的某教授被中国引渡回国来在某不错的大学中教书。每堂课上完,教授都会询问学生本节课的内容是否都清楚了,学生回答很一致,“很清楚”。接连几节课都是这样,教授开始感觉不对劲,一场摸底测验,全班基本崩盘。不是因为这个班的学生刻意隐瞒什么,而是大家都认为自己懂了。

  这种情况经常发生,简单的例子:我们经常认为我们理解了某些东西,但是被人问起来,那说的可就是乱七八糟了。

  那么,这种问题为什么会发生?一个比较大的可能就是我们太喜欢浅阅读了,浅阅读是什么?两个体现:浅阅读时我们可能会选择一些短小精悍的文章,书籍,快速的看,快速的定位到想解决的问题。其次,浅阅读时我们的脑活动不是很强,没有那种“煎熬”的感觉。在浅阅读下,我们很难带着怀疑的角度看问题。任何一个没接触过的东西,都要质疑“真的是这样吗?为什么是这样?”确实是件很累的事。但是我们传统的教育方式其实就是死记硬背,不需要甚至是不提倡我们质疑。

  经常看到这样的情况:编程或者调电路时,一个人出现了什么问题,然后我们在讨论发现问题不对劲时,这位老兄会马上声音抬高八度,理直气壮的说:“XX书上是这么说的呀!”

  那么既然这样的劣根性是存在的,那要怎样提升深阅读在阅读中的比例呢?

  以下是我目前为了解决这个问题采取的三个原则:

  1.人为的创造多思考的机会:一本技术书籍,即使有了经过翻译的版本,即使那个翻译是绝对靠谱的,也要看英文的版本。在放慢阅读速度的同时,也就有了更多思考与怀疑的机会。

  2.在平时看知乎时,多想想我该怎么回答,而不是乐呵呵的看看最高点赞的答案。

  3.不认为任何事是理所当然,搞清楚根由。


  

给事情的“完成”下定义:
  每当我们做一件事时,事先给这件事怎样才算叫做完成下出定义会让我们在做事时更有方向。

  在我们解决自己的问题的时候:在我们总结出自己决心不够时,不要说 “我将提高我的决心" 可以改成类似于 “我将在下周做到每天在闹钟想起3分钟内起床”。
  当我们总结出自己设计模式一无所知时,不要说 “我将会读设计模式的书籍” ,可以改成类似于 “我将会在下周参考《head first design pattern》写出一篇有包括讲解,DEMO,以及结论的关于设计模式的博客”
  当我们总结出自己做事不够认真时,不要说 “我将会抬高我做事时的态度”,可以改成类似于 “我将会把我犯得粗心错误写到我的桌面壁纸上,每次做相关事情前予以确认,直到三个月没再犯,我再去掉它”
  这样,即时事情没完成,我们也能比较自己做出的结果和当初下的定义有多大差距,为什么会有这样的差距,不要沮丧,再次下出定义,再次努力。
  如果完成了,那么也不要骄傲,如果相同的事还要继续,让我们下个难度更大的定义,继续挑战自我。

  在与人合作解决问题的时候:敏捷开发有一个”Openness”价值观,强调让别人时时刻刻知道你对于这件事完成的进度,另一方面就是让别人知道你对于这件事完成的定义是是什么,如果对方觉得你对“完成”的定义下的不对,可以在事情开始前就来干涉,这比输出结果后,发现不对而返工好太多了。

  

一张图:
  今天不写第三点了,发张今天看到的

  


   

  最后借用上篇总结的话:
  抓好每分每秒,不要问自己“时间去哪了”,然后问对的问题,解决对的问题,当然,不在于逼自己,而在于平和的坚持,这才是长久之计,血气是不长久的。
posted @ 2014-11-23 22:23  官文祥  阅读(231)  评论(0编辑  收藏  举报