問題中描述的現象在程式設計師中很普遍。不過也跟公司的管理方式和組織結構有關係。即使在實行了996工作制的網際網路公司也是存在的。程式設計師的投入工作時間和有效工作時間很難按照1:1的方式進行分配的。因為程式開發工作不像生產流水線上的工人那樣步驟明確，操作單一。程式設計師的開發工作帶是有研發性質的，不管遇到老問題還是新問題，都會遇到新的挑戰性。為了應付這些，都需要投入一定的時間來進行知識更新。只不過有的人把知識更新放在工作時間之外，有人工作時間之外重來不學習或者很少學習，只能佔用工作時間來學習，查詢資料。所以就會形成有效工作時間和法定工作時間不一致的情況。即使是業界大牛，也很難保證投入比能夠達到100%的情況。大牛們更忙，忙於自媒體寫作，寫部落格，出書，準備各種演講走穴的ppt，透過各種途經增加自己的影響力，同樣會佔用工作時間。

有效工作時間不飽滿不代表就不是一個好員工。這個也跟個人的能力有關。有的人工作效率很高，甚至是普通程式設計師的倍數級。他們在完成當天工作的基礎上，可以騰出一定的時間來高點自己的事情。有的程式設計師效率不高，有責任心的會花更多的時間來完成工作，越忙效率越低，越沒時間學習，出錯的機率也越高。而那些沒有責任心的且效率低的程式設計師，則即使工作沒完成也要花點時間來搞事情，如看看新聞，聊聊天，工作今天完不成就拖到明天，就是磨洋工的那種。

如果以上三種情況在一個團隊中同時出現，那就需要調整管理策略來區別加以對待。一般的情況下是透過合理的任務管理來解決。工作層層WBS分解，每天寫日報彙報進度，早上開每日站會。讓大家的工作拿出來在Sunny下曬一曬，用結果說話。

1、表達能力差。做了，但說不清楚，導致介面不清晰，需要更多的溝通才能協同工作。

2、彙報不及時。做了，團隊內部也相互溝通清楚了，但不能及時告知上級，導致上級不斷追問來打斷程式設計程序。當然，這個跟組織彙報關係有一定聯絡。

3、組織彙報過多。不是在開會，就是在開會的路上。只能在夜深人靜，領導下班了，才能安安靜靜的碼程式碼。

4、博取表現。當前很多程式設計師都很“努力”。而對於一個程式設計師來講，寫出更多的程式碼也不能證明你很努力為公司做出了更多的貢獻，於是很多程式設計師就需要表現出“我很努力”，沒有功勞也有苦勞嘛。平庸的公司這種情況更加常見。