Hiro的部落格

7月 13 週五 200708:45
與使用者溝通十種最糟的方式

本文: Becky Roberts, “The 10 worst ways to communicate with end users”

譯 : Fred Wang (http://fredwang.blogspot.com)

1. 不洽當的肢體語言

當使用者問到一個您覺得很蠢的問題,不要輕視, 因為您的表情, 口氣可能都會讓使用者感覺受到傷害, 應該藉此當作教育使用者的機會, 讓他們把您當成重要的內部顧問

2. 賣弄

我們在技術領域可能會接觸到許多的專有名詞或觀念, 但是並不表示跟使用者溝通時要用到這些東西. 這些技術名詞雖然可以提高使用者對您的專業印象, 但是往往也會讓人有高傲或自負無法接近的感覺. 例如告訴使用者清除browser cache以解決browser的問題, 教使用者一步一步的操作過程會比告訴她們 ”cache”, ”template file” 等專有名詞更切合使用者的需要.

3. 失去耐心

即使在電腦使用如此普及的年代仍有少數人使用電腦上無法輕鬆上手, 處處需要IT人員協助, 背後罵罵他們可能暫時消消氣, 但是如何避免激怒使用者, 並提供基礎的訓練與指引才是最好的方法

4. 表示輕視

想像當您因為手上長了一個青色的腫塊, 但是醫生只是拍拍您的肩膀說, ”不要擔心如果一兩個月內它沒有消失再來找我” , 您的感受如何, 同樣您如果告訴使用者一兩個月電腦當機的情況沒有改善再來找我, 也許您覺得沒什麼大不了的, 重開機就好了, 但是使用者可能覺得這對他的工作影響很大, 可能辛苦做到一半當機, 所有作業必須重來. 因此雖然是小問題, 協助使用者解決小問題將可以增加使用者對您的信賴.

5. 缺乏告知

完成使用者的需求過程與使用者溝通是必要的過程, 工作完成後的通知或延遲的通知更是重要,如果您預先告知使用者, 通常工作延遲多可以被接受

6. 缺乏文件

如果許多操作程序, 公司電腦使用規定等都能文件化並持續更新且讓使用者能容易的取得, 將可減少大量處理或回答使用者問題的時間

7. 欺騙

多年前作者遇到一個資深的技術支援者, 他習慣將使用者的問題歸咎於微軟, 然後使用者就不再提問題了, 因此他覺得自己工作很有貢獻, 因為使用者的問題變少了, 這種狀況直到一次IT組織改組後, 他被指派的服務的使用者對電腦的了解較深且希望得到更多的服務與重視, 幾週後他因為大量的抱怨與自己落後的技術能力而離職.

8. 給太多的資訊

誠實是最佳的策略, 並不表示所有的資訊都要塞給使用者, 一個媽媽告訴15歲的的孩子她的經驗, 平均一次只能聽進三句話, 因此, 限量的溝通是必須的, 但是不要期望使用者一次能吸收太多的資訊, 例如寫電子郵件告訴使用者某系統升級的必要, 如果信件過於冗長, 通常使用者看了前面幾句就略過此信, 不如條列重點幾句就可以.

9. 不提供訓練

訓練不限於一定要在訓練教室三小時的課程, 有時一個小的作業在座位上簡單的示範也是一種訓練

10. 缺乏傾聽

溝通是雙向的過程, IT是支援單位因此傾聽使用者的需求是必要的, 在時間允許下多聽聽使用者的日常作業看看有哪些地方IT可提供技術可提高他們的生產力, 安全性或競爭力

posted by FredWang

文章來源 Fred Wang 網誌

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(43)

個人分類：文章分享

▲top

7月 06 週五 200723:36
一個程式使用者的技術問題

【笑話轉載】一個程式使用者的技術問題

今天又在公司的OUTLOOK看到同事轉寄的笑話，真的是令人噴飯，再轉貼上來分享一下：
有一個在某知名網站任職的員工Joe，他發生了一些問題，於是他就寄了一封信給公司的技術支援人員...
親愛的技術支援部門：
您好，我現在急需您的幫助。我前陣子才將「女友7.0」升級到「妻子1.0」。發現這個新程式毫無預警地啟動了「孩子1.0」這個外掛程式，因此佔用了大量的空間和珍貴的資源。這在產品的使用手冊中沒有提到。另外，「妻子1.0」將自己自動複製安裝到系統中的所有程式中，它會隨系統同時啟動，監控整個系統的狀態，我的系統防火牆也因此失效了。
我平常休閒娛樂時常用的「午夜狂歡2.5」和「夜店激情2007」執行檔完全失效了，一旦執行該程式，系統即自行崩潰而當機。有時試圖執行「週日足球6」或是「週六職棒大聯盟2007」經常失敗，而且會變成啓動「瘋狂購物王7.1」，這個程式非常消耗我寶貴的資源。
看來我無法保留「妻子1.0」這個程式，因為它和我平常喜歡使用的任何程式都不相容，此外我的哥兒們都懷疑「妻子1.0」其實根本就是「木馬病毒」。我打算回到「女朋友7.0」的程式就好，可是發現「妻子1.0」這個程式居然無法解除安裝。
請您幫幫我吧！
系統無法有效運轉的Joe

後來，技術支援部門收到這封信後，寄出了一封回覆信給他：

Dear Joe
這其實是個很普通的問題，產生於你對基本使用原則的不瞭解。
很多的朋友將「女朋友7.0」升級到「妻子1.0」，以為「妻子1.0」是一個「實用與娛樂兼具的好程式」。然而「妻子1.0」其實是一種作業系統，是被設計用來執行所有程式的，也就是說它會取代你原來的作業系統。你不可能清除「妻子1.0」，也不可能回到「女朋友7.0」，因為「妻子1.0」的設計中不具有這個功能，無論是解除安裝、刪除或是清除已經安裝在系統中的這些程式檔案，都是不可能的。
有些人曾試圖安裝「女朋友8.0」或者「妻子2.0」，結果產生了更多的問題(參見手冊第158頁中的【贍養費用/孩子養育費/律師費用】單元說明)。我安裝過「妻子1.0」，建議你保持現在的安裝狀態，妥善解決遇到的困難，例如將無法正常啟動的程式乾脆完全刪除。
當任何錯誤或問題出現的時候，不論你認為是什麼原因引起的，你都必須立即執行「C:\我道歉」的程式指令，並且避免使用「退出鍵」。必要時可能需要執行「C:\我道歉」指令多次，希望最終能使「妻子1.0」作業系統恢復到初始狀態。
「妻子1.0」雖然是一個需要經常保養的程式，但同時對使用者的生活及精神上可能是非常有幫助的，請充分且有效的運用它。為了「妻子1.0」的效能，你需要不定時下載更新檔來維持系統效能及程式運轉，不過這些更新檔是需要付費安裝的，例如「flower.exe」、「gift.exe」或者是較高價的「LV.exe」、「Gucci.exe」等更新檔。
請不要在任何情況下安裝「女秘書　超火辣豪華版」，還有你信中所提到的「狂歡系列」與「激情系列」相關程式，因為「妻子1.0」非常不支援這類型的程式，系統多數時候肯定會當機甚至失效。
祝您好運！　很高興能為您服務！
P.S 相信如果你有詳閱產品支援手冊應該要了解，「妻子1.0」是不提供保固及售後服務的，但基於同情的心理我們非常樂意提供使用上的意見。
技術支援部門敬上

文章來源阿飛不會飛

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(16)

個人分類：文章分享

▲top

7月 06 週五 200722:25
善用時間

花點時間工作，那是成功的代價；

花點時間思考，那是力量的來源；

花點時間讀書，那是智慧的基礎；

花點時間愛人，是你被愛的保證；

花點時間歡笑，那是靈魂的音樂；

花點時間遊玩，那是青春常駐的秘訣；

花點時間與人結交，那是通往幸福之路；

花點時間夢想，那能使你摸到天上的星星。

文章來源善用時間

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(13)

個人分類：文章分享

▲top

7月 04 週三 200701:48
善用經驗學習

⊙善用經驗學習
「不經一事，不長一智」

「不經一事，不長一智」這是古之明訓。「我走過的橋多於你走過的路；我吃過的鹽，比你吃過的飯多。」這是「依老賣老」、「嘲笑別人」的狂語，這種事件，經常發生在我們日常生活的周遭，簡單的說就是「經驗」的多與少而已。「經驗」一詞指個體在生活的活動中所經歷的一切事故，是指活動的結果；另指個體在生活中為適應環境要求所從事的一切活動，是指活動的歷程。換言之：經驗是個體在生活中的活動歷程或結果。誠如俗語所說：「凡走過必留下痕跡。」此「痕跡」可以說就是經驗。此經驗是個體親自體驗而得，另外經驗亦可從書藉或別人的作為而獲得。

經驗要與學習相結合，才能獲得正向、美好或良善的成果。因「學習」旨在達成個體在知識、技能、情感和態度的改變。亦是由經驗而獲得知識或行為改變的歷程。坤良在國立高雄師範大學成教所進修時，師長的教誨：「成人的學習要善用經驗和資源。」即成人要能結合過去的經驗來學習，因而對事理的瞭解、事件的詮釋會有較周延的觀點與看法，因而在待人處事上亦較能「通權達變、知所進退」。

經驗有美好或痛苦的、有成功或失敗的，無論如何，經驗將影響我們的生活或作為。如因「守株待兔」而終日無成，「一朝被蛇咬，終身怕草繩」等。倘若能將成功或美好的經驗繼續發揚光大，踩著成功的軌跡，依循成功的經驗，終將有所作為。反之，將記取失敗或痛苦的教訓，痛定思痛、檢討反思、繼續奮鬥，亦終必有成功的一日。因之，經驗的重要，經驗與學習結合更是重要，坤良謹就經驗學習之心得，從「認識經驗與學習的關係」和「善用經驗學習」兩方面，簡述如下：

一、認識經驗與學習的關係

經驗與學習的關係至為密切，因為： (一)學習是經驗不斷的改造：如林德曼(E.Linderman)的經驗主張，提出「經驗是成人學習者活的教科書」。教育家杜威(John Dewey)的「教育是經驗不斷的改造與重組」，教育是「屬於經驗，由於經驗和為著經驗」的。由此可知，成人學習是與經驗結合，在既有經驗基礎上不繼的改造與重組

(二)經驗是學習的重要資源：學習既是經驗的改造，成人如摒除經驗，則學習是空乏的，如諾爾斯(M.S.Knowles)提出成人教育學的重要特色之一是成人具有豐富而多樣化的經驗，且經驗是學習的重要資源，透過經驗的分享，成人即可從中學習，獲得實用的知能或達到態度的改變。

(三)經驗也可能是學習的阻力：並非所有的經驗均具有教育性，有些經驗是違反教育而導致經驗不良的發展和未能使經驗成長，或者個體先前所獲得不正確的經驗而形成「先入為主」的經驗，都會造成學習的阻力

由此可知，成人學習以經驗為基礎，並力求不斷的重組與改造，同時將經驗視為重要的學習資源，而在學習中，過去的好壞經驗都影響到學習的結果，甚至有時變成成人學習的阻力，可見成人的學習和經驗是無法脫節的。

二、善用經驗學習

經驗是成人學習的重要特徵之一，經驗有助於成人的學習，而學習事實上就是經驗不斷重組與改造，因之，如何協助成人從經驗中學習，積極記取教訓，免蹈覆轍，如何讓成人善用經驗學習，有如下三點看法：

(一) 學習教材、內容與學習者經驗相結合新教材要產生意義，一定要以學習者過去的學習和經驗為基礎，將學習的理論與實務相結合，讓經驗與學習產生交互作用，也就是將學習的教材或學習的內容，在舊有的經驗中找到類化而結合，以增進學習者編輯記憶，並促進加速學習與應用

(二) 創造新的經驗經驗學習並非完全要親自體驗，有時為產生新經驗，可以設計活動包括模擬、遊戲和角色扮演等來增加經驗的分享機會。例如角色扮演可以讓參與者彼此相互體驗角色功能任務；模擬情境增可進新奇事物的認知；遊戲可學習到規則或合作互動等德性。創造新的經驗旨在擴展學習的視野，增加學習的深廣度或效能，以利於生活的充實和昇華。

(三) 經驗要反思與轉化實踐經驗不經反思或轉化之學習，是貧乏而空洞的，其利用價值不高，誠如柯伯(D.Kolb)的經驗學習主張，其認為經驗學習是：以「具體經驗，反思的觀察，形成抽象概念與類化，行動實驗」等四者的循環模式。也就是說經驗學習始於個人的「具體經驗」，再次為個人進行「觀察和省思」，因而獲得「抽象概念並加以類化」，最後在新情境中檢視概念的正確性，此四種循環即產生新經驗。經驗經過反思和轉化，才能去蕪存菁，讓自己永遠居於有利或成功的位置。

成人由於善用經驗的學習，因而在成功的經驗道路上昂首闊步繼續前進，也因失敗的經驗而檢討反思、觀點轉化、記取教訓而重新出發，再次導向成功勝利的行列

總之，成人的經驗學習是促進生命的開展，是擴展生活的領域，在良好的經驗中享受成功勝利的美果，也在失敗的經驗裡，檢視歷程，反思價值、方法與態度，因而轉化念頭或信念，重新找到核心價值或平衡的焦點繼續學習，仍然能獲得成功的勝利。孟子的「吾日三省吾身」，也就是經驗的反思。志工伙伴們！讓我們珍惜「寶貴的經驗」，隨時與學習相結合，在順境中繼續前進，邁向成功的目標；在逆境中要反求諸己，轉化觀點、學習典範、見賢思齊、把握機會，相信成功會伴隨而來。總而言之，「經驗」告訴我們，善用經驗學習，人生一定有出息！您說不是嗎！

文章來源善用經驗學習

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(789)

個人分類：文章分享

▲top

6月 26 週二 200704:24
從程式設計師到創業家

06/11/2007

從程式設計師到創業家

■ Ian Landsman
有許多程式設計師都想成為創業家。雖然我個人不是「硬派」的程式設計師（所以即使你把我鎖進地下室一個星期、只丟一箱咖啡或可樂給我，我也變不出10萬行的程式），但卻也曾經歷這個過程；從過去幾年經營HelpSpot的創業經驗之中，我瞭解到許多程式設計師創業失敗的原因，而以下幾點就是我的觀察：

程式碼只是生意的5%

在我所看到的許多失敗因素之中，最大的一個是設計師往往身陷在程式碼之中，花費無數個小時想讓某個功能完美無瑕、或是想運用最新的技術來傲視群雄；當然，做軟體就必須寫程式、而且最好是品質和安全性俱佳的程式碼。
然而，如果沒有人知道你的產品，就算寫出全世界最讚的程式也是枉然；如果你因為沒錢繳稅被國稅局抓去關，再多程式也救不了你。如果你因為沒有適當的軟體授權而不得不打官司，程式碼一點意義都沒有。

我在論壇上和個人網站上看過太多創業者，在應該討論和學習如何做生意的時候，卻聊程式聊得天花亂墜；當然，要程式設計師聊程式當然比聊生意經輕鬆，但對於任何人來說，做生意都不是輕鬆的事情！

設計就是一切，而且可以提升競爭力

無論你的產品是什麼，都必須擁有好的設計；光禿禿的方塊和灰色的背景是不夠的。記得，你的產品要設計得比競爭對手更好，才可能有機會。
如果你做的是後端資訊管理系統，當然不必做得像專業美術軟體那麼漂亮，不過如果做得到的話更好；重點在於讓潛在客戶能清楚的感覺到，你的產品設計得比競爭對手更好。說真的，大家其實都是以貌取人，看軟體的時候也一樣。

養成長遠思考的習慣

每一位程式設計師都喜歡一口氣把程式改好、找出所有的臭蟲然後一舉消滅。然而，即使在小規模的系統開發商裡頭，非程式設計的工作往往不能操之過急；所以從經營的角度來說，一定要習慣長遠思考。
像是行銷活動、或是產品定位之類的工作，往往必須花幾個月、甚至幾年的時間才能完成，跟寫程式的立竿見影是不一樣的。所以，你必須強迫自己往遠處看：六個月之後，你希望自己的產品、行銷、以及業務是什麼樣子？

承認吧，你不瞭解使用者

有時候，你所寫的軟體並不一定應用在你熟悉的行業；這其實是個好機會，但你要做的絕對不只是做點市場研究而已，你還必須瞭解真正的使用者，最好能找機會跟他們交談。
我知道你也許不想做這些事，但你非做不可；因為如果沒有和真正的使用者交換過意見，你就不會知道做哪些功能是在浪費時間、哪些原本沒有的功能其實才是最重要的。
許多人常常犯一個嚴重的錯誤，就是把競爭對手產品的全部功能當作自己的起點。這個作法很不好，就像是抄同學的作業一樣，而且往往兩個人都錯在同一個地方。跟你的顧客好好談談，你就可以避免競爭對手已經犯過的錯誤。

愛你的客戶

許多軟體開發商在創業之前，都有後端辦公室系統IT部門的工作背景。在我工作過的許多這類單位之中，IT人員對客戶（經常是企業內部的用戶）的觀感都不好；道理很簡單，因為他們被要求做的事情太多、而報酬又太少。
不過既然要自己創業，就得把這些過去的恩恩怨怨擺在一邊。我看過許多軟體商把過去的觀感帶進工作之中；然而，這種成見在商業軟體的世界裡是不該存在的。成功創業的重要條件之一，是要愛你的客戶；也就是滿足他們的需要、而且盡一切能力做到。
如果你做不到，就得準備好你的理由；假如顧客最後選擇競爭對手的產品，請尊重他們的決定，但告訴他們如果對方的產品無法滿足需求，請他們回來找你。
在我的經驗中，許多生意之所以能失而復得，往往只是在顧客選擇離開的時候對他們同樣有禮，如此而已。

盡可能設計得容易使用，讓高手也喜歡

不要讓使用介面迷失在酷炫的科技之中，越簡單越好；無論新手或是老手，對於簡潔介面的喜愛都是一樣的。
至於之所以要盡量簡單，主要原因是在於讓試用的人容易上手；試用者只會給你的產品幾分鐘時間，如果你的設計太酷太炫太複雜，等於在浪費這寶貴的幾分鐘。如果你浪費他們的時間，他們就會去找別人。

從其他人身上找靈感

你可以經常找個和進行中產品無關的人，把最近的測試版本展示給他看。有時候「外行人」的眼睛反而勝過「明察秋毫、不見輿薪」的專家，能找到產品和介面中的大漏洞。
即使不瞭解這項產品的應用領域，有時候他們發現的問題往往是你作夢都想不到的！

不要害怕拿下某些功能

作為一位程式設計師，我也很討厭把明明寫得太棒的程式碼從產品中拿掉；但沒辦法，有時候就非得這麼做不可。在開發的過程中，你一定會發現一些其實一開始就不必做的功能。理想狀況下，能在交貨前就發現是最理想的；一旦發現了，就最好在它們造成麻煩之前趕快拿掉。
舉例來說好了，當我在開發HelpSpot的程式時，發現用來將顧客資料讀進系統的功能竟然不會動；其實這項設計並不好，有了它反而會把HelpSpot變成一套四不像的顧客關係管理（CRM）系統。
因為如此一來，我的客戶就必須將放在HelpSpot上的資料跟公司裡真正的CRM系統隨時保持同步、而且會把HelpSpot的操作介面變得太過複雜；所以我最後決定犧牲幾個星期的工作成果，把這項功能整個拿掉。
事實證明，這是我做過最英明的決定之一；與其要客戶保持兩個系統的資料同步，我設計了一個即時查詢（Live Lookup）系統，讓顧客直接在HelpSpot中執行查詢原有CRM資料庫的指令。這項獨特的功能後來非常受歡迎，大多數客戶安裝的HelpSpot系統上都經常使用它。

耐心是一種美德

要有足夠的時間把一切該做的事情都做完，往往是很困難的；很多原本我們以為幾天可以做完的事情，往往得花上幾個星期，你要學著多點耐心。
要不是焚膏繼晷把事情拼完，就是得為了進度落後而懊惱；如果可以的話，不要讓顧客設定日期、或是有過多期望；如果是可能三個月才做得完的工作，不要答應一個月就完成。在這一點上，連我自己都還得多加把勁。:-)

用從頭學習寫程式的心態做事

當你剛開始寫程式的時候，一定是抱著每一本相關的書猛啃；你會買整堆內容大同小異的程式書，但還是每一本都讀完，因為你覺得自己再怎麼讀都不夠。
在從程式設計師到創業者的心態轉換過程中，你需要這樣的初衷；你需要熟讀每一本描述目標市場的書，無論是經營中小企業、行銷、一般管理、時間管理等等都好。事實上，你最好在寫創業之後第一支程式之前，就把這些書都讀過一遍；因為透過這些知識所能避免的錯誤，絕對值得你花這些時間和精神。

文章來源工作技巧

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(426)

個人分類：電腦和網際網路

▲top

6月 26 週二 200704:22
程式設計師的類型

程式設計師的類型

FireFoxer | 01 Apr, 2007 11:08

程式設計師的類型
前前後後跟五十多個程式設計師共事過，有三十多歲的，也有剛退伍的，也有剛畢業的女生，每個人的個性、背景都不一樣，我大致將他們分成以下幾型：

公務員型：

每天準時上下班，程式設計量與老板交待的工作量比起來不多也不少，一般這種是有點年紀的，如果是年輕的通常不外有幾個原因：有女朋友、自己下班時間兼差、或是對程式設計沒有什麼興趣…等。
精實型：

除了完成老板交待的工作之外，空閒時還會不斷的看電腦雜誌及電腦書籍，下班後還會想到工作相關的電腦問題。每天掛在網路上，逛遍各大IT網站，到各技術論壇註冊帳號發言，書籤裡都是名人的BLOG網址。
口才型：

"說"的一手好程式，對許多電腦技術和電腦公司都可以批評得一文不值，常常連自己公司也駡進去，以為自己是天下第一，一直到換了新的工作環境，才會發現自己的渺小；有的仍然繼續大言不慚，繼續用嘴說程式。雖然許多程設人員都會瞧不起這類型的人，但必須接受的事實是，他們的日子也過得很好。

天才型：

自己想破頭的技術，一問他就豁然開朗；再難的問題，碰到他都能在談笑間強虜灰飛煙滅。以為自己打字已經可以用飛快來形容(唬住一票女生)，在他眼中看來卻成了慢動作。剛認識時覺得他是心頭大患，嚴重威脅到自己的地位；認識久了之後覺得自己何其幸運，有這麼讓人放心的後援部隊，就像是"The last defense line of the country"般的英雄。可惜，這種人實在百中難得碰到一個。

文章來源專案人生

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(178)

個人分類：電腦和網際網路

▲top

6月 26 週二 200703:06
做一個快樂一生的程式師

專家評論: Scott Johnson：做一個快樂一生的程式師
IBM WebSphere 開發者技術期刊

級別: 入門
Scott Johnson, WebSphere Application Server JSP 團隊負責人, IBM
2005 年 8 月 17 日
快樂的程式師知道自己的擅長之處，也知道在那個他/她期望的有些像天上掉餡餅一樣的工作中到底涉及到什麼。受一篇關於普通程式師急於學習程式設計的文章的啟發，作者就此與我們分享了他的觀點。
高速通道和長途旅行
就程式設計，電腦科學博士、Google 的 Search Quality 總監寫了一篇很不錯的文章，名為“Teach Yourself Programming in Ten Years”。這篇文章中提出了一個大問題：為什麼人們這樣急於學習程式設計呢？是因為他們希望能夠速成呢，還是因為大家認為電腦是最容易學習的？不管什麼原因，做一個好的程式設計師並非快速學習的結果，而需要深入認真學習，並需要明智地選擇學習的內容。關於這點，本文給出了六條建議，供那些準備開始（或已經開始）用一生的時間實現做個好程式師的夢想的人參考。

通過好的例子學習
有些程式設計師很幸運。他們有良師指導，能告知他們成功解決軟體設計和程式設計的各種成功方法。他們學習了如何區分設計的好壞，如何辨別耐用的實現與不可靠的實現。他們的導師還對如何在編程領域謀得良好的職業生涯給出了建議，而且他們還瞭解了如何才能獲得成功和認可，應該接手哪些項目，應該避免參與哪些項目。
有良師的指導效果非常好，而且很有必要。如果有兩個程式師，並給其中一個指派了好的導師，有人指導的程式設計師將不斷進步，而沒有人指導的程式設計師則可能會手足無措地原地踏步。

透過反面例子學習
不過，如果沒人指導的程式師瞭解如何“自救”，他便能夠發現學習程式設計技巧的很多其他方法。透過閱讀他人設計程式就是一種所有程式設計師在其職業生涯中都可以採用的方法，而幾乎所有的新程式設計師在進行代碼維護時都不得不進行這樣的工作。
在我早期所做的一份程式設計工作中，在維護我的新上司設計的程式碼時，我學到了不應該做什麼。這個上司是一家正在快速發展的小公司的老闆之一，但並不是一個好老師。我們主要用 FORTRAN 進行程式設計，我進這家公司的時候，他已經設計了很多程式碼。他使用的變數名稱都是 a、b、c、aa、bb、cc，諸如此類。我那時剛開始學習 FORTRAN，但即使這樣，我也明顯地覺得這種方式很不好。他還透過將這些變數放入 FORTRAN 公共程式碼塊中，使其成為總體變數，這很明顯是太糟糕了。這樣做就不能在原始程式碼樹中搜索變數以進行重新命名，也不能對它們進行任何處理。據我所知，當時並沒有良好的 FORTRAN 整合開發環境可用於幫助處理這種情況，因此我對很多這樣的程式碼進行了手工清理，並保證設計更好的新程式碼——從良好的變數名稱開始。
從這個反面例子中，我們知道了：要設計可讀性好的程式碼；組、類、方法和變數的名稱要反映出其功能；避免採用最流行的命名約定，等等。在上個世紀 90 年代，我嘗試過在 C++ 中使用匈牙利標記法，而現在我非常贊同在 Java™ 識別字前使用 m_。對這些構件進行適當的命名是進行良好設計的基礎。恰當的命名不但有助於構建良好穩健的架構，還可以幫助其他人理解您的程式設計碼。但要進行恰當地命名並不容易，Tim Ottinger 就此給了一些不錯的技巧。

認識鐵三角的影響
當然，程式設計師可以進行一定的工作，以提高專案的效率。但也同樣有一些東西經常超出我們的控制範圍，從而使得項目的成功完成頗具挑戰性。請隨時謹記鐵三角，即使您的管理團隊並沒有對此引起足夠的重視，也不可大意。鐵三角描述專案的三個方面，通常定義為時間、資源和功能，這三方面共同影響專案的品質。程式設計師通常不能控制專案的這三方面，這些方面通常由市場行銷部門、公司股東、重要客戶等其他人確定。儘管程式設計師不能參與設定項目的這些方面的過程，但需要在專案進行過程中對專案的鐵三角加以注意，特別在經常出現問題時更要如此。以下內容有助於對這方面的瞭解：

透過發現軟體發展過程中效率低下的地方，使程式設計師和設計團隊成功實現目標，擺脫由於要求嚴格和資源不足帶來的限制。

從專業的角度出發，告知程式師可能是繼續進行下一步工作的時候了。

至少能夠說明，為什麼儘管大家都在努力工作、傾力而為，但要成功完成項目還是顯得如此難。

我在那家小公司工作時，該公司的管理層與全世界最受認可的一家醫療保健單位談成了一項大的業務。我們要在一年內為他們提供所需的軟體功能；需要聘傭一些新的程式設計師；這的確令人興奮。但隨後一些現實的問題開始顯現出來。透過需求分析，發現一年時間明顯不夠。然後我們又發現我們所知道的需求並不完整——他們將“逐步提出”。該公司沒有聘傭新程式設計師，但卻引入了新的專案需求，員工根本就沒有辦法處理全部的工作。
在業務達成後，我決定將項目時間延長至三年，隨後又增加了四年——總共用了七年時間——最後終於交付了最初計畫的功能程式碼。宣佈這項業務達成後的一年，這家小公司被一家大公司收購了；由於鐵三角的影響，在業務達成之前，這個項目就是金塊，而在幾年之後，卻變成了臭雞蛋。

保持簡單
在滿足需求的同時，使您的軟體設計盡可能簡單。這可能會要求放棄初期工作的成果，總結早期工作的經驗教訓，然後重新開始。這並不意味著在項目結束時才進行設計。在專案處於設計階段時就應該設計程。即使不負責進行實現，也要考慮到實現時的情況。理解過於複雜的設計（以及據此進行程式設計）需要花額外的時間和精力。作為程式師，我們處於業務需求和創建良好的設計與編寫出色的程式碼之間的中堅地帶。聘傭您進行程式設計工作的公司需要盡可能快地拿到軟體，以達成交易，獲得收益。有效簡化軟體設計的能力需要多加實踐才能獲得。但這值得化精力去學習，因為從長遠來看，這將節約時間和工作的投入量。

與他人進行良好的合作
程式設計師是團隊的一員，成功的程式設計師要能夠與其他人進行良好地合作；如果在這方面存在不足，可能會妨礙某些非常出色的人才的職業發展，因為他們很有可能被排除在較高層次的決策過程之外，而總又不能與決策者進行良好地合作，但他們帶來的價值需要掩蓋他們在組織方面的不足、羞澀或令人生厭的性格。對於我們大部分人而言，我們的才能並不能抵消這方面的缺點，因此我們必須培養良好的團隊工作能力：

首先，在本地設計程式設碼，以避免破壞生產版本。

其次，請求他人進行程式碼檢查時，要虛心接受批評，並從別人的評審中獲得思想上的最大提高。

在別人請您進行評價時（而非自己想這樣做時），提出一些建議，以進一步加強團隊合作。

對他人的出色工作予以稱讚（因為別人也能出色地完成工作），從而使團隊合作達到一個新的層次。

在適當時間主動承擔不甚舒適的工作（那些資深開發人員所進行的工作），特別在需要早起（而您夜裏工作很晚）或晚歸（如果您習慣早起）時，從而最終發展成為優秀的團隊成員。組織有時喜歡自己的員工有危機感。

知道什麼令您真正快樂
現在，軟體架構師的角色是很多程式設計師夢寐以求的。如果問從事入門級工作的年輕程式設計師他們希望做什麼，您會發現他們希望成為架構負責人，借助其很多年開發實踐積累的經驗確定整個軟體組織的方向。為什麼初級程式設計師認為自己會成為架構師呢？因為他們並不真正瞭解架構師角色的意義。
他們認為軟體架構師僅僅借助自己的技術權威領導一個團隊或更大的組織，以正確的方式設計軟體，選擇恰當的技術工具，如此等等。但架構師除了是技術角色之外，也是行政角色。很多技術專家在發現自己必須談判、和解、做生意、回復每天 200 封電子郵件，而完全放棄埋頭程式設計的快樂時，他們就不會太高興了。
對於那些希望進行人員管理工作的程式設計師而言，他們的命運也與此類似。當出現這種情況時，真正愛好程式設計的人應停下來認真地分析一下當時的情形。是否由於他們不是一個好的程式設計師才轉向管理？是否因為他們擅長程式設計，並希望從程式設計團隊的角度進行管理，才這樣做？作為程式設計管理人員，他們日常必須進行哪些工作？最重要的是，他們做這個工作時會快樂嗎？
學習技能，瞭解各種角色，瞭解自己喜歡什麼和適合自己的位置。然後，勾畫出一條美麗的人生軌跡。
文章來源 developerWorks台灣

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(342)

個人分類：電腦和網際網路

▲top

6月 26 週二 200702:58
程式設計師不可不注意的五件事

程式設計師不可不注意的五件事

Mar 10th, 2007 by Days

Posted by Mr. Friday

Mr. Monday寫了一篇你在大學裡應該學會的三件事，這篇以此類推，就叫做「程式設計師不可不注意的五件事」吧！這篇文章小小的匯集了Mr. Friday從大學以來參與程式設計開發的心得，雖然不敢說自己程式功力多麼高深，不過拋磚引玉，希望這篇文章可以引來更多有益的討論，對於新接觸程式設計這塊領域的新鮮人來說，應該可以避掉很多前人走錯、不應再重蹈覆轍的錯誤路子。

1. 文件標示不明，註解不清：這大概是所有程式設計師在看其他人所寫的程式時, 最痛苦的一件事了。在一間公司裡，不管你有多麼資深，有時候總免不了得先看懂別人在寫什麼程式，好接手寫下去（或合作開發應用程式）。曾經聽學長說過, 在大型專案裡, 自己重新寫永遠都比改別人程式還快――因為有的人寫得實在是太亂啦！！！看不懂！這就好比今天有個人用火星文寫了一串密密麻麻的文字，又沒留下小抄著明說哪一段文字是在寫什麼，之後老闆要你接手繼續寫下去，天呀，光是搞懂他標題在寫什麼就已經花去大部分的時間了，要準時交出程式？怎麼可能！有的人還誇張到連自己以前寫什麼都看不懂呢！

解決之道：在寫程式時，每個人記得要順手留下註解，不見得要長篇大論，但至少要註明大概的用途，能說明演算法內容者更佳。有的人可能在撰寫時可能會留下一些測試用程式碼，寫完以後就刪得乾乾淨淨。如果你沒有寫doc的習慣，至少把這些測試碼註解起來就好了，千萬別刪！要知道你的隨手小筆記，可能是未來接手者的救命丹呢。

2. Coding Style不統一：如果你曾參與過程式整合測試的流程，你可能會發現，同樣是寫程式，不同的教育背景與習慣竟會導致這麼程式設計style上的不同，有的人習慣javascript這種直敘式的語言，有的人則習慣Java這種以物件導向（Object Oriented Programming：簡稱OOP）為架構，而且你很可能會在他桌上找到一本厚厚的Design Patterns原文書。這些語言以及相對應的設計習慣，並沒有誰對誰錯，就像鋼筋混凝土與木材都一樣可以用來蓋房子，只要在對的環境用對材料，就可以撐上個幾十年。但是對同一個開發團隊而言，不同的設計習慣可能會帶來災難，就好像一棟房子上面是用鋼筋水泥，可是地基卻是用木頭做的，想也知道會出現問題――Mr. Friday曾經從教科書上看來一個例子，因年代久遠，Mr. Friday記憶中的可能跟事實有點出入，不過大意是這樣：有間歐洲銀行花大錢委託國外軟體商開發一套金融交易系統。這個國外軟體商開發好幾個月後，把成品交給義大利銀行總部使用，結果總部人員一打開程式，竟然發生大當機。銀行總部與軟體商花了好大一番功夫，才找到問題癥結點――日期格式不一樣！比如說2004年7月1日，有的地方會寫成04/07/01，有的地方是寫07/01/04，當然更有的地方是寫01/07/04……而正好軟體開發商與銀行用的日期格式是完全不同的，造成系統日期判定錯誤，最後結果竟然是得重新開發一次！不同的日期格式就能夠造成如此災難了，同一個開發團隊裡面、不同的coding style造成的災情亦可想而知。

解決之道：團隊裡面難免會遇到不同背景的程式設計師，除非你很確定所有的參與者都有一致的開發習慣，否則這時最好能先由一個領導者確立程式的整體結構，並參與API介面的制定，甚至是變數的取名與傳遞方式。一些常見的公用變數與程式的使用方法最好記載在一份公開文件或wiki中，讓工程師共同參考。如果只有少數幾個人的程式設計習慣與其他人不同，建議是先讓他們從修改一些簡單的程式碼著手，先讓他們逐步習慣其他人的設計方式，過一段時間後再投入主力程式的開發。

3. 絕對不要輕易相信One Size Fits All：網頁程式設計師應該特別明瞭這一點，因為他們絕大多數的人都歷經過「IE正常顯示，可是在Firefox打開就亂掉了；好不容易Firefox上調到正常，結果IE上的畫面變成一團糟」的痛苦。各家瀏覽器支援的標準不同（當然很多人會告你是IE不守規矩）已經不是新聞，不過這種事在其他的程式設計領域也是常常遇到：不同OS、不同的通訊標準、甚至是如前述所說不同的日期表示方式。什麼？你說「Java不就是一個跨平台的最好標準嗎？用Java開發的程式可以在各種不同平台上順利執行啊！」噢噢，可別忘記那是指「在同一個版本的JVM上」喔！Mr. Friday就曾經遇過某個用JDK 1.4開發的程式，到了新版1.5.0（不知道為什麼Sun要稱1.5.0版為”5.0版”…）上compile後卻跳出一個錯誤：某個JDK所提供的函式已經depreciated（過期，不再支援）了！更別說有的人搞不好用的不是Sun（比如說BEA）所提供的JVM哩，誰知道會不會有什麼Bug在裡面！

解決之道：千萬不要在未經大量測試前宣稱自己是跨平台還是跨所有瀏覽器的程式，比較盡責的做法是像MySQL官方網頁那樣，列出所有程式版本與平台，並註明哪些版本在哪個平台上歷經大量測試、問題較少，哪些版本是有支援，但未經大量測試。如果你比較懶，至少也應註明自己的開發與測試平台是哪些！

4. 絕對不要把程式進度當作可以量化的指標，除非你不打算過著人類正常吃喝拉撒睡的生活：寫程式與其他工作不一樣之處在於，它永遠都是新的挑戰。科技日新月異，程式設計師面對的挑戰永遠是在新的平台、新的通訊協定、新的規格（甚至是新的程式語言）上設計新的程式。即使你以前寫過類似功能的程式，你也不可能確保以前的設計方式在新的平台上會不會出問題。如果你信心滿滿告訴老闆說明天早上程式一定會寫完，換來的代價很可能是公主徹夜未眠還寫不完！

解決之道：你可以根據你過去的紀錄推知類似的程式功能你大概會花多久完成，但是絕對要預留「如果遇到很難解決的問題…」的後路。記得在學校時代上系統設計分析方法時，教授曾說：「據統計，只有40%的專案能夠如期完成。」Mr. Friday雖然不知道教授口中的統計數字從何而來，但是根據Mr. Friday身邊所有人的經驗，絕大多數的專案都難以按時完成。對一個身負「如期完成」重任的專案經理來說，寧可在早期以加班或增加人手的方式把程式維持在一定進度，如果還是無法負荷，也可以試著修改專案目標，免得一拖再拖，到了開發後期根本是無止盡的拖延。

5. 缺乏遠見：已經有很多書告訴你Design Patterns、UML、Class Diagram還是Normal Form這些幫助規劃程式架構的工具有多重要，可是這些書卻常常忘記提醒大家「有遠見」是多麼的重要。永遠不要小看自己所寫的程式，也許這個程式未來會變成大家都流行的基本配備也說不定。60年代的程式設計師也沒想到只取後兩碼數字的習慣，會在40年後造成Y2K問題。同樣地，一個簡單但卻不夠彈性（scalability：這個字沒有恰當的中文翻譯，多數人翻成擴充性，意思為能支援的標準很多、經得起各種情境的測試）的設計，也可能會在程式完成後產生意想不到的錯誤。

解決之道：就算寫的程式再容易，也千萬不要忽略在scalability方面的考量。與其在設計時多花個幾小時思考，也勝過程式寫完後才發現「糟了！得重寫了！」

每個人心中都有一個衡量「好的程式設計師」的一把尺，也許標準人人不同，但如果缺了這五項該注意的事，這個人肯定難以成為出類拔萃的程式設計師。謹以此心得，紀念過去那些沒有睡眠的夜晚、奉獻在無用程式的心力上T__T

文章來源 MR./MS. DAYS

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(21)

個人分類：電腦和網際網路

▲top

6月 26 週二 200702:48
你是專業程式設計師嗎

你是專業程式設計師嗎？(上)
朱仲傑　　2006/10/12

你是「專業」的程式設計師嗎？什麼是專業？我自己的定義是「使用自己所擅長的程式語言，快速且正確地解決問題的程式設計師。」這句話裡有兩個重要的關鍵字：「快速」與「正確」。正確是絕對必要的，如果最後的結果不正確，那不管是用了什麼最新的技術，或是到底多短的時間就完成等，其它的因素都是白廢的。至於怎樣才叫快速？這個比較沒有量化的標準，而且快速還可以再細分成：你寫程式的速度和寫出的程式的執行效能。

但業界的確有權威的標準，來判定你到底是不是專業的程式設計師。最簡單的方式，就是參加一些有時限的程式設計比賽，例如正在舉辦的Google Code Jam 2006。Google Code Jam分成了三個關卡，每個關卡都要你在有限的時間內，解決幾個問題（詳情請看Google網站）。問題有難易度之分，相對所分配到的分數也不同，而你所得到的分數會依據你解題的速度、正確度與效能給分。只要在時限內達成要求，就代表你至少有一定程度了。

筆者不幸在第一關就慘遭淘汰。經過一番自我檢討，在今年的比賽裡，我犯了幾個嚴重的錯誤。第一，我沒有詳細的閱讀比賽規則、看錯比賽時限、不熟悉比賽程式介面。我把第一、二關時間看錯，第一關是要在60分鐘內解決兩個問題（兩個問題滿分分別是250分和750分），第二關的時間75分鐘。而計時是從登入後就開始計算，我在chat room晃了一下才找到自己的比賽區，賽前又沒有去熟練比賽程式操作介面，摸索也用掉了一些時間，所以當我真正認真讀題目寫程式時，時間只剩不到50分鐘。

第二個錯誤是我太自以為是。我原本認為沒什麼好怕的，寫程式我熟練得很。可是這個比賽的目的，其實不是要你對於一個程式語言的語法到底有多熟練，而是如何去找出、設計出正確的解題方法，至於用到的語法都只是最基本的條件判斷式、迴圈，外加基本的API等等。解題的方式說穿了很簡單，只要動動腦筋，運用一些幾何、數學的基本常識或功式，依題目的需求，組合成正確的解答即可。所以你必需具備的反而是幾何、數學的基本能力，而不是程式語言到底有多熟練。

要在時限內正確的解決問題並不容易，尤其是在做專案時。有句玩笑話說，專案的Deadline就是訂出來讓人delay用的。如果時限已到，問題還沒有辦法100%解決呢？那你就要用你專業的判斷，配合當下的環境，把能得到最好結果的答案給交出去。程式比賽時間是無法延長的，專案的話就有許多談判的空間，如果你交出去的答案夠水準，在客戶面前談判的籌碼自然就多一些。Google Code Jam其中一個題目的滿分是250分。要拿到滿分很難，但按照給分的條件，就算你的解法沒有100%的正確，還是會有一定分數。所以別浪費時間在仔細的檢查為什麼程式沒有辦法100%通過測試，只要有80%以上，就趕快交卷(submit)，馬上去解另外一題來拿分數。

我犯的第三個錯就是浪費時間在程式檢查上，5個test case我只過了四個，我花了很多時間來找這個bug，結果不但沒有時間解第二題，連第一題也忘了submit(沒sumbit就是0分了)。我在莫名奇妙中結束了這屆的Google Code Jam，千金難買早知道啊。

想法才是效能的關鍵

在google code jam中，解題的速度很重要，程式執行的效能也不可缺。效能固然和花掉的CPU時間有關，但這個時間會依硬體效能的提升有些改變，我認為，程式設計人員在設計你的解法/演算法(algorithm)時的想法和態度，才是決定程式執行效能的關鍵。

舉個簡單的例子，請你設計一個程式，可以計算a加到b的總合(例如1加到100)，你會怎麼寫？很直覺的，這種重覆性的工作，可以交給迴圈來解決。是的，用迴圈是可以正確的解決這個問題，但我認為這是最不專業的解法。我們就算數學不好，也聽過高斯小時候的故事；話說高斯從小就非常的聰明且頑皮，有一天上課時，老師為了讓他不搗蛋，出了一個難題給他，要他計算1加到100的總合。老師以為可以讓高斯安靜一下子，沒想到高斯沒幾分鐘就把答案算出來了。後來推導出所謂等差數列的功式，也就是首項加末項乘以項數再除以二，以這個例子來說就是(a+b)*(b-a+1)/2 。短短一行程式碼就解決的問題，為什麼要用迴圈寫成好幾行呢？當數字大時，使用數學功式的程式執行的速度絕對比用迴圈還快上很多！

寫程式的態度應該是，把你所學會的所有知識中，找出最好的解決方法，而不是程式正確會跑就好。如果還有更好的方法是你還不會的，那就趕緊把它學會，日後好運用在你的程式裡。你也許會不以為然的說，解決這種小問題，幹嘛要計較這麼多。我不想在這討論程式該不該做最佳化的問題，網路上已經有太多類似的爭辯，不知大家有沒有聽過「格局決定結局，態度決定高度」這句話？設計程式的思維和邏輯也不是一朝一夕就能養成或是改變的，你想要成為頂尖專業的程式設計師，就要養成良好的思維習慣。（待續）

文章來源企業應用

你是專業程式設計師嗎？(下)

朱仲傑　　2006/10/13

專業領域能力

除了態度之外，就是你如何去發揮、結合其它領域的專業知識。我以前教授青輔會電腦第二專長訓練班，來上課的學生都不是資工電腦相關本科系的(所以學電腦才是第二專長嘛)，他們想學好程式設計，但大部份的人心中都有個疑惑：「我寫程式贏得過本科系的人嗎？」我鼓勵他們說：「單比寫程式，也許你們不一定贏得了，但你們在其它領域的專業知識，則是他們欠缺的！」我常說，學資工其實是最沒有用的，因為除了電腦之外，其它領域什麼也不會。寫一個股票系統不需要太高深的程式設計技巧，可是其中的分析、統計確需要專業的相關知識。就拿我來說好了，也許我很會寫程式，但我沒辦法寫出一個股票系統，因為我在那個領域裡完全不懂。這就是我想要表達的本科系無用論，所以本科系的人不需要太驕傲，而非本科系的人也不需要太悲觀，各自發揮你們在各個領域的專長，並深化你想要的domain know how，你就可以成為一位出色且專業的程式設計師。

那我該怎麼做才能達到在程式領域及某個特定的領域兼具的專業呢？程式領域的專業你可以用不斷的練習來達成，例如到討論區中幫別的解決問題或是研究別人的解法，也可以到TopCoder (http://www.topcoder.com)這樣的網站上去挑戰磨練你的技巧，像Google Code Jam就是你驗收成果的好時機。至於其它領域的專業呢？透過學校上課或是工作專案裡來學習，這方面倒是沒有什麼固定快速的學習方式。

創新

有人叫我大師、達人、高手（但照前面的定義來看，我還真不怎麼專業。）從開始學習BASIC語言(有行號的那種)，一路走來Quick BASIC、Visual Basic、ASP到Java，算一算已經快二十年了，能夠支持我這樣一路走來最主要的動力是「熱情」，這點跟上次來台灣的兩位大師的觀點一樣：對寫程式的熱愛、對技術的熱情。

要保持熱情並不容易，因為有很多外在的因素會迫使你放棄，例如經濟的壓力，在台灣，技術人員的薪水高不到哪去；無日無夜無條件的加班，對體力上可說是很大的考驗。台灣在硬體方面是世界首屈一指的，不論是代工組裝的品質、ODM、OEM ，甚至外型設計也屢獲大獎。可是為什麼在軟體的創新研發上，能在國際上叫得出名字的就只有那幾家？我們程式設計的功力比較差嗎？並不會啊！創新的能力我想是最主要的因素。

創造力或許是天生的，但學校教育的培養也相當重要。無奈的是，不論教改前或教改後，教育的目標還是沒有變：考上好的大學、好的研究所，你就能出人頭地。「把書讀好就對了，其它什麼事都不用管。」這一直是台灣許多父母的觀念，不好好念書幾乎就和不孝劃上等號了。從小「補、補、補」的教育，讓我們的創造力逐漸消失。反觀影響電腦界最深遠的兩個人--Microsoft的Bill Gates跟Apple的Steve Jobs--就是個最好的例子，他們都沒念完大學。你看過他們相關的傳記就知道，他們年輕時幹過多少在台灣社會下不被允許或不可能做的事。讀書固然重要，但重點在於能否激發創意的實現，否則就變成了死讀書、讀死書、然後讀書死。

如果你還是學生又想當專業的程式設計師，那恭喜你，你還有許多時間可以好好的改變你自己。如果你已經是個程式設計師，改變雖然需要勇氣和承擔很大的風險，但不改變你就永遠只是個程式設計師，要變專業成為頂尖的話，改變乃是不得不然的路。

文章來源企業應用

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(62)

個人分類：電腦和網際網路

▲top

6月 26 週二 200702:30
程式為什麼不會動？程式設計師告訴你為什麼！

原文在： Top 20 replies by Programmers to Testers when their programs don't work。翻譯如下：

第 20 名：這很奇怪喔。

第 19 名：以前從來不會這樣啊！

第 18 名：昨天明明會動的啊！

第 17 名：怎麼可能~

第 16 名：這一定是機器的問題。

第 15 名：你到底是打了什麼才讓程式當掉的？

第 14 名：一定是你的資料有問題。

第 13 名：我已經好幾個禮拜沒碰那一段程式了。

第 12 名：你一定是用到舊版了。

第 11 名：一定是巧合！為什麼這種壞運氣只讓你碰上。

第 10 名：我不可能什麼功能都測試到吧，有 bug 是正常的！

第 9 名：這個不可能是那個的原始碼！

第 8 名：這程式應該是會動的，只是我寫好後還沒做測試。

第 7 名：可惡！一定有人改了我的程式。

第 6 名：你有檢查過你的電腦有沒有病毒嗎？

第 5 名：儘管這功能還不能動啦，你覺得他如何？

第 4 名：在你的系統不能用那一個版本的程式啦！

第 3 名：你幹嘛要那樣操作，都是你的問題。

第 2 名：程式發生問題時你在哪裡？

第 1 名：在我的機器明明就可以動啊！

所以說嘛！可以做人，幹嘛來寫程式呢？

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

之前有一篇類似的轉寄笑話:

工程師常說的話看看你常說哪幾項
25.都這樣了，還不work，搞什麼？

24.你可能中毒了喔。

23.一定是有人改了我的程式。

22.已經可以了，不過還沒測試過喔。

21.都好了啊，還沒測試過就是了。

20.我不是已經修好了嗎？

19.這個不能那個。(THIS can't do THAT.)

18.我一個人又測不完！

17.怎麼這麼衰！

16.沒問題，馬上好！

15.當然，當然，我再修一修就可以了。

14.快好了，快好了。

13.好啦，只不過一個小功能嘛！

12.你拿錯執行檔了。

11.可以，可以，來得及。

10.我可沒動過這個模組喔！

9.你的測試資料一定有錯！（我那邊不會啊！）

8.不可以這樣操作的啦！

7.你的作業系統（驅動程式）升級了沒有啊？

6.機器好像壞了。

5.怎麼可能？！

4.哦，這程式還要改一下。

3.昨天還好好的呀！

2.我從來不知道有這種事。

1.奇怪...
.
.
.
.
.
.
.
最後，也是最常用的
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
0.幹

文章來源 Mark's Place

程式設計師的四不一沒有：
操不死、罵不退、窮不怕、加班不停、沒有前途
程式設計師的工作內容：
錢少、事多、離家遠
位低、權輕、責任重
睡覺睡到作惡夢、哈錢哈到腦抽筋

加班沒錢是共識，晚上關門是職責，週末上班是常態，上線不睡是義務。
老闆說，他絕對不會強迫我們加班的，只是不能事情一堆還準時下班。

文章來源程式人的對話

(繼續閱讀...)

Hiro 發表在痞客邦留言(0) 人氣(235)

個人分類：電腦和網際網路

▲top

«1 ...345 12 »

歡迎光臨Hiro在痞客邦的小天地

與使用者溝通十種最糟的方式

一個程式使用者的技術問題

【笑話轉載】一個程式使用者的技術問題

善用時間

善用經驗學習

從程式設計師到創業家

程式碼只是生意的5%

設計就是一切，而且可以提升競爭力

養成長遠思考的習慣

承認吧，你不瞭解使用者

愛你的客戶

盡可能設計得容易使用，讓高手也喜歡

從其他人身上找靈感

不要害怕拿下某些功能

耐心是一種美德

用從頭學習寫程式的心態做事

程式設計師的類型

程式設計師的類型

做一個快樂一生的程式師

程式設計師不可不注意的五件事

程式設計師不可不注意的五件事

你是專業程式設計師嗎

程式為什麼不會動？程式設計師告訴你為什麼！

自訂側欄

自訂側欄

個人資訊

熱門文章

文章分類

最新文章

最新留言

動態訂閱

文章精選

文章搜尋

誰來我家

參觀人氣