A Career in Computing
by Bruce Eckel
June 2, 2009
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.
Here's an earlier piece I wrote on how I got started in programming.
I found all these to be interesting and stimulating takes on the same subject:
In a future article (I'll post the link here when it's done), I will talk about the importance of understanding management and business issues, whether or not you ever plan to be a manager, and in that article I'll include a list of books that (even though they're about management) you should read to prepare yourself for your career.
Have an opinion? Readers have already posted 24 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.
作者 Bruce Eckel 是编程界的大牛，著有大名鼎鼎的《Thinking in C++》和《Thinking in Java》。
请 注意，这篇文章的目标读者并不是那些已经做出自己选择的人。（对于这些人而言）你会继续自己的编程生涯，而不管别人会怎么说。因为它已经渗透到你的血液 中，你已经无法摆脱。你已经知道答案：C++、Java、Shell脚本、Python、还有其它一大堆的语言和技术，你都理所当然地会去学习。甚至有可 能你才仅仅14岁，就已经知道好几种不同的语言。
在这个领域做得越多，我越觉得软件开发比任何行业都更接近于写作。 我们从来不知道是什么造就了优秀的作者，我们只知道什么时候我们会喜欢某个人的文字。编程不是一种工程，仅需要把东西从入口倒进去，然后再转动手柄。把软 件开发看成确定性的，是一个诱人的想法。因为这个想法，人们总想搞出一些工具来帮我们开发出想要的软件。但是我的经验告诉我，事实并非如此——人的重要性 远高于流程。而软件是否运行在一部精确的机器上已经越来越不重要了——这犹如测不准原理对人类的影响。
我 们不妨把软件开发比作盖房子。造房子的人当然不可能完全一样。这些人里面有：混凝土工、屋顶工、管道工、电工、砖瓦工、水泥工、瓦片工、搬运工、粗木工、 细木工。当然，还有工头。每个工种都需要相应的技能，这些技能都需要花时间和精力去掌握。跟软件开发一样，造房子也是一个“建立/推翻”的过程。如果你想 很快地获得回报，你可能从搬运工和砖瓦工开始做，这样的话，你无需太多的学习曲线就可以获得回报。当需求很多时，你的工作会很稳固，甚至收入也可能提升 ——如果没有足够的人手的话。但是，一旦行情不妙，木匠甚至工头就可能把砖瓦工一脚踢开。
另 一个方法是：先大致地了解这个领域，找到最适合你的地方。打个比方：我的兄弟对软件很感兴趣，也进入了这个行业，但他的工作是安装、维修、升级电脑。他总 是一丝不苟，所以当他把电脑搞好，一定会很完美——不只只是软件，连电线都会被仔细地捆好。他总是生意兴隆，远远超出他的精力所能及。他甚至都不用担心 .com 泡沫的崩溃。显然他的饭碗不容易被抢走。
我在高校里待了很久，甚至还在UCLA（加州大学洛杉矶分校）开始进修博士学位，后来 又幸运地终止了。我说“幸运”是因为我不再喜欢呆在学校，而我之前在高校待了那么久，只是因为我很享受它。但我所享受的，基本上是不务正业的东西——艺术 和舞蹈课，在校报工作，还有一小撮计算机课程（之所以说计算机课程“不务正业”，是因为我本科是物理专业，研究生才是计算机专业）。虽然我在学术上远谈不 上卓越（有意思的是很多当时也许不会接受我这个学生的学校现在却用我的书做教材）。我真的很享受作为学生的日子，当我完成博士课程，也许会以一个教授的身 份终老一生。
但就如现在看到的，我在学校里最大的收获恰恰来自我那些“不务正业”的课程，它们拓展了我的思维，使之超越了“我们已经知道 的东西”。在计算机领域中，你总是为某种目标而编程。你对目标了解得越多，你就做得越好。我遇到过一些欧洲的研究生，他们需要结合其它专业领域来搞编程， 他们的论文需要解决这个专业领域的特定的问题。
◇Study prior art
要 尝试一些冒险的事情——尤其是那些令人害怕的冒险。当你尝试之后，将体会到出乎意料的兴奋。（在冒险的过程中）最好不要刻意去计划某个特定的结果。当你过 于注重结果，你往往会错过那些真正有价值的问题。我的冒险往往是这样开始的——“我们先做些试验，看看它会把我们带到什么地方”。
或许某 些人会对我的回答感到失望，并回复我说：“是的，这很有趣也很有用。但我到底应该学什么？C++还是Java？” 我再重复一次：并不是所有的问题都有一个唯一的简单的答案。问题的关键不在于选择某个编程语言，然后掌握之。问题的关键在于：持续学习，并且很多时候，有 不止一个选择。相信我所说的，你的生活会更精彩！