相比於產品、測試、監控和運維等其它人員，程序員的工資可能相對高些，但地位看上去真是最低的。下面來通過一些例子來說明。
1 開始了一個版本週期，前一週，程序員會被要求參加各種需求評審，架構評審會，會上會被輪番施壓，不僅會被要求做盡可能多的需求，而且會被要求實現各種高難度的功能。
還不能有討價還價，如果一旦有，產品就會拉上更大的老闆來施壓，畢竟實現更多更完美的功能，產品才能掙到更多的錢，所以在這個時間點上，大老闆總是向着產品，一起給程序員施壓。
2 開發階段尚屬獨立，程序員還能自主些，雖然在開發過程中，不同的組之間需要協調接口，或者需要在數據庫等方面相互調用，程序員之間也會扯皮，也會有矛盾，但這畢竟屬於程序員內部的矛盾。有時候想想，程序員何苦再爲難程序員。
3 但在已經制定好開發計劃測試計劃和發佈計劃的情況下，產品方總會想些辦法來插入些額外的需求。這時，程序員能反駁的餘地也很少，大多也只能逆來順受，通過加班完成這些額外的需求。
4 開發好了，進入測試階段。這個階段，只要是測試，不管測試人員資歷有多淺，都可以開bug，或者有任何性能等方面的問題，測試人員都可以提。
可能有些bug很難重現，或者有些bug很難改，但程序員在和測試交流過程中，絕對也處於劣勢地位，只要測試能通過截圖證明有問題，哪怕只出現一次，程序員就得改。
5 上線前和上線時，程序員會被運維人員叫到一邊聽候調遣，發佈沒事最好，程序員頂多就只是枯坐一段時間。但如果有問題，那對不起了，程序員就得立即排查問題。這時就會面對來自老闆、產品、測試和運維人員的多重壓力。
6 哪怕就在平時，不管上班時間還是下班時間，只要線上爆出問題，或者客戶在羣裏提了，監控人員馬上就會呼叫程序員上線解決問題，如果不解決，會有更多的人介入，介入的人都能對程序員指手畫腳。
通過以上對程序員日常工作的描述，大家能看到，在項目計劃、開發、測試、上線和運維等階段，程序員經常會被各種各樣的同時“呼來喝去”。但是反過來說，這恰恰是程序員工資高的原因。而且，經常被呼來喝去的程序員，反而能以較高的效率來提升能力。
一方面，正是因爲程序員職責範圍大，所以看上去會被其它同事吆喝。另一方面，如果程序員本身平時摸魚，得過且過，出了問題往後縮，那麼也不會被其它同事“指使”。
其實事情如果反過來看，每次程序員被指使，其實程序員就得到了一次能提升能力的機會，比如能參與架構討論，參與排查解決問題，參與維護項目。而且程序員在被諸多被指使的過程中，不僅能提升技術能力，更能提升溝通、運維和產品策劃等方面的能力。
這樣久而久之，程序員的身價就提升了，當公司給出的工資無非匹配程序員的身價時，程序員就跳槽了，到工資更高的公司裏去“被吆喝解決實際問題”了 。
可能有些程序員會說，我在公司裏“受苦受難”很久了，但能力和工資一直無法提升，這些程序員可以從如下方面做些改善。
1 程序員遇到的這些問題，或者程序員被指使的情況屬於客觀情況，程序員主觀上再排斥，這些問題照樣會來，而且主觀上排斥了，問題反而解決不好，解決的效率會更慢。
所以主觀上，程序員應當把各種問題，甚至是各種磨難，當成提升能力和提升工資的磨刀石。
2 在解決問題後，多覆盤，或者遇到自己暫時無法解決的問題，在別人解決後，覆盤下人家的方法和思路，這樣下次遇到類似問題，就可以依樣畫葫蘆，以後再多操練幾次，就能熟能生巧，慢慢地，技能就上升了。
3 程序員受到的指使會很多，對應地，遇到的問題也會很多。所以程序員更應當會區分低價值和高價值問題。比如解決線上問題的過程、設計整體架構或者用分佈式組件實現高併發，這些屬於高價值問題，而重複性地討論需求，重複性地設計接口和模塊等問題，這些屬於低價值問題。
區分好以後，可以區別對待，多覆盤高價值問題，或者高價值問題中的每個細節都搞明白，這樣也能較快地提升能力。
4 當然，如果公司一方面無法再給予程序員提升能力和工資的空間，另一方面，還再繼續變本加厲地壓榨程序員，那麼程序員就可以跳槽了，就沒必要還在這種公司裏被呼來喝去了。
這是我的公衆號，其中包含了大量面試文章，同時我自己出了多本Python和Java方面的書籍，會定期在公衆號裏發書的電子版。請大家關注下我的公衆號，謝謝了。
