阿里数据库专家:写给我们这些浮躁的程序员

Posted on

阿里数据库专家:写给我们这些浮躁的程序员

本文作者:叶正盛,阿里巴巴数据库技术专家,专注于数据库应用性能量化。

再次写给我们这些刚入行浮躁的程序员,如何成长,以下是列出了一些成长的心得,我们不必每条都去实践,但是优秀的程序员成长过程中总会实践里面的几条。

多做项目,多思考

不要害怕做事,刚毕业的同学最缺的就是工作经验,乱七八糟的项目能让你很快就了解了一个公司的业务与使用的技术,并且可以多接触同事与客户。

当你毕业后刚进一家公司时,如果主管没有把你安排到项目组工作,那真的很杯具,因为他认为你还不能胜任工作或者你的加入会让项目组更糟。

还有人说,我刚进公司,公司就把我当成了苦工,工资又低,项目组加入好几个,也做了很多事情,每天都要加班。我估计有很多人感觉是这种状态,为什么会是这样,因为全国人民(不只是程序员)里有90%可能都和你一样的感觉,这说明你现在状况是很普遍的,也说明你现在的能力并没有很多出众的地方。也许是逆境才能让人成长,如果有一天你让你的团队从这些苦力工作中解脱出来或者能给你的团队前进的动力,那你就升华了,你就比他们出众。你没有能力去改变现状,所以只能接受,而不要认为是自己生不逢时,或者说公司环境太差。创业也一样,不要认为公司没发展的主要原因是环境太差,那你不要去当老板算了,投资环境都非常好还能轮到你吗。

还有很多同学感觉自己付出了很多,回报太少,这个问题很难平衡,首先一点,公司在聘你进来后不会因为你没有成绩就先给你回报,公司也不可能会在你有了成绩后就立即给你回报,但是长时间付出没有回报,那这个公司就不值得你付出。我不赞成频繁换公司,这么做至少可以说明你是一个只求回报不求付出的人。

至于薪资的问题,这个很难去评估,因为每个企业的收益相差太远。但是刚毕业的同学工作需要关注薪资+成长环境,当薪资可以满足普通生活需求后,成长环境更为重要,就好比,给你一月5000元,或者6000元,真的不那么重要,因为这些收入在你以后的人生中基本没有影响。当然,如果你现在在大城市几年里每个月只拿着1000元,那还是需要选择一下收入更好的公司,因为这么低的收入会严重影响你的工作学习计划,也说明你的公司不重视员工,没有能力给员工好生活的公司,将来的发展也是有限的。

特别说明一点,互联网公司与传统信息化企业不一样,互联网一直是风险比较高的行业,也许你选择了一个看好的企业,也佩服老板的眼光,可能你现在需要的是与公司同甘共苦。不要指望在刚创业的团队里拿到非常好的待遇,因为你现在就是在投资,也许几年后公司成功了,你就是功臣,不怎么出色的你也可以当上总监或副总裁。

Bruce Eckel:编程生涯

Posted on

Bruce Eckel:编程生涯

EN文:

Computing Thoughts A Career in Computing by Bruce Eckel June 2, 2009 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.

Further Reading

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.

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.


中文:

Bruce Eckel:编程生涯

作者 Bruce Eckel 是编程界的大牛,著有大名鼎鼎的《Thinking in C++》和《Thinking in Java》。 本文是他对程序员(尤其是新手)的忠告。

================华丽的分割线================

大家总是问一个错误的问题:“我应该学习C++还是Java?”在本文中,我将告诉大伙儿:对于选择编程生涯真正需要关注的是哪些问题。

请 注意,这篇文章的目标读者并不是那些已经做出自己选择的人。(对于这些人而言)你会继续自己的编程生涯,而不管别人会怎么说。因为它已经渗透到你的血液 中,你已经无法摆脱。你已经知道答案:C++、Java、Shell脚本、Python、还有其它一大堆的语言和技术,你都理所当然地会去学习。甚至有可 能你才仅仅14岁,就已经知道好几种不同的语言。

问我这样的问题的人可能来自其他行业,或者来自诸如Web开发之类的领域。他们知道HTML是一种类编程语言,而且想尝试构建某些更大型的应用。但我特别希望,当你在问这个问题时,你已经意识到了想要在计算机领域取得成功,你需要掌握自学能力,而且永不停息。

在这个领域做得越多,我越觉得软件开发比任何行业都更接近于写作。 我们从来不知道是什么造就了优秀的作者,我们只知道什么时候我们会喜欢某个人的文字。编程不是一种工程,仅需要把东西从入口倒进去,然后再转动手柄。把软 件开发看成确定性的,是一个诱人的想法。因为这个想法,人们总想搞出一些工具来帮我们开发出想要的软件。但是我的经验告诉我,事实并非如此——人的重要性 远高于流程。而软件是否运行在一部精确的机器上已经越来越不重要了——这犹如测不准原理对人类的影响。

我的父亲是造房子的,小时候我偶尔会帮忙打下手,放放砖块之类。他和他的木工告诉我,他们是为我好才让我干这些活——这样我就不至于走入这个行业。事实确实是这样。

我 们不妨把软件开发比作盖房子。造房子的人当然不可能完全一样。这些人里面有:混凝土工、屋顶工、管道工、电工、砖瓦工、水泥工、瓦片工、搬运工、粗木工、 细木工。当然,还有工头。每个工种都需要相应的技能,这些技能都需要花时间和精力去掌握。跟软件开发一样,造房子也是一个“建立/推翻”的过程。如果你想 很快地获得回报,你可能从搬运工和砖瓦工开始做,这样的话,你无需太多的学习曲线就可以获得回报。当需求很多时,你的工作会很稳固,甚至收入也可能提升 ——如果没有足够的人手的话。但是,一旦行情不妙,木匠甚至工头就可能把砖瓦工一脚踢开。

当互联网刚刚兴起时,仅仅是花一点时间学习HTML,你就可以得到一份薪水丰厚的工作。但是当形势惨淡时,对于技能的要求更高了——HTML程序员(就像搬运工和砖瓦工一样)第一个被抛弃了,而拥有更高技能的程序员则留了下来。

我想说的是: 除非你准备活到老学到老,不然的话,不要进入这个行业!编程看起来似乎是一个高收入而又稳定的工作。但要做到这一点,唯一的途径是:始终让自己更有价值。

当然,你总能找到例外。总有那么一些人,仅仅学了一门编程语言,就可以胜任留在一个岗位上,而不需要增长他的技能。但他们只是幸免于难而已,他们最终无疑是很脆弱的。为了不让自己变得脆弱,你需要持续的提高自己,通过阅读、加入用户组、参加研讨会…… 你学得越深入,你就越有价值,也就意味着你有更好的职业前景,可以配得上更高的薪水。

另 一个方法是:先大致地了解这个领域,找到最适合你的地方。打个比方:我的兄弟对软件很感兴趣,也进入了这个行业,但他的工作是安装、维修、升级电脑。他总 是一丝不苟,所以当他把电脑搞好,一定会很完美——不只只是软件,连电线都会被仔细地捆好。他总是生意兴隆,远远超出他的精力所能及。他甚至都不用担心 .com 泡沫的崩溃。显然他的饭碗不容易被抢走。

我在高校里待了很久,甚至还在UCLA(加州大学洛杉矶分校)开始进修博士学位,后来 又幸运地终止了。我说“幸运”是因为我不再喜欢呆在学校,而我之前在高校待了那么久,只是因为我很享受它。但我所享受的,基本上是不务正业的东西——艺术 和舞蹈课,在校报工作,还有一小撮计算机课程(之所以说计算机课程“不务正业”,是因为我本科是物理专业,研究生才是计算机专业)。虽然我在学术上远谈不 上卓越(有意思的是很多当时也许不会接受我这个学生的学校现在却用我的书做教材)。我真的很享受作为学生的日子,当我完成博士课程,也许会以一个教授的身 份终老一生。

但就如现在看到的,我在学校里最大的收获恰恰来自我那些“不务正业”的课程,它们拓展了我的思维,使之超越了“我们已经知道 的东西”。在计算机领域中,你总是为某种目标而编程。你对目标了解得越多,你就做得越好。我遇到过一些欧洲的研究生,他们需要结合其它专业领域来搞编程, 他们的论文需要解决这个专业领域的特定的问题。

了解编程之外的领域,将会极大得提高你解决问题的能力 (就如同多学几种编程语言将极大地提高你的编程技能)。很多时候,我发现仅仅学习计算机专业的学生,比那些(除了计算机之外)拥有其它背景的学生,在思维上有更多的局限性。因为后者有着更严谨的思维,也不那么容易想当然。

有一次我组织了一次会议,其中一个议题是:理想的应聘者有哪些特征: ◇把学习当成生活方式。比如:你应该知道不止一种语言,没有什么比学习一门新语言更能让你开阔眼界了。 ◇知道如何获取知识 ◇Study prior art ◇善用工具 ◇学会把事情简化 ◇理解业务 ◇为自己的错误负责。“我就是这样的”是不能接受的托词。能找到自己的失误。 ◇成为一个领导者,善于沟通和激励。 ◇搞清楚你在为谁服务 ◇没有绝对正确的答案(更好的方法总是存在的)。展示并讨论你的代码,不要带着感情因素——你的代码并不等于你本人。 ◇明白完美是渐进的

要 尝试一些冒险的事情——尤其是那些令人害怕的冒险。当你尝试之后,将体会到出乎意料的兴奋。(在冒险的过程中)最好不要刻意去计划某个特定的结果。当你过 于注重结果,你往往会错过那些真正有价值的问题。我的冒险往往是这样开始的——“我们先做些试验,看看它会把我们带到什么地方”。

或许某 些人会对我的回答感到失望,并回复我说:“是的,这很有趣也很有用。但我到底应该学什么?C++还是Java?” 我再重复一次:并不是所有的问题都有一个唯一的简单的答案。问题的关键不在于选择某个编程语言,然后掌握之。问题的关键在于:持续学习,并且很多时候,有 不止一个选择。相信我所说的,你的生活会更精彩!

洋文原始出处: http://www.artima.com/weblogs/viewpost.jsp?thread=259358 来源: [http://www.rootsir.com/transshipment/2012/709.html](http://www.rootsir.com/transshipment/2012/709.html)

知其所以然(三):为什么算法这么难?

Posted on

知其所以然(三):为什么算法这么难?

By 刘未鹏 – July 10, 2011

不知不觉《知其所以然》系列竟然也写到第三篇了,虽然前面两篇也说了不少,但是总觉得还有东西没有说“透”,或者说没有说“好”。所以这篇试图从不同的角度用更好的例子来继续深入阐述。(感谢silwile对本文的review和意见)

广大码农同学们大多都有个共识,认为算法是个硬骨头,很难啃,悲剧的是啃完了还未必有用——除了面试的时候。实际工程中一般都是用现成的模块,一般只需了解算法的目的和时空复杂度即可。

不过话说回来,面试的时候面算法,包括面项目中几乎不大可能用到的算法,其实并不能说是毫无道理的。算法往往是对学习和理解能力的一块试金石,难的都能掌握,往往容易的事情不在话下。志于高者得于中。反之则不成立。另一方面,虽说教科书算法大多数都是那些即便用到也是直接拿模块用的,但不幸的是,我们这群搬砖头的有时候还非得做些发明家的事情:要么是得把算法当白盒加以改进以满足手头的特定需求;要么干脆就是要发明轮子。所以,虽说面试的算法本身未必用得到,但熟悉各种算法的人通常更可能熟悉算法的思想,从而更可能具备这里说的两种能力。

那么,为什么说算法很难呢?这个问题只有两种可能的原因:

  1. 算法本身就很难。也就是说,算法这个东西对于人类的大脑来说本身就是个困难的事儿。
  2. 讲得太烂。

下面会说明,算法之所以被绝大多数人认为很难,以上两个原因兼具。

数据的游戏:冰与火

Posted on

数据的游戏:冰与火

2013年7月31日 陈皓

我对数据挖掘和机器学习是新手,从去年7月份在Amazon才开始接触,而且还是因为工作需要被动接触的,以前都没有接触过,做的是需求预测机器学习相关的。后来,到了淘宝后,自己凭兴趣主动地做了几个月的和用户地址相关数据挖掘上的工作,有一些浅薄的心得。下面这篇文章主要是我做为一个新人仅从事数据方面技术不到10个月的一些心得,也许对你有用,也许很傻,不管怎么样,欢迎指教和讨论。

另外,注明一下,这篇文章的标题模仿了一个美剧《权力的游戏:冰与火之歌》。在数据的世界里,我们看到了很多很牛,很强大也很有趣的案例。但是,数据就像一个王座一样,像征着一种权力和征服,但登上去的路途一样令人胆颤

数据挖掘中的三种角色

在Amazon里从事机器学习的工作时,我注意到了Amazon玩数据的三种角色。

  • Data Analyzer:数据分析员。这类人的人主要是分析数据的,从数据中找到一些规则,并且为了数据模型的找不同场景的Training Data。另外,这些人也是把一些脏数据洗干净的的人。

  • Research Scientist:研究科学家。这种角色主要是根据不同的需求来建立数据模型的。他们把自己戏称为不近人间烟火的奇异性物种,就像《生活大爆炸》里的 那个Sheldon一样。这些人基本上玩的是数据上的科学

  • Software Developer :软件开发工程师。主要是把 Scientist 建立的数据模型给实现出来,交给Data Analyzer去玩。这些人通常更懂的各种机器学习的算法。

我相信其它公司的做数据挖掘或是机器学习的也就这三种工作,或者说这三种人,对于我来说,

  • 最有技术含量的是 Scientist,因为数据建模和抽取最有意义的向量,以及选取不同的方法都是这类人来决定的。这类人,我觉得在国内是找不到的。

  • 最苦逼,也最累,但也最重要的是Data Analyzer,他们的活也是这三个角色中最最最重要的(注意:我用了三个最)。因为,无论你的模型你的算法再怎么牛,在一堆烂数据上也只能干出一堆垃圾的活来。正所谓:Garbage In, Garbage Out !但是这个活是最脏最累的活,也是让人最容易退缩的活。

  • 最没技术含量的是Software Developer。现在国内很多玩数据的都以为算法最重要,并且,很多技术人员都在研究机器学习的算法。错了,最重要的是上面两个人,一个是苦逼地洗数据的Data Analyzer,另一个是真正懂得数据建模的Scientist!而像什么K-MeansK Nearest Neighbor,或是别的什么贝叶斯、回归、决策树、随机森林等这些玩法,都很成熟了,而且又不是人工智能,说白了,这些算法在机器学习和数据挖掘中,就像Quick Sort之类的算法在软件设计中基本没什么技术含量。

{技术}{多线程}实施并行编程的五大障碍

Posted on

实施并行编程的五大障碍

近期看见一篇来自Intel的很有意思的分析文章,作者提到在他向45名与会的各公司程序员/开发经理/战略师提问“什么是实施并行编程的最大障 碍”时,下面五个因素被提及的次数最多:遗留代码(legacy code)、教育(education)、工具(tools)、对众核趋势的恐惧 (fear of many cores)以及可维护性(maintainability)。文章虽然是一篇Intel Parallel Studio的软文,但是其中提及的这五大障碍却非常值得讨论,下面是我对这五大障碍的一些粗浅看法,希望能起到一个抛砖引玉的作用,欢迎大家给出你们 的看法。

( 注:好像Google Group让我原文的一些超链接都失效了,如果想有更好的阅读体验,请看 http://www.parallellabs.com/2010/03/22/five-obstacles-that-slow-down-parallelism/ )