程式設計對很多人來說有點神秘。這就造成了在公司內部，人們對程式設計的事情產生了很多懷疑和疑惑。 通常，當你不了解乙個東西是怎樣做成的時，你只能說：可能是這樣吧。 如果你從沒見過工地，你也許會認為幾個星期就能建出一棟大樓。事實上，在這樣的時間內是可以完成這棟建築的，只是能不能用就不知道了。如果你看過房子如何 建造，跟蹤它的建造過程，你能從物理實物看到地基如何澆灌，鋼架結構如何搭成，等等。但給電腦編寫程式，或建設乙個**卻是不可見的。 除了程式設計師外，程式**對其他人來說是接觸不到的。程式的執行好像是大幕後發生的魔術戲法。只有開發團隊的成員才能知道程式是什麼，怎麼工作 的，不能幹什麼。從程式設計師的角度看問題，你就能得到最好的開發結果、專案評估資料和進度更新。很多的a型性格的人對此不以為然，但事實毋庸置疑。
當客戶提出他們想要什麼東西，而且要在什麼時候完成時，問題就開始出現了。銷售人員希望做成這筆交易。拜託，請告訴客戶，他們的想法不現實，這 個生意做不了。這樣做下去只能導致一場災難。我曾看見過工程統計部門把估算的工期消減一半，四處花錢去達成他們的銷售，完成他們的任務。直到最後有一天， 事情的發展看起來都是程式設計師的錯造成的。他們這樣做結論是因為程式設計師是最容易責備的。
程式設計師們在學校裡沒有學過辦公室政治學。他們應該學，當然這是另外乙個話題了。作為乙個程式設計師，他需要集中精力，沉著的思考，去開發出清晰好用 的程式。這是個困難的事，需要用去你全部精力。程式設計師們沒有時間去理會是誰背後給了自己一刀。可工程部門玩的這些遊戲卻有嚴重的後果。
我的前乙個公司，乙個百萬美元的專案，熱熱鬧鬧的，像煙火一樣，短暫的光華後就落到地上了。 什麼原因？是這個公司指使程式設計師們每週工作70小時以上去完成客戶專橫的進度表導致的？還是工程部門對客戶言聽計從導致的？
我也不認為開發人員沒有任何責任。如果你看過電視劇集seconds from disaster，你會明白，災難的發生是一群人都沒有做自己該做的事情導致的。但是，我可看見程式設計師們都在做他們自己的工作。而其他人都在幹什麼呢？
那麼，公司是怎麼認為的？他們解雇或開除了所有的程式設計師。然而整個工程部卻沒事。這次攻堅戰的慘敗後，也沒人願意留在那裡了。
程式設計師被打入地獄的過程都是有乙個個的「遵命」鋪就的。為了對得起自己，對得起自己的職業，程式設計師應該警惕那些危險的事情。評估分析，評估工作 通常會花掉很多的精力。據我所知，這個比任何事情都要費神，它需要你從多個層面去考慮整個事情。不幸的是，我曾親身經歷優秀的評估報告被駁回或修改。評估 的越符合實際，招惹的眾議越多。
把符合實際的預期報告告訴使用者是個困難的事情。這會使生意的成交增加困難。程式設計師在承擔其他人冒險的後果。程式設計師的工作從來不輕鬆。事實上，程 序員是乙個公司裡對這個事情看的最清楚的人。他們懂編碼，知道需求業務。他們也許不善於和客戶打交道，但他們卻真正知道專案應該怎麼做。
重視你們的程式設計師。他們不僅僅是個技工，他們也是懂業務的。他們能憑藉自己的經驗判斷出，
程式設計師，請盡早修復你的Bug
一旦進入軟體開發的生命週期，bug就不可避免地隨之而來。關於是在軟體開發生命週期的早期還是後期 實施和發布後去修復bug的問題上，產生過許多激烈的討論。軟體開發人員總體認為早期修復bug是最優的策略。無論是在哪個發展階段，修復bug都非常耗時，而且置之不理會產生一定的成本。越到後期去修復bug，出現...
程式設計師要重視什麼？
b 1.基礎理論 b 就是大家常說的 作業系統原理 計算機系統結構 編譯原理 資料結構和演算法 資料庫原理 計算機網路原理 等等，很多做應用開發的程式設計師認為這些幾乎沒用 這些對做底層系統開發的程式設計師來說幾乎是必不可少的 講究速成的培訓班也不會開這些課程，中國正規計算機專業的學生也有很多對這些...
請不要再責怪你的程式設計師「太慢」
為什麼上週沒發布？作為管理人員，很容易將延遲發布的責任歸咎於開發團隊成員。但是你是否有認真想過，這些 慢悠悠 的程式設計師是否真的是不能按時發布的真正原因？我們採集了大量關於程式設計師開發周期的資料，主要記錄他們需要多久才能完成不同型別 stories tests bugs 和不同大小 s m l ...