出處：https://www.artima.com/weblogs/viewpost.jsp?thread=259358

大家總是問一個錯誤的問題：“我應該學習C++還是Java？”在本文中，我將告訴大夥兒：對於選擇程式設計生涯真正需要關注的是哪些問題。

請注意，這篇文章的目標讀者並不是那些已經做出自己選擇的人。（對於這些人而言）你會繼續自己的程式設計生涯，而不管別人會怎麼說。因為它已經滲透到你的血液中，你已經無法擺脫。你已經知道答案：C++、Java、Shell指令碼、Python、還有其它一大堆的語言和技術，你都理所當然地會去學習。甚至有可能你才僅僅14歲，就已經知道好幾種不同的語言。

問我這樣的問題的人可能來自其他行業，或者來自諸如Web開發之類的領域。他們知道HTML是一種類程式語言，而且想嘗試構建某些更大型的應用。但我特別希望，當你在問這個問題時，你已經意識到了想要在計算機領域取得成功，你需要掌握自學能力，而且永不停息。

在這個領域做得越多，我越覺得軟體開發比任何行業都更接近於寫作。 我們從來不知道是什麼造就了優秀的作者，我們只知道什麼時候我們會喜歡某個人的文字。程式設計不是一種工程，僅需要把東西從入口倒進去，然後再轉動手柄。把軟體開發看成確定性的，是一個誘人的想法。因為這個想法，人們總想搞出一些工具來幫我們開發出想要的軟體。但是我的經驗告訴我，事實並非如此——人的重要性遠高於流程。而軟體是否執行在一部精確的機器上已經越來越不重要了——這猶如測不準原理對人類的影響。

我的父親是造房子的，小時候我偶爾會幫忙打下手，放放磚塊之類。他和他的木工告訴我，他們是為我好才讓我幹這些活——這樣我就不至於走入這個行業。事實確實是這樣。

我們不妨把軟體開發比作蓋房子。造房子的人當然不可能完全一樣。這些人裡面有：混凝土工、屋頂工、管道工、電工、磚瓦工、水泥工、瓦片工、搬運工、粗木工、細木工。當然，還有工頭。每個工種都需要相應的技能，這些技能都需要花時間和精力去掌握。跟軟體開發一樣，造房子也是一個“建立/推翻”的過程。如果你想很快地獲得回報，你可能從搬運工和磚瓦工開始做，這樣的話，你無需太多的學習曲線就可以獲得回報。當需求很多時，你的工作會很穩固，甚至收入也可能提升——如果沒有足夠的人手的話。但是，一旦行情不妙，木匠甚至工頭就可能把磚瓦工一腳踢開。

當網際網路剛剛興起時，僅僅是花一點時間學習HTML，你就可以得到一份薪水豐厚的工作。但是當形勢慘淡時，對於技能的要求更高了——HTML程式設計師（就像搬運工和磚瓦工一樣）第一個被拋棄了，而擁有更高技能的程式設計師則留了下來。

我想說的是： 除非你準備活到老學到老，不然的話，不要進入這個行業！程式設計看起來似乎是一個高收入而又穩定的工作。但要做到這一點，唯一的途徑是：始終讓自己更有價值。

當然，你總能找到例外。總有那麼一些人，僅僅學了一門程式語言，就可以勝任留在一個崗位上，而不需要增長他的技能。但他們只是倖免於難而已，他們最終無疑是很脆弱的。為了不讓自己變得脆弱，你需要持續的提高自己，通過閱讀、加入使用者組、參加研討會...... 你學得越深入，你就越有價值，也就意味著你有更好的職業前景，可以配得上更高的薪水。

另一個方法是：先大致瞭解這個領域，找到最適合你的地方。打個比方：我的兄弟對軟體很感興趣，也入了這行，只不過他的工作是安裝、維修、升級電腦。他總是一絲不苟，所以當他把電腦搞好，一定會很完美——不光是軟體，連電線都會被仔細地捆好。他總是生意興隆，遠超出他的精力所能及。他甚至都不用擔心 .com 泡沫的崩潰。顯然他的飯碗不容易被搶走。

我在高校裡待了很久，甚至還在UCLA（加州大學洛杉磯分校）進修博士學位，後來又幸運地終止了。我說“幸運”是因為我不再喜歡呆在學校，而我之前在高校待了那麼久，只是因為我很享受它。但我所享受的，基本上是不務正業的東西——藝術和舞蹈課，在校報工作，還有一小撮計算機課程（之所以說計算機課程“不務正業”，是因為我本科是物理專業，研究生才是計算機專業）。雖然我在學術上遠談不上卓越（有意思的是很多當時也許不會接受我這個學生的學校現在卻用我的書做教材）。我真的很享受作為學生的日子，當我完成博士課程，也許會以一個教授的身份終老一生。

但就如現在看到的，我在學校裡最大的收穫恰恰來自我那些“不務正業”的課程，它們擴充了我的思維，使之超越了“我們已經知道的東西”。在計算機領域中，你總是為某種目標而程式設計。你對目標瞭解得越多，你就做得越好。我遇到過一些歐洲的研究生，他們需要結合其它專業領域來搞程式設計，他們的論文需要解決這個專業領域的特定的問題。

瞭解程式設計之外的領域，將會極大得提高你解決問題的能力 （就如同多學幾種程式語言將極大地提高你的程式設計技能）。很多時候，我發現僅僅學習計算機專業的學生，比那些（除了計算機之外）擁有其它背景的學生，在思維上有更多的侷限性。因為後者有著更嚴謹的思維，也不那麼容易想當然。

有一次我組織了一次會議，其中一個議題是：理想的應聘者有哪些特徵：
◇把學習當成生活方式。比如：你應該知道不止一種語言，沒有什麼比學習一門新語言更能讓你開闊眼界了。
◇知道如何獲取知識
◇Study prior art
◇善用工具
◇學會把事情簡化
◇理解業務
◇為自己的錯誤負責。“我就是這樣的”是不能接受的託詞。能找到自己的失誤。
◇成為一個領導者，善於溝通和激勵。
◇搞清楚你在為誰服務
◇沒有絕對正確的答案（更好的方法總是存在的）。展示並討論你的程式碼，不要帶著感情因素——你的程式碼並不等於你本人。
◇明白完美是漸進的

適當嘗試一些冒險——尤其是能令人感到害怕的冒險。當你嘗試之後，將體會到出乎意料的興奮。（在冒險的過程中）最好不要刻意去計劃某個特定的結果。當你過於注重結果，你往往會錯過那些真正有價值的問題。我的冒險往往是這樣開始的——“我們先做些試驗，看看它會把我們帶到什麼地方”。

或許某些人會對我的回答感到失望，並回復我說：“是的，這很有趣也很有用。但我到底應該學什麼？C++還是Java？” 我再重複一次：並不是所有的問題都有一個唯一的簡單的答案。問題的關鍵不在於選擇某個程式語言，然後掌握之。問題的關鍵在於：持續學習，並且很多時候，有不止一個選擇。 相信我所說的，你的生活會更精彩！

Summary
I regularly receive requests for career advice, and I've tried to capture the answers in this blog, and in a follow-on. For those of you who asked but never got an answer, I apologize. Your questions stimulated me to work on this, and it's taken awhile.

The question that people ask is usually the wrong one: "should I learn C++ or Java?" In this essay, I shall try to lay out my view of the true issues involved in choosing a career in computing.

Note that I am not talking here to the people who already know it is their calling. You're going to do it regardless of what anyone says, because it's in your blood and you can't get away from it. You know the answer already: C++ AND Java AND shell scripting AND Python AND a host of other languages and technologies that you'll learn as a matter of course. You already know several of these languages, even if you're only 14.

The person who asks me this question may be coming from another career. Or perhaps they are coming from a field like web development and they've figured out that HTML is only kind of like programming, and they'd like to try building something more substantial. But I especially hope that, if you are asking this question, you've realized that to be successful in computing, you need to teach yourself how to learn, and never stop learning.

The more I do this, the more it seems to me that software is more akin to writing than anything else. And we haven't figured out what makes a good writer, we only know when we like what someone writes. This is not some kind of engineering where all we have to do is put something in one end and turn the crank. It is tempting to think of software as deterministic -- that's what we want it to be, and that's the reason that we keep coming up with tools to help us produce the behavior we desire. But my experience keeps indicating the opposite, that it is more about people than processes, and the fact that it runs on a deterministic machine becomes less and less of an influence, just like the Heisenberg principle doesn't affect things on a human scale.

My father built custom homes, and in my youth I would occasionally work for him, mostly doing grunt labor and sometimes hanging sheet rock. He and his lead carpenter would tell me that they gave me these jobs for my own good -- so that I wouldn't go into the business. It worked.

So I can also use the analogy that building software is like building a house. We don't refer to everyone who works on a house as if they were exactly the same. There are concrete masons, roofers, plumbers, electricians, sheet rockers, plasterers, tile setters, laborers, rough carpenters, finish carpenters, and of course, general contractors. Each of these requires a different set of skills, which requires a different amount of time and effort to acquire. House-building is also subject to boom and bust cycles, like programming. If you want to get in quick, you might take a job as a laborer or a sheet rocker, where you can start getting paid without much of a learning curve. As long as demmand is strong, you have steady work, and your pay might even go up if there aren't enough people to do the work. But as soon as there's a downturn, carpenters and even the general contractor can hang the sheet rock themselves.

When the Internet was first booming, all you had to do was spend some time learning HTML and you could get a job and earn some pretty good money. When things turned down, however, it rapidly becomes clear that there is a hierarchy of desirable skills, and the HTML programmers (like the laborers and sheet rockers) go first, while the highly-skilled code smiths and carpenters are retained.

What I'm trying to say here is that you don't want to go into this business unless you are ready to commit to lifelong learning. Sometimes it seems like programming is a well-paying, reliable job -- but the only way you can make sure of this is if you are always making yourself more valuable.

Of course you can find exceptions. There are always those people who learn one language and are just competent enough and perhaps savvy enough to stay employed without doing much to expand their abilities. But they are surviving by luck, and they are ultimately vulnerable. To make yourself less vulnerable, you need to continuously improve your abilities, by reading, going to user groups, conferences, and seminars. The more depth you have in this field, the more valuable you will be, which means you have more stable job prospects and can command higher salaries.

Another approach is to look at the field in general, and find a place where you already have talents. For example, my brother is interested in software, and dabbles with it, but his business is in installing computers, fixing them and upgrading them. He's always been meticulous, so when he installs or fixes your computer you know that it will be in excellent shape when he's done; not just the software, but all the way down to the cables, which will be bundled neat and out of the way. He's always had more work than he could do, and he never noticed the dot-com bust. And needless to say, his work cannot be offshored.

I stayed in college a long time, and managed to get by in various ways. I even began a Ph.D. program at UCLA, which was mercifully cut short -- I say mercifully because I no longer loved being in college, and the reason I stayed in college for so long was because I enjoyed it so much. But what I enjoyed was typically the off-track stuff. Art and dance classes, working on the college newspaper, and even the handful of computer programming classes that I took (which were off-track because I was a physics undergrad and a computer engineering graduate student). Although I was far from exceptional academically (a delightful irony is that many colleges that would not have accepted me as a student now use my books in their courses!), I really enjoyed the life of the college student, and had I finished a Ph.D. I probably would have taken the easy path and ended up a professor.

But as it turns out, some of the greatest value that I got from college was from those same off-track courses, the ones that expanded my mind beyond "stuff we already know." I think this is especially true in computing because you are always programming to support some other goal, and the more you know about that goal the better you'll perform (I've encountered some European graduate programs that require the study of computing in combination with some other specialty, and you build your thesis by solving a domain-specific problem in that other specialty).

I also think that knowing more than just programming vastly improves your problem-solving skills (just as knowing more than one programming language vastly improves your programming skills). On multiple occasions I have encountered people, trained only in computer science, who seem to have more limits in their thinking than those who come from some other background, like math or physics, which requires more rigorous thinking and is less prone to "it works for me" solutions.

In one session a conference that I organized, one of the topics was to come up with a list of features for the ideal job candidate:

• Learning as a lifestyle. For example, you should know more than one language; nothing opens your eyes more to the strengths and limitations of a language than learning another one.
• Know where and how to get new knowledge.
• Study prior art.
• We are tool users.
• Learn to do the simplest thing.
• Understand the business (Read magazines. Start with Fast Company, which has very short and interesting articles. Then you can see if you want to read others)
• You are personally responsible for errors. "It works for me" is not an acceptable strategy. Find your own bugs.
• Become a leader: someone who communicates and inspires.
• Who are you serving?
• There is no right answer ... and always a better way. Show and discuss your code, without emotional attachment. You are not your code.
• It's an asymptotic journey towards perfection.

Take whatever risks you can -- the best risks are the scary ones, but in trying you will feel more alive than you can imagine. It's best if you don't plan for a particular outcome, because you will often miss the true possibilities if you're too attached to a result. My best adventures have been ones that have started with "lets do a little experiment and see where it takes us.

Some people will be disappointed by this answer, and reply "yes, that's all very interesting and useful. But really, what should I learn? C++ or Java?" I'll fend these off by repeating here: I know it seems like all the ones and zeroes should make everything deterministic, so that such questions should have a simple answer, but they don't. It's not about making one choice and being done with it. It's about continuous learning and sometimes, bold choices. Trust me, your life will be more exciting this way.

Talk Back!

Have an opinion? Readers have already posted 24 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.