譯註：這篇譯文來自Stack Exchange上的一個提問，在許多開發者中都產生了共鳴。很多時候，作為程式設計師的我們，在日常工作中並沒有很多時間用在編寫程式碼上，而是不斷的在維護某個年代久遠的系統，不斷修正Bug，維護的專案會越來越多。如果我們希望能改進已有的程式碼，對系統做下重構，有時候並不能得到公司的支援。提問者聲稱自己的報酬非常低，但卻在做整個開發團隊級別的工作，這到底正常嗎？難道所有的開發者都是這樣的？以下兩個回覆獲得了大多數開發者的認同，想學習下如何同公司高層溝通的技巧嗎？
TiredProgrammer 6月12日：
我在一家中等規模的公司裡做Web開發。剛開始的時候，我的任務是對一個已有的應用做擴充套件（這個專案的程式碼很糟糕，是由多個程式設計師花了好幾年時間開發的，他們用不同的方法處理相同的任務，而且基本上沒什麼結構可言）。
當我成功的按照需求完成了對應用的擴充套件後，公司讓我全職負責對這個應用的維護工作。這當然沒問題，或許只有我是這麼想的。但是公司卻禁止我去改進已有的程式碼，只讓我集中精力解決bug——如果有bug報告的話。
從那時起，我又陸續接手了3個類似這樣的專案，現在我都得一起維護。之後，我又被委任了4個專案——這次可以從頭開始建立整個應用，當然了，這些新開發的專案我也得去維護。
現在，我快被每日不斷的使用者郵件給搞瘋了，我所負責維護的每一個應用都是這樣。公司希望我能直接處理這些郵件中提到的問題，同時又丟給我2個新專案（這之後已經有5個專案在排隊等著了）。杯具的是，對於我自己編寫的程式碼，我還沒有收到任何bug報告，只是偶爾會有那麼一些腦殘要求希望徹底顛覆原來的需求。
無論如何，這正常嗎？在我看來，我一個人做的工作頂得上一整個開發團隊了。我最初預想的可不是這樣的啊，我是白痴嗎？我猜這個帖子可能會引起網上的大論戰，但請告訴我，並不是每一個開發者都遇到了我這種情況。P.S. 我的薪水幾乎和超市的收銀員一樣多，如果不比他們低的話。（亮點…）
acattle最後編輯於6月13日：
我在實習的時候也發現有很多時間都花在解bug上了。你必須意識到作為初級程式設計師，你沒法獲得更有挑戰性的工作，你得從沒人願意幹的髒活累活幹起。這當然是不幸的，但這條規律適用於所有的工作。
另外，你得認識到一點，對於公司來說，能正常工作的程式碼遠比清晰的程式碼更重要。從你所在的公司的角度來看，修改已有的程式碼庫是在浪費金錢，你不過是在重做已有的東西，而且還可能會帶來更多潛在的錯誤。通常這種型別的公司都不是計算機/軟體公司，因此高層都缺乏足夠的技術背景來理解你要做的這種大改動的意義。也就是說，如果你所在的公司是技術型公司，由懂技術的人來管理，他們能夠理解好的程式碼所帶來的價值的話，你可能還會有更多的餘地，儘管有時候你還是需要選擇一下戰場（畢竟，生意的主要目的還是為了賺錢）。
那就是說，丟下你現在的工作而期望得到更有意義的工作是不合理的。同樣令人遺憾的是，你不得不同時處理由各個不同的專案經理針對各個專案提出的要求。
作為一名程式設計師，事實就是比起你自己從頭寫起程式碼的時間，你要花費更多的時間在維護和修改其他人的程式碼上。如果這對你來說難以接受，也許你應該只把開發當成一項愛好，然後選擇別的行業謀生。如果你對維護程式碼沒有什麼異議，但感覺工作並沒有使自己發揮出全部的功效，或者覺得自己快被工作榨乾了，那麼你需要同你的經理好好探討一下你的工作模式。如果你面臨的問題比這個更嚴重，或者如果你感覺經理並不知道如何有效的根據你的技能來管理你的工作，那麼考慮換個新公司應該是個好主意。根據你提到的低工資，跳槽可能是你現在最好的選擇。
Péter Török最後編輯於6月13日：
看起來似乎是管理層在任務優先順序的選擇和工作量的管理上出了問題。你應該同你的經理談談，讓他們知道你的工作已經過載了，如果每個人都跑過來煩你，讓你完成他們馬上想達成的要求，這樣你就無法繼續有效的工作了。那樣會讓你從一個任務跳到另一個任務，浪費了大量的時間在切換思維上。對於高效率的軟體開發工作來說，你應該只全身心投入到一項任務中去。有越多的中斷和干擾，你就要花越多的時間在環境切換上。有研究顯示，大約15分鐘的時間能讓你進入專注的狀態，此時你的思維是最有效率的。如果你每15分鐘被中斷一次，你永遠也無法專注下去，這對你和公司都是很大的浪費。
因此你應該試著和你的經理溝通，達成一個更加合理的工作模式。這應該包括對任務進行優先順序劃分，並在某種程度上提前進行規劃。所有的使用者需求都應該按照優先順序的順序記錄在列表上。並且，優先順序不應該由需求的發起者來指定（自然地，大家都會認為自己的需求是世界上最重要的），也不能由你自己來定，而應該由某個擁有足夠多的商業知識以及對你維護的一系列產品有著全域性認識的人來指定（產品經理）。理想情況下，所有的需求請求都應該被錄入到問題追蹤系統如Jira或者Mantis上，或者至少給產品經理髮送郵件，而不是直接發給你。應該由他/她去負責處理 “為什麼我的需求還沒有完成？”這樣的使用者抱怨，而讓你集中精力在開發工作上。如果這種情況難以實現的話，當你在處理新的需求時，你至少要和經理溝通協商出一段時間，這段時間內你不能被打擾，只負責開發工作。
如果上面的做法可行，下一步就應該是提前做好規劃。比如，估計一下完成最高優先順序的任務需要多少時間，然後將你的時間劃分為各個“衝刺階段”，每個階段可能是1周或好幾周時間，為你的下一個衝刺階段安排滿足夠多的任務。你可能還希望保留一段時間以應對緊急的需求，但其餘的都可以提前規劃好。你也可能更希望將不同專案的工作劃分到不同的時間點上，比如，專案A就安排在周1解決，周2到周3是專案B，周4上午可以做專案C，下午就可以做專案D等等，以此進一步的減少任務間的切換。按照這種方式，你對於未來1周或幾周的工作任務就有了大致粗略的瞭解。此外，這也為你的客戶提供了一個路線圖：他們可以瞭解到他們的請求何時可以得到解決。這裡你可能不會想對你的經理提到“敏捷”這個詞——這基本上就是敏捷開發，但有些人並不清楚敏捷開發到底是什麼，他們就是一味地反對。
儘管你現在的職位看起來報酬很低，可是你維護的專案越多，你就越有資本來溝通協商。對於公司來說，招一個新人進來給他培訓，再讓他維護所有這些專案需要花費相當長的時間（時間就是金錢）。你可以正當的指出你的程式碼比原有的部分要好的多，所以從公司的方面來說，他們沒法輕易的以同樣的價錢僱到一個合適的候選者來完成同樣的工作。更不用說如果他們不改善工作條件的話，他們僱到的下一個傢伙很快也會像你一樣受夠了就退出不幹了。試著讓公司懂得讓你快樂的留在公司對公司是最有益的。這會給你一些資本來和公司協商以上的情況，並要求加薪。
你究竟有多少談判的資本——這是個大問題。管理層可能會也可能不會對你的請求有足夠的尊重。但如果你把握的夠好的話，你就有機會。如果他們拒絕，你總是可以再去尋找更好的工作。這種情況對於每個職場菜鳥來說並不相同，雖然（很悲催的）你的經歷是相當典型的。但是確實總是有更好的工作地點在那等著。工作場所的好壞同地理位置的關係聯絡並不大，但給我的感覺是，在歐洲北部你可以獲得的機會比平均水平要高一些。因此，在你完全受夠之前，如果你無法顯著改善現在的工作條件，你應該馬上開始尋找新的工作機會。騎驢找馬總是很好的，所以你不要因為需要用錢就立即接受第一份offer。最終你總會找到一個更好的去處的。