我們經常說要關注細節，這個從大的方向上來說，是沒有問題的。以前有一本書《細節決定成敗》講的這一方面。在對於某些領域，細節是需要關注的，但是不能陷入細節。換個說法，如果你一直糾結與細節的上的問題，就很難突破自己，把握全局，畢竟人的時間是有限的，能夠把握整體，抓住重點細節，關注核心領域所處的細節才是王道。
以前做過很多項目，在項目整體業務確定之后，就陷入到細節的討論之中，當一群人坐在一起，你說一句，我說一句，把大家都能想到的各種可能性都拿出來，然后你針對各種可能性找出相應的解決方案。這些細節中，有一部分是針對某一特例的，有一些是業務異常規則引起的，有一些是交互方面的，而有一些是具有抽象的，公共性質的。
在這些細節中，最有價值的就是具有抽象的，通用領域的細節，這些能夠幫助你把具體的細節抽象出共同的特性，並且可以把這些抽象細節應用於其他領域，從而能夠達到舉一反三的效果。舉個例子，在項目，我們經常會用到定時機制，一個關注的細節問題是，如果系統在維護，定時任務沒有執行，那么如何進行重試。對於某一個特定的場景，可以寫一個人工觸發按鈕。這個細節就可以進行抽象，就是如何補償由於定時機制機制異常而導致任務沒有執行這種場景，有多重方案，甚至可以開發一個專門的任務管理平台來做這個事情。類似這種可以通用和抽象出來的細節，比如業務並發控制解決方案 等，是非常值得關注和深度挖掘的。
對於某些特定場景的細節，比如我們和外部合作，定制了協議，但是對於極少數情況，不符合這個協議等，這種都是普片情況下的特例考慮，很難對這些問題進行抽象，因為這些都是對於特定領域和場景的。值能夠針對特定的細節具體分析，這一部分的價值相對比較低。只能夠加強你對某一領域了解的深度。
還有一類純粹是浪費時間的討論，這些完全是無意義的或者說沒有太多可行性的參考價值。比如頁面文本框的長度要多大，業務失敗要不要發送郵件給用戶，以及許多裝逼問題：“對於一個可有可無的功能，考慮機器斷電，磁盤寫滿等細節。
如果經常關注的第三類細節問題，就相當的無聊和無趣了，而最耗費和讓人陷入的就是第二類或者第三類細節問題的討論，這類細節問題很難幫助你或者讓你站在更高的角度去考慮問題，可以了解這一部分細節，但是沒有必要陷入這一部分細節，應該去專注細節問題的共同點，從着一些共同點中找出共性的問題並提出這一類問題的通用解決方案。