本週工作背景：本週正式加入了team，時間真快，4周了。本週談到了這麼個故事，在美國教書的某教授被中國引渡回國來在某不錯的大學中教書。每堂課上完，教授都會詢問學生本節課的內容是否都清楚了，學生回答很一致，「很清楚」。接連幾節課都是這樣，教授開始感覺不對勁，一場摸底測驗，全班基本崩盤。不是因為這個班的學生刻意隱瞞什麼，而是大家都認為自己懂了。
這種情況經常發生，簡單的例子：我們經常認為我們理解了某些東西，但是被人問起來，那說的可就是亂七八糟了。
那麼，這種問題為什麼會發生？乙個比較大的可能就是我們太喜歡淺閱讀了，淺閱讀是什麼？兩個體現：淺閱讀時我們可能會選擇一些短小精悍的文章，書籍，快速的看，快速的定位到想解決的問題。其次，淺閱讀時我們的腦活動不是很強，沒有那種「煎熬」的感覺。在淺閱讀下，我們很難帶著懷疑的角度看問題。任何乙個沒接觸過的東西，都要質疑「真的是這樣嗎？為什麼是這樣？」確實是件很累的事。但是我們傳統的教育方式其實就是死記硬背，不需要甚至是不提倡我們質疑。
經常看到這樣的情況：程式設計或者調電路時，乙個人出現了什麼問題，然後我們在討論發現問題不對勁時，這位老兄會馬上聲音抬高八度，理直氣壯的說：「xx書上是這麼說的呀！」
那麼既然這樣的劣根性是存在的，那要怎樣提公升深閱讀在閱讀中的比例呢？
以下是我目前為了解決這個問題採取的三個原則：
1.人為的創造多思考的機會：一本技術書籍，即使有了經過翻譯的版本，即使那個翻譯是絕對靠譜的，也要看英文的版本。在放慢閱讀速度的同時，也就有了更多思考與懷疑的機會。
2.在平時看知乎時，多想想我該怎麼回答，而不是樂呵呵的看看最高點贊的答案。
3.不認為任何事是理所當然，搞清楚根由。
給事情的「完成」下定義：
每當我們做一件事時，事先給這件事怎樣才算叫做完成下出定義會讓我們在做事時更有方向。一張圖：在我們解決自己的問題的時候：在我們總結出自己決心不夠時，不要說 「我將提高我的決心" 可以改成類似於 「我將在下週做到每天在鬧鐘想起3分鐘內起床」。
當我們總結出自己設計模式一無所知時，不要說 「我將會讀設計模式的書籍」 ，可以改成類似於 「我將會在下週參考《head first design pattern》寫出一篇有包括講解，demo，以及結論的關於設計模式的部落格」
當我們總結出自己做事不夠認真時，不要說 「我將會抬高我做事時的態度」，可以改成類似於 「我將會把我犯得粗心錯誤寫到我的桌面桌布上，每次做相關事情前予以確認，直到三個月沒再犯，我再去掉它」
這樣，即時事情沒完成，我們也能比較自己做出的結果和當初下的定義有多大差距，為什麼會有這樣的差距，不要沮喪，再次下出定義，再次努力。
如果完成了，那麼也不要驕傲，如果相同的事還要繼續，讓我們下個難度更大的定義，繼續挑戰自我。
在與人合作解決問題的時候：敏捷開發有乙個」openness」價值觀，強調讓別人時時刻刻知道你對於這件事完成的進度，另一方面就是讓別人知道你對於這件事完成的定義是是什麼，如果對方覺得你對「完成」的定義下的不對，可以在事情開始前就來干涉，這比輸出結果後，發現不對而返工好太多了。
今天不寫第三點了，發張今天看到的
最後借用上篇總結的話：抓好每分每秒，不要問自己「時間去哪了」，然後問對的問題，解決對的問題，當然，不在於逼自己，而在於平和的堅持，這才是長久之計，血氣是不長久的。
第二週工作學習總結
第二週工作學習總結 toc 本週任務 完成情況 學習總結 基礎知識 數字用巨集，不然替換掉的時候不方便 記憶體分配 對堆的分配 陣列不等於指標 用指標儲存字串，實質在於把靜態區的首位址賦值給指標變數 資料結構內部對齊 指定位元組對齊 位元組序之大頭序 小頭序 字串拷貝與記憶體拷貝 strcpy 函式...
每週工作學習總結（3月第一周）
setrop2 函式是gdi中的函式，其主要目的是設定當前的前景混合模式。gdi使用前景混合模式來結合畫筆和物件內部填充的當前螢幕中的顏色。前景混合模式定義了畫筆和畫刷的顏色和已經存在的影象中的顏色將如何去結合 int setrop2 hdc hdc,int rop2 引數 hdc 裝置上下文的控制...
第三週工作學習總結
重寫人民幣大小寫轉換 實現20位數 20位數的大數乘法 閱讀程式設計規範 完成 現代作業系統 前三章閱讀 實現控制台列印 圖形如下 完成完成 完成完成 未完成一 函式scanf s 相比於scanf 輸入函式，可以多分配乙個單位的記憶體以保護程式的正常執行，但是不能保證結果正確 在申請最大容量時，多...