一是重視演算法、資料結構、執行效率的「效率魔人」
二是重視程式架構、擴充性、彈性、可理解性的「架構狂」
有很多「第三型態人」,他們的信念只有一條:「程式只要會動就好」。第三型態人不在乎效率,也不管架構漂不漂亮,上面要求他做什麼,他就想辦法東湊西湊,從Google找程式剪貼,從MSDN抓範例來用,反正只要能隨便測過一個case就能交差了。
要成為一個優秀的程式設計師的關鍵是什麼?關鍵不在於coding速度有多快、懂多少演算法,或是背了多少patterns,最重要的是「熱情」!
偉大的程式設計師都非常喜歡寫程式,寫程式的過程是一種絕妙的享受,他們執著的地方或許不同,可能是程式的效率,也可能是開發的效率,甚至是架構的彈性或是程式碼的精簡美觀程度,但他們都非常想要並堅持自己應該寫出「好程式」。

現實生活中,不管學哪一種程式語言,通常只要幾個星期就能上手,再過個一年半載,當你成為老鳥,就沒人在乎你用什麼語言了
面試時,要有自信,要平等的對話。你要的是一個互利的錄用合同,不要每次對方提出要求,你都說Yes
工程師被雇傭,不是因為會編程,而是因為能夠創造商業價值
我認識的一些最優秀的程序員,往往拙於表達。因此,別人不是不想與他們一起工作,就是低估了他們的價值。相反地​​,如果你看上去很會編程,並且很善於表達,別人就會真的這樣看待你

從新手到專家要經歷5個階段
1.新手
2.高級新手
3.勝任者
4.精通者
5.專家
大多數人掌握的技能,在他們的生命裡,基本上處於第2階段,也就是高級新手的程度
他們之所以沒有繼續往上提升,是因為他們掌握的技能足以應付日常生活與工作中的需求,也就不再想著刻意提升了
刻意練習則要求我們先明確了解自己需要改進的地方,再集中精力練習,最後獲得飛躍式提升
舒適區,無論我們花費多少時間去練習,頂多停留在高級新手或者勝任者的階段,是無法成為真正的精通者或專家的
刻意練習的6個步驟
1.制定具體目標
2.走出舒適區,認真學習
3.專注投入,刻意鍛煉
4.進行回饋,確立問題
5.保持練習,完成階段性目標
6.到達終點
當我們在學習區透過刻意練習提高了技能後,舒適區就會變大,把原來屬於學習區的部分變成新的舒適區。而恐慌區的部分則會減少,變成新的學習區。經過這樣的循環,我們最終會成為頂尖人士

好的演算法工程師必須先是一個好的軟體工程師,因為沒有什麼好的演算法是可以脫離工程實踐而成立的

所謂的死海效應,就是好員工像死海的水一樣蒸發掉,然後死海鹽度就變得很高,正常生物不容易存活。因為當公司發展到一定階段,能力強的員工容易離職,這些人能力強,對公司內愚蠢的行為的容忍度不高,他們也容易找到好工作;另一方面,能力差的員工傾向於留著不走,他們也不太好找工作,年頭久了,他們就變中高層了
1.廢物主管沒有人情味;好主管對人熱情。
2.廢物主管常把「我」掛在嘴邊;好主管常把「我們」掛在嘴邊。
3.廢物主管「使用」員工,就像用抽取式衛生紙,用過即丟;好主官「灌溉」員工,讓員工成長,就像給樹木澆水。
4.廢物主管讓員工畏懼;好主管贏得員工尊敬。
5.廢物主管愛邀功,就像吸鐵一樣吸走功勞;好主管永遠把光芒給別人。
6.廢物主管「微觀管理」,透過密切觀察與操控員工來達成目標;好主管「授權管理」,將任務指派給員工之後,授權他們自己去掌控一切,達成目標。
7.廢物主管說,「你快去做!」好主管會說,「我們一起加油吧。」
8.廢物主管短視近利;好主管深謀遠慮。
9.廢物主管把自己當皇帝;好主管把自己也當成員工,沒有階級之分,會和底下的人一起喝咖啡、一起成長。
10.廢物主管只注重工作過程;好主管將員工放首位。

我們工程部的氣氛是蠻不錯的。仔細想想大家工作蠻開心的,也樂於相互幫忙,人員流動率也低
當頭腦有休息的時間,才會有靈感,很多難解的問題我都在休息的時候蹦出解決的契機
「信任」是最簡單也是最困難的管理方法
雖然我們都需要學習如何溝通,但每個講話都講個二三十年了,不擅長溝通問題可能不在方法,而是人的習慣
當上位者戀權戀位,最後高手都走光了,留下的只是渣

永遠要誠實面對自己的能力,不斷地讓自己能力進步往更好的方向走,不要被短期的結果影響,要記住人生是長期累積的結果也是一個連續的過程

Programming languages are different, but design smells are alike.
Frameworks are different, but the same design patterns shine through.
Developers are different, but rules of dealing with people are uniform.
Microservices frameworks Evolutionary Architecture
New programming language Clean Code, Design Patterns, DDD
LeSS, SAFe Lean manufacturing principles
Hystrix Fault Tolerance Patterns
Docker Continuous Delivery
Angular Web, HTTP and REST

在台灣的時候,工作的哲學往往是時程優先,程式碼品質排後。在我的經驗裡,一個新專案下來,一些亞洲工程師會先用自己會的東西下去套,如果能夠套出來就交差了
但矽谷這邊的工程師會預先準備一週左右的時間,了解這個專案的要求和開發環境,是否可以導入一些大家素有耳聞、早就想用看看的的新技術。提這些新技術不是炫耀而已,它們往往都是已經證明可以有效提昇工作效率的東西
美國工程師在一個專案開始前,通常會有較長的前置時間研究系統,但開始上路後就會順暢很多,而且常常可因為引入新東西而更有效率

售票要面對的其實是瞬間流量,而不是整日流量。如果你看到某某售票說他們「單日最高可以提供超過幾千萬人次的流量」,顯然他們對於售票一點概念都沒有,或是假設消費者一點概念都沒有

最大的問題在於他們都相信使用者會正常幫忙轉交,即靠客戶端的瀏覽器來轉址傳值
一來,重要的資訊就會被客戶知道,例如寬宏售票疑似洩漏資料庫密碼;二來中間的內容可以修改,例如修改訂單金額
某部分原因可以歸咎到早期第三方金流的範例都是這樣寫的,工程師也就直接延續這樣的寫法直到現在
世界在進步,過去的技術也許就該讓它留在過去

在較傳統的資料庫與網頁伺服器架構下,並不單純是增加頻寬、硬體等,就能夠順利完成售票;瓶頸可能來自於系統設計本身。
雲端架構只是讓硬體更有彈性,最終還是要靠自己。
當技術的問題解決了,經驗足夠與否就成為關鍵。
危機處理的判斷其實很依賴經驗,因為你無法知道會發生什麼。如果在前面做了一個比較不好的選擇,就會使得你後來的選擇更有限。
問題都會發生,重點是要怎麼補救,跟站在誰的角度思考。當先前的錯誤犯得不夠多、或是經驗無法累積的時候,就很容易在很緊急的狀況下做出不一定正確的決定,並且此後容易一錯再錯。

有趣的是,新的目標與舊的目標之間,除了存在措辭方面的差異外,幾乎一模一樣。我的助理向我抱怨說:「我們浪費了一個月的時間,又回到了原地。」但我對他說:「不是的,此前我是靠直覺選擇了目標,沒有調查資料的支援,無法令員工信服;現在,經過一個月的工作,大家都有了信心。更重要的是,舊的目標因為沒有經過員工參與,即使實施起來,他們也很難全身心投入。」
謙虛使人進步。許多領導者在工作中唯我獨尊,不能聽取他人的規諫,不能容忍他人和自己意見相左,這些不懂得謙虛謹慎的領導者也許可以取得暫時的成功,但卻無法在事業上不斷進步,達到卓越的境界。
執著是指我們堅持正確的方向,保持矢志不移的決心和意志。無論是公司也好,還是個人也好,一旦認明了工作的方向,就必須在該方向的指引下鍥而不捨地努力工作。在工作中輕言放棄或者朝三暮四的做法都不能取得真正的成功。
成功者需要有足夠的勇氣來面對挑戰。任何事業上的成就都不是輕易就可以取得的。一個人想要在工作中出類拔萃,就必須面對各種各樣的艱難險阻,必須正視事業上的挫折和失敗。只有那些有勇氣正視現實,有勇氣迎接挑戰的人才能真正實現超越自我的目標,達到卓越的境界。正如馬克·吐溫所說:「勇氣不是缺少恐懼心理,而是對恐懼心理的抵禦和控制能力。」
當員工表現不佳或是新手時,企業碰到重大危機時,可以更多地親身參與管理,更多地使用命令的方式;當企業改變方向時,或員工因不理解方向而士氣不高時,可以多與員工分享企業的願景;當員工對工作能得心應手時,或發現部門協調有問題時,可以更多地強調和鼓勵團隊合作;當員工懂得較多,或沒有危機時,可以更多地讓員工以民主討論或投票方式來做出選擇;當員工能力很高又是專家,且員工積極自主時,可以儘量授權給員工;當員工有動力但是能力和經驗不足時,應當儘量考慮員工的長期發展,安排有啟發性的工作,慷慨地做員工的「教練」。

公司的每個人,包含我自己,都該做時間的掌控者,不要被時間掌控。只有不知道自己在幹什麼的人,才會開一堆沒效率的會議。大家都說不喜歡開會,但又不在開會前事先準備,每次都空空來到會議上找一群人腦力激盪,搞得會議超時又疲累。幾個小時過後,還是沒有產出一個有效有共識的結論,甚至又耽誤其他人的時間,這對公司來說得不償失。

以 coding 為業可以換來一份有豐厚回報的、穩定的中產階級生 活。如果你有悟性,喜歡這個工作,那它是一種享受時光的好辦法,如果你的老闆和同事是優秀的人,那它會更加有趣—即使比較枯燥的那部份,也會對你有所幫助。

嫌棄理由 1:你沒有自己的想法。

嫌棄理由 2:你風花雪月沒有邏輯。

嫌棄理由 3:不信任 RD 的能力。


如果你只是單純地列出所有你待過的公司、作過的 projects

那跟去看復仇者聯盟,結果裡面都只有鋼鐵人起床吃飯走路一樣無趣


但整題而言,在 Project Manager 的角色中,你必須是個「負責任、懂技術、有溝通能力」的角色,我認為這些是足以身任一個的 Project Manager 基本條件。

System.out.println("Hello World!");

他們並不是想要打混摸魚,相反的,工程師們熱切的想要展現自己的能力。

「必須有勇氣,才能承認自己一直都做錯了某些事,承認自己有待學習、還有更好的方法。」 — 品質管理之父 愛德華.戴明(W. Edwards Deming)


設計 RESTful Web Service 的要訣只是盡可能使用 HTTP 既有的能力

「彼得原理」是指:在組織或企業的等級制度中,人會因其某種特質或特殊技能,令他在被擢升到不能勝任的地步,相反變成組織的障礙物(冗員)及負資產。

好的工程師為了拿高薪,不得不往管理職升遷,變成管理職後再也不需要寫程式,所以為什麼好的工程師這麼少 ? 因為他們都變經理了。可惜的是,程式寫的好的人不代表會管理人,最後反而因為管理績效不好需要離開公司,但也回不去以前工程師的狀態了。


反觀在職的工程師,他們常說「用新工具、新框架來維持現狀」是最困難的挑戰。這句話也暗示著他們離職的首要原因:「缺乏生涯成長的機會」和「無法用新科技工作」。講白一點就是:不論是欠缺挑戰或是被挑戰擊敗,工程師一旦停止學習就等著離開。

當然我也知道,如果不是為了活下去,誰願意接案 ?

何謂宗教化?

所謂宗教化(Becoming more religious),意思就是程式設計派系的對立深化。漸漸地,許多軟體工程師對於程式語言的訴求已經不是各取所長,而是先選定語言,再選擇要解決甚麼問題,說穿了就是跟工程的理念背道而馳。

樂觀而言,程式設計派系對立,使得個語言、架構和設計模式在劇烈競爭下相繼成熟,使得軟體工程師在工作時有更多的選擇。

這麼一說,不代表程式語言通用化是一件壞事;但是在大家圖方便的同時,也要記得軟體工程自身的複雜度,才能判斷程式語言是否適合解決問題,所謂善其事、利其器。

「現在越來越多軟體工程師只會用函式庫(Library)寫 Code,而不是真的在做工程。如果你把一位 Ruby-on-Rails 的工程師丟到 J2EE 上去,就寫得一蹋糊塗。這是我們科技業訓練求快卻不求穩造成的失敗。」
工具歸工具,思維才是實力

工程師的天職是利用程式,尋找解決問題的各種可能,根本就不是製造「美麗的」產品。
工程師的工作流程是這樣的:提出多種可能解決方案之前,得先看用戶的問題根源到底為何,重新理解問題之後,才思考要用何種技術、角度解決。

1. DNS 解決方案,使用 CDN,把資源檔的請求分散到多個不同域名上。

2. HTTP Headers (Expires, Cache-Control, If-Modified-Since )

3. 所有 Steve Sounders 說的規範,參考:高效能網頁 (http://shop.oreilly.com/product/9780596529307.do )

4. 如何解決所有 PageSpeed, YSlow, Chrome Dev Tools Audit, Chrome Dev Tools Timeline 上列出的問題。

5. 什麼時候要把事情交給 Server,什麼時候要交給前端。

6. 利用快取 (cache), 預先抓取 (pre-fetching) 跟 延後載入 (post-load) 技巧

7. 原生 Javascript,知道何時要自己刻,何時要去找別人的程式碼來參考,同時還能夠評估出優點跟缺點再去做。

8. 新潮的 MVC Javascript 函式庫知識跟用法 ( 例如:AngularJS, EmberJS, ReactJS ),圖形函式庫 ( 例如:D3, SnapSVG ),DOM 操作函式庫 ( 例如:JQuery, Zepto ),延遲載入 (lazy loading) 或是 package 管理函式庫 ( 例如:RequireJS, CommonJS ), 任務管理 ( 例如:Grunt, Gulp ),package 管理 ( 例如:Bower, Componentjs ) 及 測試 ( 例如:Protractor, Selenium ).

9. 圖片格式,優點,何時使用哪一種,如何使用。圖片的優化技巧,載入的策略 ( Sprites, lazy loading 技巧, 快取刷新, PNG 交錯)

10. CSS 標準的知識與用法,現代規範與策略 ( 例如:BEM, SMACSS, OOCSS )

11. Javascript 在電腦科學的部分 ( memory management,single threaded nature, garbage collector algorithms, timeouts, scoping, hoisting, patterns )


怎麼可能是正常的一般人呢?

工程師和產品經理協作、溝通矛盾是一個永恆的話題。因為兩者的知識體系和思維結構不一樣,關注的重點不一樣,所以在協同工作過程中,難免會出現一些分歧和摩擦,出現互相埋怨和吐槽的情況。
工程師和產品經理之間的健康關係應該是基於信任、尊重和理解以及同一利益共同體的,脫離了這一前提,高效的協作就成了空談。

人腦最大的問題是「健忘」。所以當你在思考一個複雜問題的解決方案時,常常滿足了 A B C,卻忘了 D E F,滿足了 B C D F,回頭又忘了 A 與 E。這背後是有原因的,人腦是非常多的「迴路」所組成的構造,這些迴路都有半衰期,剛剛連通一次,過幾秒鐘它就斷掉了,所謂短期記憶。如果你不斷連通這個迴路,則它可以持久一點,所謂長期記憶。

我們無法預測軟體開發中每一個項目的時間,是因為這些工作的本質就是「創造新知識」。開發軟體的目的是創造「自動化的流程」,一但目標達到,自動化後的流程就可以重複的被執行,在可預測的時間裡面。所以一個軟體就像是「食譜」一樣,而電腦就是「廚師」,輸入的資料是「食材」,而輸出的資料是「晚餐」。
軟體工程用硬體工程的模型去管理,從出發點就是錯誤

鼓勵孩子們學習編寫電腦程式可以完善國家的技術驅動鏈,發明出更多軟體和數位化工具,而不是大量的製造業和原材料供應商。
「沒有人天生就會編程,孩子們應該從小就開始學,這樣才能深入骨髓。」
「我父母那代人的很多工作都不復存在了,我也在思考這 20 年意味著什麼。當我們的孩子長大後,他們會與全世界競爭,到那時,編程會像英語一樣普遍。」

他們認為優秀的工程師只喜歡跟優秀的工程師一起工作,因此從五年前的第一天開始,他們對於工程師的雇用就非常嚴格、寧缺勿爛,不斷去要求團隊只招聘更優秀的工程師。
大家喜歡工作的內容,又喜歡一起工作的同事,邀請更多朋友來加入的意願自然很高。這時候公司只要問大家,他們認識的工程師中,誰是最優秀的,然後鼓勵他們邀請這些人來加入,自然就會有很好的成效。
Zynga 這類要用花花綠綠的福利去吸引員工的企業,從根本上就有問題。如果不是工作本身無趣、缺乏成就感,怎麼會需要那些花招?領導團隊沒辦法正視核心問題,從本質上去改善公司文化、工作內容,反而只是花錢包裝點綴、掩飾太平,時間拉長,人才引擎當然會出現問題。

心理安全:我們能不能在這個團隊放下顧慮,而不會感到不安或尷尬?
可靠性:我們能不能依靠隊員按時完成一份高質量的工作?
結構 & 清晰度:我們團隊的目標、角色以及執行計劃清楚嗎?
工作的意義:我們所做的工作對我們個人重要嗎?
工作的影響:我們真心相信我們正在做的這項工作有意義嗎?

「目前的事實是,如果我們不做一些更好的選擇,那麼我們的領先優勢將逐漸縮小。我們需要讓孩子們參與數學和科學,而這不僅僅是一小部分孩子,而應該是所有人。所有人都應更早地學習如何 coding。」
「Coding 這件事情本身就是解決問題的代名詞,如何系統化、邏輯地解決問題通過 Coding 及其基礎數學理論可以最好地教給受教育者。在學習 Coding 的這個過程中,對於未知領域訊息的搜尋、獲取及分析的情況會反覆發生,​​這是在我們傳統基礎教育學科中極少遇到的情況,但是卻是非常重要的一項基礎能力,Coding 會無形之中不斷強化一個人依靠自己的想法和力量找到解決方案的能力。

使用自己不熟悉的程式語言去開發一個新的程式,其實就像拼拼圖
懂得如何找到你要的資料,跟知道怎麼解決問題一樣重要
寫程式是一個創作的過程,可以自由選擇依專家的見解或運用自己的方式去解決問題。特別是當碰上不熟悉的程式語言時,往往需要做足功課,好好研究一番,才能找到最適的解決方案。

當你去餐廳點餐再也不管價格,確實會有一種享受跟滿足感。但就像是在幻想山頂風光,當你真的到了那裡,絕對只會失望。那種快樂主要來自於你的期待,而不是真的那麼好。
真要說什麼體悟的話,我發現真正讓我快樂的,其實是全心專注時所得到的寧靜與心流狀態(flow)。
發財了,然後你得到的就只是這樣。銀行帳戶的數字改變,電視的尺寸改變,車子的廠牌改變,房屋的地址改變,全都不會讓你覺得生活真的完整。我終究得靠自己想清楚人生中的一切狗屁。

軟體估算往往很扯,就像《人月神話》裡面說的那樣,認為一切都將運作良好,每項任務僅花費它所「應該」花費的時間基本上就是鬼話
定制軟體裡面很多東西都是要從頭做起,而且如何組合、最終如何工作、軟體究竟應該干什麼等這些都是運動目標。一開始的時候路徑和目的都是未知的,所以很難知道什麼時候能幹完。
估算第一定律:估算純屬浪費

估算第二定律:估算不可互換

對一個人的估算並不能用來預測另一個人多久才能完成工作。

如果估算者和實現者水平相當甚至在同一團隊工作的話,估算的可轉移性顯然會有改善。

估算第三定律:估算是錯的

估算不是承諾。是猜測,而且往往是范圍越大未來的估算活動越深入,出錯的可能性就越大。

由於估算較小較近期的任務要比較大較遠期的精確,所以把任務分解是有意義的。理想情況下,用戶可以交互和測試的獨立子功能應該成為估算過程的單元

估算第四定律:估算是暫時的

開發者在項目開始前可能估計特定功能需要 1 週的開發時間。等項目開展 3 個月後,知道和拍板了很多事情后,同樣的功能也許就只用幾小時或者 1 個月了 「估算」實際上可以在工作完成後進行,這樣精確度可以達到 100%(而且成本幾乎為 0!)。

估算第五原則:估算是必要的
如果對軟體開發的時間和成本沒有概念,企業就無法做出是否開發的決定。

在實務上,它有一個致命的缺點,那就是很難找到同時在產品開發、人才,以及技術,三種截然不同領域上,都能表現優秀的管理人才。
因此最常發生的狀況,就是由工程師升任的產品經理,很會做產品與技術管理,但在人才管理上卻是無可救藥、問題百出的情況。
既然三種職務很難有一位經理人可以兼顧,與其強求而達不到效果,他們乾脆一不做二不休,把它直接拆成三個職位。

1、項目時間延續太長,學不到新東西

引發工程師無聊情緒最常見也最明顯的原因就是一個開發項目拖得時間太長。

2、維護代碼這種遺留問題讓人感覺太無聊

你可以重新寫一遍代碼,使用不同的編程語言或技術。通過這種方式,你會學習到新的東西而不是僅僅在遺留下來的代碼上修修補補。

3、工作只剩下複製 / 黏貼這種小兒科的東西

4、只能使用內部工具也太沒勁了

作為一個工程師,我們喜歡打造一個自定義的內部工具來解決某些特定問題,因為動手創造是一件令人興奮的事情。而且,構建一個定制化的解決方案通常要比找出一個現有的方案進行再利用要好得多。

5、如果不知道自己為何寫代碼,必然厭倦工作

糟糕的人力管理也是造成工程師對工作心生厭倦的常見原因。更具體地說就是:針對工程師的自上而下的獨裁式管理會讓他們產生抵觸情緒。

6、日復一日的工作總會不可避免地走向無聊

在一個封閉的工作環境裡長時間工作絕對會扼殺人感知生活的樂趣。這一點不僅僅是針對科技行業工作者或者是工程師職位,放諸於其他行業也是一樣的。

我們會積極地創造一些走出常規工作環境的機會。



如今在創業路上,家庭反對死一批,朋友同事嘲笑死一批,害怕失敗死一批,徘徊等待死一批「沒有時間」又死一批。
我就是不能把自己創業的想法告訴任何人,世道不安,也不知道哪個居心叵測的孫子以後會偷了自己的想法。
因為想法只佔據 1%,剩下 99% 是執行
因為不管你相信不相信,在你的想法提出前,絕對已經有人想過你的想法——甚至更可能,已經有人在不同領域實踐了你的想法。
因為世界上所有成功建立的公司,實際上建立在一個還湊合的想法和完美的執行上

我們的思想指引著我們的行為,健康的思想可以讓我們事半功倍,而有毒的思想往往會讓我們在職場上跌個大跤。
愛因斯坦曾經說過:「我們創造世界的過程也是一個我們如何思考的過程,要想改變世界,必須先改變我們的思想。」

特別是技術類型公司,單指寫程式的效率來說,最好的程式設計師,和最差的有很大的差距。有些研究說是 10 倍,有些說是上百倍。
一個為期 1-5 個月的專案,當目標和資源已經定義出來的時候,其實完成的時間早就已經被上帝決定好了。
當你打算完成的事情決定好產出的目標之後,時間早就已經被決定,你能夠做的就只是盡自己的能力,縮短預測的失誤

「當一個工程師難道不需要擁有電腦相關學位嗎?」Justice 提出了疑問。

「不需要,」Such 十分肯定地回答,「寫 code 好比焊接零件,這是一種技術,培訓工程師就是一門生意。」


在我們每個人在工作時間內,不僅需要做總裁,也需要做木匠。而老實說,那些做木匠的時光,才是真正讓我們在工作中有所成長的過程。

但是煩惱的是,總裁總是跳出來打擾木匠。

實驗室給兩組人,分別灌輸了相同的「健康很重要」、「你不健康會死」這種極其關鍵的健身內容。

實驗人員要求第一組人員親口保證,下週必須鍛煉——每個人都保證了,對天發誓一定會鍛煉。但等時間到了下週,只有 39% 的人真的履行諾言去鍛煉。

實驗人員也要求第二組人員親口保證,下週必須鍛煉。不過,實驗人員進一步要求人員保證鍛煉的詳細內容,比如下週什麼時間鍛煉、在哪裡鍛煉、怎麼鍛煉、鍛煉多長時間。而等時間到了下週,91% 的人確實按照他們所說的去鍛煉了。


你願意學習新語言的態度和意願,可能比那個高級的但已經不願意學習新東西的 java 程序員,更容易得到這份工作。

盡力完成,但不必期待完美
如果你心煩,代表你可能無法勝任現在的工作

維持高品質的代碼庫增加了整個工程團隊的工作效率。清潔代碼更容易便捷發展和維護,更適應變化,不容易引入錯誤。健康的代碼審查過程使之成為可能。
學習和得到充分得到挑戰是心理學教授米哈里· 米哈伊稱之為「流」,一個人是如此的完全集中在他們做的事情,他們甚至忘了時間。
A 等人聘請 A 等隊員。 B 等人聘請 C 等人。

當我們勤儉的吃了一個禮拜的便當後決定在假期給自己一天大吃大喝的機會,這種現象就稱為道德自我准許,它大大的影響了很多人養成習慣的計畫。
你會發現流動的空氣能讓人思考更清晰,讓你產生更多有趣的新點子。
不懂如何判斷事情先後順序
太多規劃
太少規劃

新創產品最好三個月內就上線,避免軍心渙散

整個產品研發過程中,所有人都互相尊重、互相合作,從一開始設計師、工程師、PM 都會在一起討論,做出來之後還會坐在一起討論,會馬上給一些反饋,然後馬上修改好。
不僅是工程師之間,還有和設計師、PM,他們也會參加一些討論,且我們一定要坐在一起,這樣類似 UI 上細節的問題,比如顏色、像素對齊等,都可以當面溝通。即使 Facebook 的遠程會議系統和線上溝通工具都已經很健全了,但公司還是鼓勵坐在一起工作。
在矽谷公司裡,在開發流程上我覺得最重要的就是:Code Review。

真正的資訊科學教育不在於寫程式,而在於善於利用電腦幫我們解決問題的能力。很會寫程式,卻不會解決問題,甚至發現問題,那麼我們還是會淪為軟體代工國家,與過去的硬體代工,並無多大差異。
不僅是工程師之間,還有和設計師、PM,他們也會參加一些討論,且我們一定要坐在一起,這樣類似 UI 上細節的問題,比如顏色、像素對齊等,都可以當面溝通。即使 Facebook 的遠程會議系統和線上溝通工具都已經很健全了,但公司還是鼓勵坐在一起工作。

大多數的人不思考
遊戲讓人快樂,因此你不會覺得累
但工作會讓你壓力重重

因為這些人完全沒有實現自己真正的生命價值

也沒有去做他們真正想做的事情

又為了麻痺自己,忘卻自己的人生多無趣

所以用各種娛樂來消遣時光


我的工作不是告訴工程師他們該怎麼做他們的工作,我的工作是解釋為什麼路線圖中的功能是適合客戶和業務的。
只要我能夠更多地向開發人員提問,並真誠地傾聽和學習,我就能更好地瞭解和代表他們的觀點。

1. 認為自己的解法是最好的,不願意溝通讓步。

2. 沒有顧及團隊合作,以及自己 Code 的易讀和可維護性。

3. 以技術不足、或專案困難為籍口,拖延工作及期限。

4. 應該要有比常人更好的待遇。

溝通能力 - 「我以為」不能是行動的依據

「Sudo 的 CEO Yvette,總是提醒我們不要把「我以為」當作解答,任何判斷應該要經過科學的驗證才是合理的。而我自己也曾經犯過「我以為」的錯。」

負責任-當遊戲規則更改為團體戰時,你就要對團隊負責

「尊重 deadline (期限),盡力令團隊更好才叫做負責任 ! 」


每個使用電腦技術的工程師大多靠自學成才,在工作中和自己的閒置時間提高技能。

學位的作用是讓你對程式設計和電腦相關的知識有一個全面的瞭解。有助於你瞭解更多相關的學科,例如數學、資料庫、演算法、網路、程式設計模式和語言。

你不需要成為任何這些學科的專家:但你需要知道它們的存在,並完善這些技能,並且在現實世界中使用這些技能以便於讓這些技能對我們真正有用。

當你開始使用這些技能來完成實際項目時,這些技能才會漸漸變成你的東西,否則就只是紙上談兵而已。根據興趣、工作或專門的計畫,特定地去學習某些領域,然後一步步前進。

你需要工作於一些小型的項目,以掌握具體的概念,但在現實生活中,在你運作了你的第一個版本之後,你就會不由自主地繼續前進。


肯打拼就能出頭天?或許對少數人而言是如此,但對大多數人而言,家境決定了一生成功與否。

社會學所談論的「階級複製」概念──有錢人的孩子有較多的人脈和成功機會,窮人的孩子極少能出頭天。


當 UI 設計師設計完介面之後,對 UX 設計師來說工作還沒完成,UX 設計師最終的工作是在使用者的大腦裡完成的,所以 UX 設計師永遠看不到自己的工作成果,只能透過使用者訪談或定性定量 UX 研究方法,去檢視使用者腦袋裡的體驗是否正確。


客戶在接觸到產品之後,才會真正明白自己的需求。

當我們向客戶展示產品的時候,他們才會意識到哪些是必需的。給出一個功能性原型設計,遠比一張長長的文字表格要好。

將複雜的東西整理成簡單的很困難,但是要是把複雜的搞得更複雜,那就簡單了。

這一條適用於程式設計、設計和幾乎所有的創造領域中。我一直以來都希望自己的 code 能越容易理解越好。如果你的 code 過於複雜和晦澀,那十之八九它正常運作的可能性很低。

永遠不要停止學習,一旦你停下來,技術的浪頭就會狠狠將你拍死在沙灘上。

作為工程師立於不敗之地唯一方法就是,不斷學習、不斷進步。因為一旦你鬆懈下來,你的所有優勢都將隨風而逝。

在這個不斷變化的世界中,評估(evaluation)是最為重要的技能。

這一點有些人可能並不知道。但是如果你願意認識新事物,看得到他人的努力,比較做事方法之後再擇優使用,那麼不但是你自己,還有你的團隊、你的專案、你的公司,都將受益無窮。

如果要全方位地看問題,再基於自己的需求選擇對應的最佳方向,這就很困難。


如今 95% 的產品經理做的 99.9% 的功能,都是有先例可抄可藉鑑的。衡量一個產品經理優秀與否,絕對不是他抄不抄,而是他什麼抄什麼不抄。


大量缺乏基本專業素養和工作經驗的人擔任了 PM,造成的結果就是:產品做的一塌糊塗,連正常的使用流程都走不順利,研發被拖的疲於奔命。

有些人可能說:PM 需要好的 EQ,溝通表達能力強,會畫原型,懂交互,對常見的產品交互模式瞭若指掌,甚至要會哄著研發人員幹活。

OK,這些都沒錯,但是這些能力並不是一個專業 PM 的核心能力,都是可有可無的。

抽象思維能力

抽象思維能力對專業級的 PM 來說是第一重要的能力,無論是企業級產品客戶提出的各種具體需求,還是消費級產品使用者提出的各種回饋,都是特別具體的一個一個「點」,好的 PM 要能夠從這些具體的「點」的背後抽象產品的本質需求和內在邏輯,這是一個 PM 的基本功。

邏輯思維能力

一個不具備邏輯思維能力的 PM 對研發人員來說是像哥吉拉一樣恐怖的怪獸。因為研發人員最終要用程式去實現這個產品,一旦產品無法在邏輯上說得通,產品在開發階段就根本走不下去了,其最終的結果很可能是研發人員背黑鍋。


階段一:我是經理,大家都得聽我的,純管理人的角色。

階段二:我是產品設計師,我負責提需求,做交互,大家按照我的想法做。

階段三:我是用戶,我負責體驗產品,大家和我一起優化。

好的服務必須要盈利

好的服務必須要有好的技術支持

好的服務必須要有好的用戶體驗

Usability:你的產品究竟能解決什麼問題。

Identity:你的產品究竟能讓用戶感到什麼不一樣。

Meaning:你的產品能為個人和社會實現怎樣的願景。

作為一個好產品的自我修養是不要讓開發替你填坑,而是你盡可能的輔助開發減少腦力消耗。

對於前端服務,盡可能追求極簡主義,不斷學習設計知識,反複測試,在不影響用戶理解的前提下,盡可能去除不必要的元素。


沒有人願意被貼上了糟糕工程師的標籤,但一個可悲的事實是,很多開發人員沒有意識到他們自己就屬於這一群體。沒有人願意問自己:我是一個糟糕的開發人員嗎?

牛仔工程師

1. 編碼速度非常快:然而,不幸的是,那麼不懂代碼的人,因此會認為這些「快槍手」很厲害

2. 凌亂、不可讀的代碼:意大利麵條式代碼難於理解,並且通常沒有必要那麼龐大和複雜,從而導致了其他人難於理解工程師的所作所為,因此這種代碼通常是維護的噩夢。

3.Bug,無處不在的 bug:在牛仔程序員身上,還有一種常見的情況是,在他們迅速「修復」一些 bug 的同時,創造出了更多的 bug。因此他們總是感覺很忙,就像英勇的消防員,疲於到處滅火。總而言之,每一個糟糕開發人員創造的 bug 和錯誤都會導致消耗生產力。哪怕剛開始的時候,他們看上去很牛,總是能按時完成其他開發人員不敢輕易允諾的編碼任務,但是這是以各種意外錯誤頻頻降臨為代價的,而這原本可以通過優秀開發人員的精心設計和簡潔代碼編寫扼殺在襁褓中。

自大:有的牛仔並不壞,因為他們只是根據管理 / 客戶不可能的期限要求,才生產出了意大利麵條式代碼(但是,那些重視自己代碼的開發人員會選擇離開這樣的公司或拒絕這樣的客戶)。這些初學者通過接受來自於資深的優秀的開發者的指導,是可以改正的。但是,如果他們的身邊盡是和他們一樣或平庸的開發人員,那麼他們就會陷入自我感覺良好的錯覺中。

使得這些工程師變得糟糕的最重要​​的屬性,是自大:最糟的是,糟糕的工程師都不願意聽別人說教,不願意從錯誤中學習,因為他們不承認他們犯了錯誤,正如前面提到的,他們通常會推卸責任。請注意,這並不意味著牛仔在現實中就是難相處或低智商的人——也許他們就是你遇到過的最和藹親切的人——但是,在他們面對批評的時候,卻有著一種根深蒂固的自大和不願意承擔過錯責任的心態。

平庸的開發者

這裡我指的平庸意味著「不能勝任」。在某些方面,平庸的開發者比牛仔更糟,因為他們知道自己不能夠勝任,卻不願意去努力,滿足於停留在技能階梯的底層。

平庸的開發者通常對寫程式缺乏興趣,因此在理解概念方面有困難。他們需要很長的時間來創建一些東西,同時生產的代碼欠佳並且充滿問題。他們通常對毫無沒有激情 / 興趣可言,他們在學習新技術時進展緩慢,或通常沒有實際的操作經驗。

優秀的開發人員

MVP 型開發者不希望只是簡單地解決問題,他們會努力尋找解決問題的最佳方法。

MVP 型開發者有著強烈的好奇心,會不惜一切代價地去尋找事物為什麼工作或不工作的原因。

MVP 型開發者自信且謙遜,因為他們始終牢記,三人行必有我師,他們喜歡和更優秀的人才一起合作,因為他們能從這些更好的開發人員身上學習。


看書

自己看書有個缺點是容易閃神、容易疏失一些細節與重要觀念,「畢竟不是每個人都可以無遺漏的看完,而且真正會乖乖看完的人也有限。」

網路自學

多如牛毛,但同時它也切得很散、缺少系統性。

懂了工程原理後,設計師在與工程師溝通時會更順暢,產品的開發流程也比較不會因設計、工程打架而拖延。

「系統面不同,會導致設計流程的不同。如果設計師學會 coding,那麼他們在和工程師溝通上會有更清楚的概念,也能更快理解工程師的工作,讓兩者間的溝通能更順暢。」


開發者的高速成長期:

初級開發者必須要專注代碼本身,在這個階段,不要分心想任何其他亂七八糟的事情。在開發一個專案時,如果身為工程師想的是「我想讓自己的代碼在別人眼裡看起來漂漂亮亮的」,而不是「我做的東西應該以用戶感受第一」,那麼他本身就是一個初級開發。

中級開發者的瓶頸期間

中級開發者很清楚自己在團隊中的角色,能認識到他們為團隊工作帶來的價值。一個好的中級開發者知道代碼是用來解決問題的,而不是用來終結問題的。然而,中級開發者總容易陷入一種認知上的金字塔,那就是他們會遵循一些「正確的方式」去解決問題。

高級,甚至是大神開發者需要滿足的條件

如果你的團隊中缺乏高級開發者,那這個專案基本都無一例外走向失敗。擁有中級開發者能讓你做事情非常快,但是在工作中你會發現,專案不僅僅只是搭造和維護程式。最終你只能關閉網站,或者用比預期中更高昂的價格維護它。只有高級開發者能選擇技術和網站,而不是任由他們來傷害你。


成為高效率開發者這件事你可以通過經驗、書本、或者試驗和錯誤來學習,但最有效方式之一,就是直接向高效開發者學習。

在別人沒法干擾你的時候工作

實際上「正常」工作時間內我幹不了什麼事情,只有靠加班時間才能完成事情。 —匿名

我通常在早上 6 點到 9 點間能夠幹的事情比一天其他時間能幹的都要多,長時間的不受打斷至關重要。 —匿名

工作 / 生活平衡

有一位比你還要努力的「重要他者」是有幫助的,不然的話你就得自己扛了。我的做法是保持彈性,有時候我會衝刺一段時間、再放鬆一下。大概是高強度 2 個月然後放鬆 1 個月這樣子。在我看來,這要比 3 個月保持相同節奏更高效(不過這一點並不適合每個人),因為工作不是線性的。 —匿名


很多作家每天還是大量閱讀別人的作品,欣賞和學習別人的才華。日常所讀的文章,多半比自己所寫的多得多。藝術家、建築師也不是整天埋頭苦幹,常常要去看過別人的作品。

從大量「閱讀」開源程式碼開始訓練自己,到達能夠「悅讀」高品質的開源程式碼,進而對重要的開源程式碼計畫做出「貢獻」。

(1) 多讀優質的開源碼,有助於英文的學習。

(2) 程式設計的訓練,有助於英文寫作。

(3) 英文能力的提升,有助於理解高階的程式碼 。

(4) 英文能力和程式能力的提升,有助於與國外交流以及走上國際舞台。


自學是件苦悶的事情,它要佔用你原本可以用來娛樂的時間。

為什麼別人看電視的時候,你要聽課?

為什麼別人刷網頁的時候,你要讀書?

為什麼別人逛淘寶的時候,你要寫筆記?

為什麼別人玩遊戲的時候,你要查資料?

為什麼一個人願意在下班後每天花上幾個小時的時間坐在書桌前學習?

所以自學最難的地方既不是學什麼,也不是怎麼學,而是怎麼堅持,因為你要不斷地和自己的惰性做鬥爭,和各種各樣的誘惑做鬥爭,和輕鬆舒服的安逸做鬥爭。這麼難,怎麼辦?

方法只有一個——養成習慣。是的,習慣。

為什麼一定要自學?

1. 解鎖加速學習的技能

自學,未必能夠給你帶來好的工作、好的運氣、好的報酬。但是,學習到一定程度,你會解鎖一個關鍵技能:融會貫通,之後你的學習速度就會呈幾何增長。

2. 獲得階梯式的成長

一個人跑去問老闆「我都有十年工作經驗了,為什麼您還不幫我加薪?」,老闆回答說「你是有十年工作經驗呢,還是把一年工作經驗用了十年?」

工作的前幾年往往是一個人成長最快的時期,當你一切都能得心應手、熟悉應對時,很容易進入一種平和的溫水煮青蛙的時期。


「長時間工作一點也不高效。假如你工作八小時,試試五小時,或者甚至只工作四小時。如果你只有這麼多時間來工作,你就不會有空在工作的時候去看推特了。」

當我讀塔勒布的書《反脆弱》的時候,他也提到長期保持較高的工作效率的技巧是每天只工作一段的時間。

為什麼每週四十個小時不管用?

我經常只能在頭幾個小時專心工作。我工作時間持續越長,我就越不能專心。

每天工作短短幾個小時

首先,我最高效的時間是我起床之後。所以我需要睡個好覺,醒來之後立刻開始工作。我並不看新聞或者社交網路。因為即便我只看一下下,就會由於注意力被分散而影響我的工作效率。

工作到死

在我不想停的時候停止工作,最好的方法是保持長期工作。這樣做,就好像讓我像馬拉松運動員那樣一直勻速跑著,而不是埋頭苦幹然後提早退休。


固執

當我真的累了的時候,似乎總是更容易執著於我正在走的一條壞路線,而不是反思路線是否正確。因為把終點設在了海市蜃樓,於是我得在茫茫沙漠中走更長的時間才能找到綠洲。

缺乏創造力

區別那些比普通工程師的效率高 10 倍以上的工程師的標準,不是他們能多寫 10 倍的代碼,而是這些高效的工程師使用創造力的話,只需要十分之一的努力就可以解決問題。但當我累了的時候,創造力急劇下降以致於想不出創造性的解決方案。

士氣減弱

當我的大腦不是火力全開的時候,它喜歡投餵一些要求不高的任務飼料。比如說,這一天我閱讀了 5 次 RSS 訂閱,又閱讀了一些其他無關緊要的內容。去攻克真正重要問題的積極性和士氣銳減。

煩躁

如果你碰到一個像炮仗一樣一點就著的人,那麼他很有可能正經受著睡眠被剝奪的痛苦。當你疲倦的時候,你的耐心和忍受力就會受到嚴重的影響。我很清楚當我沒有充足睡眠的時候,我的狀態最糟糕。


學習,並非為了成為「程式設計師」

「當你學會閱讀,你便能藉著閱讀學習更多知識,程式設計也是一樣的道理;如果你會撰寫程式,你能透過程式語言學習到的事物將更為多樣。」學寫程式就是在學習創意思考、有系統的推論、和團隊合作,而這些技能不僅在各專業領域都受用無窮,更是生活中不可或缺的能力。

他也在學習該如何設計 怎樣將某個靈光乍現 變成一個成熟的、可以運作的專案 所以他在學習很多不同的、核心的設計原則 怎樣實驗新的想法 怎樣將複雜的槪念分割成更小的單位 怎樣與其他人合作發展你的專案 當事情不對勁時,怎樣尋找、糾正程式中的錯誤 如何堅持下去並且再接再厲 當面對事情發展不如意,這些挫折的時刻 這些都是重要的技能 而且它們並不是只與編寫程式相關 它們關係到所有不同的活動 但姑且不論他將來會做甚麼 他都會能夠運用他學到的這些設計技能 這些槪念對每個人都很實用


我面前有兩條路可以走,要麼做技術管理,要麼繼續當工程師。我選擇了當工程師,因為這項工作更簡單。到了今天我終於意識到這個決定是多麼的糟糕,儘管過去 20 年 我做了那麼多很棒的東西出來。

我目睹了身為工程師的擁有的能力是多麼的弱,不管你程式設計、創造不同或者修復破壞的東西表現得有多出色。我當時完全沒有意識到身為工程師(或者架構師之流)你的進步空間有多狹窄。你就是一個螺絲釘,根本沒有那種改變現狀的能力。除了少了財務方面的好處以外,更高份額的 IPO 參股的可能也更低,能接觸到的東西更少,作為工程師你的對有機會開發很酷的東西感到滿意。

在銀行當工程副總裁意味著他不需要理解技術,因為他管理的是人,但技術決策還是由他來做出。

我還可以繼續做事,但關鍵是你沒法從技術角度改變別人的做事方式,除非你有那種機會和權力。一旦你做出了正確的決定並且找到了合適的地方去發展,講真,只有天空才是極限。

作為一個有將近 35 年 經驗的工程師,值得欣慰的是我現在還能做東西,還能找到樂趣,這些年還能做一些令人驚豔的東西。但我還是對沒有直面當領導的挑戰感到後悔。從某種程度來說變成是容易的選擇。

我後悔沒有做出那個選擇,後悔沒有看到它本該可以引領我去到哪裡,但我也可能會失去寫代碼所帶來的所有樂趣,體會不到那些讓人精神枯竭的工作完成後修復任何東西帶來的成就感。


1. 工具不能代替思考

2. 除非管理小組能夠真正懂得敏捷「轉變」的價值,否則它就不能發揮作用

3. 學習需要一個安全的環境

4. 每個人都可以成為領導者

5. 架構師去寫代碼往往能作出最佳決策

6. 改變需要勇氣

7. 建立信任的關鍵是言行一致

8. 成功的結對程式設計與良好的協作相關

9. 多模式思維促進更強大的結果

10. 認識到每個人都有不同的優勢

11. 終身制學習

12. 積極的影響迸發幸福感


學英文

為什麼?因為英文真的很重要!聽說讀寫,至少讀要讀的懂,你才看的懂那些外國公司的 API 文件,發生問題的時候,才能去 stackoverflow 上面發問。

一個好的問題,或是說,讓人看的懂得問題,應該要包含四點:

1. 目的(你的程式要達成什麼目的?)

2. 手段(你怎麼達成你的目的?)

3. 錯誤(在什麼場景下發生的什麼錯誤?)

4. 程式碼(有排版過的程式碼,拜託)

試著理解它

若是不理解,你就只是個只會複製貼上的機器人,一點成長都沒有,至少要理解到兩點:為什麼有這問題、這個解法是如何解決的

每種程式語言都有不同的適合的場景,還有一點是,「每種程式語言,都有很大部分是相同的」,例如說:變數、函式、迴圈、條件判斷、陣列…

不管學哪種程式,都會碰到這些最基本的東西,無論是再複雜的程式,都是這些基本的東西組裝而成。

學程式學的應該是「心法、內功」,而不是表面的限制,這樣就算換了一個你從沒看過的程式語言,你也會猜的到它在幹嘛。

「如果以蓋大樓來形容這個概念,把砌磚作為一種技能,把蓋大樓作為一種知識。我想可以這麼講:如果你早就知道你喜歡砌磚,很會砌磚,就直接去砌磚吧。如果你的夢想是蓋大樓,你要學的東西還很多,那讀大學是你最好的途徑。不是每個人都要蓋大樓,靠砌磚就可以賺錢了,砌的好還可以賺很多錢,大家搶著要。」


許多人看到一些不實的宣傳都會覺得:「什麼!只要上課幾個月以後就可以月收入七八萬,那我要快點去寫程式」

花大錢上完課找工作才發現薪水還是跟之前沒差多少

寫程式是一件簡單的事情沒錯,尤其是最近程式的入門門檻愈來愈低,真的到了人人都可以寫程式的年代 但相信大家都聽過一句話:「易學難精」 這種門檻很低的東西,人人都可以學會,那怎麼會有公司缺這種工程師? 有啦的確是有,那些課程你修完之後應該是有基本的一點點實力,可以找到一份工作養家活口 只是薪水應該不會太高,因為取代性太高了 任何沒基礎的人學三個月都能跟你做一樣的事,薪水會高到哪裡去?

寫程式是一件很棒的事情,是一件很有成就感的事情 如果你是因為喜歡程式所以跑來學怎麼寫程式,那歡迎你,你可以自由自在、無拘無束的學 但若是為了轉換人生跑道,覺得寫程式很好賺來寫程式的話,給你一些忠告

1.不要相信那些上完半年課就月入七八萬或是年收百萬的鬼話

2.課程只是帶你入門,你還是得自己去鑽研那些更有深度的東西

3.努力、堅持


第一,寫程式的人(Coder、Employee、Worker)

寫程式對他們來說枯燥無味,但為了生活,他們繼續產出他們的程式碼。

第二,有目標而寫程式的人(Hacker、Doer、Entrepreneur)

他們會去找既有的資源架構,嘗試做出原型(Prototype),有時候雖然做出來雖然有點破(像是下圖右方的機器人),但他們樂在其中,並且常常不眠不休的寫程式。

第三,熱愛程式本身的人(Architect、Theorists、Change Maker、Geek)

他們喜歡寫有架構、能夠被別人重複使用的套件(Library)。他們樂於貢獻自己所知所學到這個世界,並且常常在想有沒有什麼最新科技、理論能夠套用到某個工具或服務上,讓這個服務更快、更大、更好。

Coder的工程師思維

Coder因為只想把事情做到交差了事,因此他們每天的任務就是把上面說要做的事情完成,一分不多、一分不少。

Hacker的工程師思維

Hacker知道怎麼完成一樣事情,但技術沒有這麼高超。他們重視目的和UX,因為他們喜歡使用自己做的東西。

當有任務下來,Hacker不會讓使用的細節從眼前溜過,他們會默默的將設計不完整的地方補完。有時候他們甚至會和管理者爭論,這個Feature到底該不該有,因為他們認為使用者不會喜歡。

Architect的工程師思維

Architect的工程師思維源自於兩個面相,第一個是他們喜歡有秩序、可以永久保存、重複使用的東西,第二個是他們無私的想要貢獻自己做出的東西給這個世界。

一個好的產品設計,從工程上面來看應該也要是規律、優雅而有深度的。若工程設計本身具有規則,使用者在使用時是可以隱約感受到其背後令人舒適的邏輯的。因此我認為Architect喜歡秩序的工程師思維是好的。

我想人們之所以會走向不同的工程師類型,和工作環境、投入的Project也有很大的關係,即使在Google,也有很多聰明的人因為一些因素成為單純生產Code的Coder。

希望每個工程師都能選擇自己想走的路,生活、創業、貢獻...一切都是自己的選擇


我不斷地苦口婆心地招攬人才,希望他們都能夠接受這次工作機會,即便薪水低的給了跟沒給一樣。

我相信,自己會成為全公司裡面最冷靜,最自律,也最能鼓舞人心的創業者。

1. 簡潔真的具有超級強大的威力

新創公司的最核心的優勢就體現在「專注與速度」上面,而一家初創公司的領導人更應該在專注上面做到更加專注。


常常看到非資訊背景的朋友問工程師:我最近想學寫程式!該怎麼入門?

通常他們會得到很多糟糕的答案:「先了解演算法」、「先弄懂資料結構」、「先認識物件導向」。

而這些想學coding的朋友,大部分只是這兩種情況:

A. 最近覺得寫網站好酷,想試試看自己能否寫個blog、或是個人網頁

B. 對工作上某些人工流程不滿意,想試試看自己能否學寫程式、用電腦解決問題

他們的願望僅此而已,並沒有打算成為電腦專家、駭客,實在沒有必要從C/C++入門。

就像點火一樣,先從零星的火苗開始、小心保護不要讓它熄滅,接著慢慢加東西進去、讓火焰慢慢成為大火。學習,除了知識/技能之外,培養成就感與熱情也是很重要的。


一、不害怕探索陌生程式語言

跳脫舒適圈的恐懼往往多於學習程式,會擔心是否無法重現過去工作的好表現,甚至因此懷疑自身能力。

學習陌生程式語言這項關鍵能力會越練越上手,並讓你在學習過程中成為更好的程式設計師。

二、精通Debug

想加快Debug速度,要提升「提出假設」和「檢視假設」的能力。假設能力可隨著Debug經驗的累積而提升,檢視能力則需加強善用檢測工具的技能。

三、開發節省時間的工具

團隊中表現出色的人多數寫了許多工具,這些看似和績效無直接相關的工具開發時間可能佔三分之一的工作時間,卻因此大大提升工作效率,其中包含用來部署程式、監測系統,以及其他可節省時間的工具。

四、優化重複性工作的速度

每次搜尋需花12秒,類似的步驟每天要重複20次,若用快捷鍵可將搜尋時間縮短到2秒,一年下來即省了40個小時。

五、發展系統性思考模式

寫完程式碼、讓程式可運作僅是冰山一角,要產出真正有價值的程式,必須從程式本身提升到整個系統來思考。


人們能用意志力改變行為,但如果我們不了解行為背後的生理基礎,我們就不能輕易說出『靠意志力就能解決』這樣的話。


溝通與社交能力,比天份重要

基本上就只是跟對象好好的坐下來討論他們遇到的問題與解決方法

一個人是沒有辦法成事的,你需要有你的團隊

沒有溝通與社交這兩項能力,根本不會有團隊可言


書讀多了,容顏自然改變,很多時候,自己可能以為許多看過的書籍都成為過眼煙雲,不復記憶,其實它們仍是潛在的氣質里、在談吐上、在胸襟的無涯,當然也可能顯露在生活和文字中。

運動重在自強不息,速度和距離只是表面,更重要的是鍛鍊人的意志力、自制力、承受力、自信心,表達一種堅韌不拔的人生態度。


人總是由環境決定的,沒有天生的壞脾氣,所謂的壞脾氣大多數都是後天養成的臭毛病。而那些總愛發脾氣的人,其實是從來不考慮別人感受的,說到底就是自私。

事實上,越是能力強的人,越是好脾氣,他們明白髮脾氣是無法解決任何問題的。

越有本事的男人越沒脾氣。因為素質,修為,涵養,學識,能力財力會綜合一個人的品格。


成為一名程式設計師,需要多少時間與金錢?

就如身邊許多求才若渴的朋友們說的:「求職者很多,可用的不多」

程式人得掌握與熟悉某些框架,也要知道技術生態系中的慣例,認識某些模式與最佳實踐,瞭解怎麼處理錯誤,在運用技術便利性的同時,別忘了資料結構、演算法甚至數學等基礎理論的重要性

大多數時間上,程式開發者只關心如何寫出正確功能的程式,卻少了安全方面的防護

旅程才剛開始,這之後還得經過信心大失、不知天南地北等兩個階段,才能進入逐漸獲得正向回饋的階段,獲得用程式設計糊口的能力。

十年磨一劍的比喻並不誇張,相信這條路上,還有許多東西要精進,而不只是以那些速成或快速開發的噱頭而自滿,也才是對這門行業的尊重,尊重自己的行業,別人也才能尊重程式開發者


人力資源部對求職者的過去的工作有種與生俱來的追究愛號,問在哪裡做過,做過幾個項目,為什麼離職,平時喜歡做些什麼。其實這都是費話

做技術的,一般都沒有那麼能說會道的能力,被刷掉的可能性太大。

公司是看能力的,等你做出成績後,公司會考慮你的合理要求。請記住,入職時工資就是你的全部。

今年一波人走,又招聘來一波人,對技術主導型的公司傷害太多

想維持一個穩定的team,把那麼幾個關鍵的員工把握住了,這項工作就做好了。

做技術的員工,很老實的在自己的崗位上工作,卻因不懂辦公室政治而被迫離開,而且還要說是自己有問題,公司是對的。對於一個漂在異鄉的人,這給人一種很無奈的蒼涼。


長期浸淫於資訊技術領域的人們多半是「技術思考」,直線 / 快速 / 效率 / 邏輯這些特質是技術人想事情的本性,沒有不好,只是過去我們是這樣子被訓練出來的,快速的演算法,更快速的資料存取,更厲害的資料壓縮與傳輸技術。

但是當我們要把軟體應用設計出來給人們使用時,技術人並沒有受到夠多的訓練,去了解人的本性與限制,去嘗試發散創意或跳躍思考,或更深入的思考什麼是真正的問題,什麼是有價值的問題,什麼是脈絡下的隱性需求。

Design Thinking 概念很容易理解,關鍵在實際動手做,把 Design Thinking 變成 Design Doing


大學的教育主要是幫助你進行人格、性格和思維的塑造,比如說數學分析能讓你更加理性堅韌而又不失變通,離散數學可以讓你感受結繩記事以後,人類思維的演變。

人的大腦不是一成不變的,你可以透過訓練讓大腦裡的回路鋪設更適於做某一種事

釐清排斥的原因,重新調整心態

還有一個技巧就是虛極靜篤,很多時候你不接受一個概念,是因為你自己心裡已有的觀念太強了,讓你不自覺地產生了排斥。


人才是企業最重要的資源,但切勿為了某個天才顧此失彼

Rick 工作不需要別人,他寧願在做自己的私人工作空間裡獨自工作。

Rick 也不需要任何人建造的任何東西。他可以從頭構建他需要的一切東西,因為凡人給他提供的東西都太微不足道了。

很快,Rick 就不再參加會議,他沒時間開會,因為要寫的程式太多了。

Rick 關上了辦公室的門,白板也停下來了。他不再有時間幫別人培訓,他自己的問題都還解決不完。

Rick 身後的事情不斷積壓,他之前創建的工具不斷冒出 bug,這些使得他無暇預估新產品的開發。

首先,他創建了一個必須依賴他的「邪教」:所有的問題在最後都會變成 Rick 的問題。助長了個人迷信色彩。開發者們不再嘗試自己解決,就那麼等著看 Rick要怎麼做。

第二,他不寫可讓大家維護的程式碼。從來不記錄也不測試,所以儘管天資聰穎,仍一敗塗地。他對自己才華的盲目自信戰勝了一切。

第三,他這人性格就帶有破壞性色彩。團隊成員不願向他坦誠自己的意見或建議,因為他動輒就會訓斥他們。Rick 尊重的人只有他自己,除此之外,他藐視一切。

第四,他缺乏責任意識。哪次失敗也不關他的事,他始終堅信這一點,所以無法從錯誤中汲取教訓。

整個團隊意識到他確實有毒。但是這個團隊成員對他依賴性太強,以至於人人都覺得他是他們唯一的選擇。

要記住,永遠都有別的選擇。

團隊的優勢不是在於個人的才華發揮作用,而在與整個團隊間通力合作、堅忍不拔、互相尊重。

團隊建設要注重彼此尊重、互相激發出最好的那面,做最好的自己。


老闆很高興,因為他幾乎讓每個員工保持“忙碌”,但是,他們在工作中,是以什麼樣的速度來完成呢?他們確實做了很多事情,但實際上並沒有那麼多。

第一,在必要的時候無論做什麼都要做到最好。

第二,就是教會別人,這不僅是給他人也是給整個團隊的禮物,以後回饋到他們的身上。

第三,就是走出舒適區,向團隊裡的其他人學習,在出現瓶頸時可以做不同的工作來緩解系統壓力。

第四,就是和老闆合作,這樣可以幫他們擺脫困境。這一切很違反直覺,是吧,但今天太多的管理人員根本就沒有領悟到。他們讓人們限於孤島,讓人們保持忙碌,“忙碌”似乎成了他們的關鍵性指標。他們讓人們著手做很多工作,但卻忘了把工作完成才是真正重要的事情。


「因果關係」與「機會運氣」都要同時下注才是更全面的策略。尤其當「機會運氣」所需要的下注資本很低的時候。花一點小小的資源,來換個「萬中選一的好運氣」是值得的。

要中獎的第一個訣竅是,你得去買張彩券。

很多人還是被「線性思維」給綁架了,不願意大膽直接朝目標做些無傷大雅的嘗試,只願意像公務員一樣遵循自己預設的SOP。背後的原因除了是被升學主義的思維框架所限制外,另一個深層的心理因素就是恐懼!怕自己被拒絕而失敗的恐懼!

一個平衡且成熟的大人,不會因為恐懼而墨守成規,也不會因為貪婪而投機取巧,這是過度仰賴「因果關係」或「機會運氣」的兩個極端。


大學教育的價值不在於弄懂許多已知的現象,而是培養你的心去思考那些無法從課本上學到的東西。

只有一件事情比沒有獨立思考的能力更可怕,那就是以為自己有。

一知半解的話還不如不會,平生工作最害怕就是遇到說:「我以前也有寫過程式」、「我以前也有技術背景」的人

「東西會動就好」這句話沒有錯的前提是有基礎能做好,但時程安排卻不允許所做出的 trade-off;說得誇張一點,選擇「會動就好」其實也是一種基於專業經驗所做出的判斷。

我不否認學習這套框架的話能夠「簡單」地生出一個包含前端跟後端的網頁來,但使用跟活用是兩回事。

只要需求一變動,往往就被殺了個措手不及,而這樣的情況只是被框架所框住,而不是真正的在運用框架。

最後一個角度是「出國工作」,「寫程式」相較之下不需要那麼多「語言能力」。想想是還不錯,走向國際又有競爭力。

除非你超厲害或是超便宜,不然為什麼要找一個不太會講當地語言的?前者值得驕傲,後者的話就點到這裡為止好了


1.對工具技術有深入的掌握度

2.能寫出可理解可維護的程式碼

3.選擇技術的能力

4.軟體架構分析與設計能力

5.圖像解說能力

6.能綜觀全局的能力

7.嘗試導入對團隊更好的流程

8.真正能完成一件事的自信

9.不斷地自我提升

10.臨危不亂

11.樂於分享所知

12.溝通受人敬重

13.勇於認錯、自我反省


設計本身是一種需要反覆迭代進行的程序,但是太頻繁的來往溝通,可能會殺死程式開發者的專注力與工作效率,也無法使企畫設計者的想法得到迅速的反饋。


「通常畢業致詞者會祝你們好運還會祝你們心想事成,但我不會這麼做。我會告訴你們原因。

在接下來數年的三不五時間,我希望你們被不公平對待,如此你們才知道公平正義的重要。我希望你們遭遇背叛,如此才知道忠誠的重要性。

很抱歉要這麼說,但我希望你們有時感到孤單,這樣才不會把朋友當作理所當然。

我希望你們三不五時遭遇不幸,如此才能意識到機率和運氣在人生中扮演的角色,了解成功不是完全你所應得的,而他人的失敗也不是他們所應得的結果。

當你們失敗時,人生三不五時一定會有失敗,我希望你的對手會對你的失敗幸災樂禍,讓你們理解運動家精神的重要性。

我希望你們遭忽視,如此才會知道聆聽他人的重要性,我還希望你們遭遇足夠的痛苦來學習同理心。

不管是否來自我的希望,這些事終究會發生。至於你們是否能從中獲利,則取決於你們從不幸中獲得訊息的能力。

畢業致詞者通常會給學生一些建議。他們會給一些廣泛的建議,也會給一些有用的小撇步。

最常給的建議就是:做自己。給所有穿著一樣的人如此建議實在有點怪,但你們確實應該做自己。

只是你們得了解做自己的意義何在。除非你很完美,否則做自己不代表不能接受改變。

在某些狀況來說,你不應該做自己,而是應該變成更好的人。大家說『做自己』是因為他們希望你們能阻擋外界要求你們做的事,但除非你們了解自己是誰,或思考過自己是誰,否則無法『做自己』。」