《Coders at Work》读后感精选

《Coders at Work》是一本由Peter Seibel著作，Apress出版的Paperback图书，本书定价：USD 29.99，页数：632，特精心收集的读后感，希望对大家能有帮助。

《Coders at Work》读后感(一)：看看前辈是怎样编程的

读这本书的目的，是想找个答案: 如果一辈子以编程为事业，究竟是一种怎样的体验？顶级软件工程师的工作，生活和思维到底是怎样的？

作者采访的都是业内顶尖的大师，不过大部分人都在四五十岁以上了。难得的是他们每个人依然把编程当作一项好玩的事情，这才是对自己职业真正的热爱吧。

程序员到底是科学家，工程师，艺术家还是工匠呢？不同的受访者给了不同的答案，但大部分答案还是落在工匠和工程师之间。

计算机编程总共出现的历史就是这短短的几十年，虽然硬件的速度提高了千倍万倍，编程的技术和技巧其实并没有数量级的进步，这就是为什么这些老行家们说的话，今天看来还是那么有道理吧。更可悲的是，随着现在软件库的层层封装，大多数程序员已经沦为搬运工，做一些组装，拼装的应用级开发工作，不像上世纪六七十年代，编程包含了操作系统，编译器，汇编，自己写编程语言…，一直到芯片、铁壳。

或许编程真的没有过去那么有趣了，但是，所有的东西都在那里，要想深入底层，没人拦住你去探索。coding真是一个无尽的wonderland!

《Coders at Work》读后感(二)：大师都有扎实的基本功

我要站出来批评一下那个名为“去他的算法内功基础，对于程序员，实用主义才是王道” 的评论（我的评论对事不对人）。

首先我要说，这个观点绝对是错误的。表面上这句话好像抓住了“实用主义”的大旗，但却借此抨击算法等基本功的重要性，太误人子弟。就拿Google Fellow Jeff Dean来说，他绝对算得上是实用主义的大师了吧？可是如果你去看看他关于Google整个系统架构演变过程的讲座，你就会发现把Google的那些诸如MapReduce、GFS之类的看家法宝化繁为简之后都可以还原成最基本的算法、数据结构之类的问题！Google整个架构的发展也是根据需求的变化而产生的，MapReduce之类的不就是在遇到需要解决大规模并行编程这个问题时产生的实用的解决方案吗？没有扎实的基本功它能被设计出来么？哪一个大师没有扎实的基本功？哪怕是你说的Jamie Zawinski，如果他算法基本功没有十分纯熟他能被称为大师么？别以为他标榜实用他就没有扎实的基本功了。

我的观点是，想真正成为杰出的程序员，没有扎实的基本功是绝对不可能的，因为你会发现当你需要解决一个没有现成答案的问题时，你的基本功就是最可信赖的武器。所以，如果你不想只做一个码农，好好学好算法打好基本功是绝对值得的！当然，如果你只像做一个只能靠google搜索答案过活的程序员，就当我这话没说。

这本书最大的益处就是帮助广大程序员了解大师是怎么成长过来的，学习他们的宝贵经验。我觉得对于程序员来说，大师的成长经历都隐含了一个基本规律：他们都是编程至少十几二十年以上才最终成为大师的，“十年学会编程”并不是什么天方夜谭，而是确确实实的事情！同理，任何人如果想要成为大师（或者至少是杰出的程序员），那么他首先要做的就是打好基本功：08年图灵奖得主Barbara Liskov博士在回答“什么素质是研究者必不可少的素质是”她毫不犹豫的说是扎实的基本功最重要。对于学生来说，基本技能和解决问题的能力很重要，非常重要！这个道理对程序员来说是一样的！

成功的方式有很多种，事实上很多商业上的成功案例中技术仅仅是其中最不重要的一环，在中国这个讲究关系的环境中更是如此。我认同市场>管理>技术。我建议大家根据自己的特点来选择合适的职业发展路线。

随着中国IT行业的发展，科技创新将会变得越来越重要，而超级程序员也会越来越成为香饽饽，如果各位同学确实热爱编程，愿意一辈子编程，我希望你坚持下去，因为只要你成为超级程序员肯定会有赏识你的公司。以IBM中国为例，技术路线的最高级别IBM Fellow，年薪是以百万人民币计算的（当然很多人抱怨Band10以下的收入）；很多成功的技术型小公司也都靠被大公司收购的方式实现了自我价值；而一个反例就是不依靠科技创新的公司（例如团购网站），它们确实是不怎么需要高端技术人才，这样的公司不是靠技术取胜。

感兴趣的朋友可以看看我这篇文章：Erlang User Conference 2010见闻（兼谈程序员职业生涯） http://www.parallellabs.com/？p=867

《Coders at Work》读后感(三)：摘要和感想

Jamie Zawinski

At the end of the day, ship the fucking thing! It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point -- you're not here to write code; you're here to ship products.

If you spend the time to build the perfect framework that's going to do what you want and that's going to carry you from release 1.0 through release 5.0 and everything's going to be great; well guess what: release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you're out of the game. Your never shipped your 1.0 because someone else ate your lunch.

Your competitor's six-month 1.0 has crap code and they're going to have to rewrite it in two years but, guess what: they can rewrite it because you don't have a job anymore.

...if we'd had unit tests or smaller modules or whatever. That all sounds great in principle. Given a leisurely development pace, that's certaintly the way to go. But when you're looking at, "We've got to go from zero to done in six weeks", well, I can't do that unless I cut something out...I hope I don't sound like I'm saying "Testing is for chumps", it's not. It's a matter of priorities. Are you trying to write good software or are you trying to be done by next week？ You can't do both.

...Design Patterns -- which I just thought was crap...Then in meetings they'd be tossing around all this terminology they got out of that book. Like, the inverse, reverse, double-back-flip pattern -- whatever. Oh, you mean a loop？ OK.

Brendan Eich

But we need to be practical about standards. We can't just say all you need are lambdas -- Alonzo Church proved it, so we're not going to add any more to the language.

Joshua Bloch

But what you do is you force people to subset it (c++)

There are just a bunch of features (of c++) that you're not going to use because the resulting code is too high.

There's a brilliant quote by Tony Hoare in his Turing Award speech about how there are two ways to design a system: "One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies."

What we're doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills -- all of these things that we don't necessarily think of as engineering but without which I don't think you'll ever be a really good enigneer. So I think it's just something that we have to remind ourselves of. But I think it's one of the most fun jobs on the planet. I think we're really lucky to have grown up at the time that we did when these skills led to these jobs. I don't know what we would have been doing a few generations back.

Joe Armstrong

I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented language is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

What I've learned is, programming when you're tired, you write crap and you throw it all away the next day.

I have noticed over the years, the really good code I would write was when I'm in complete flow -- just totally unaware of time: not even really thinking about the program, just sitting there in a relaxed state just typing this stuff and watching it come out on the screen as I type it in. That's code's going to be OK.

It's a movtivating force to implement something; I really recommand it. If you want to understand C, write a C compiler. If you want to understand Lisp, write a Lisp compiler or a Lisp interpreter.

Things you don't do are difficult and things you've done are easy.

Then there's -- I don't know if I read it somewhere or if I invented myself -- Joe's Law of Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program.

I think the code is the answer to a problem. If you don't have the spec or you don't have any documentation, you have to guess what the problem is from the answer. You might guess wrong.

Do good stuff. If you don't do good stuff, in good areas, it doesn't matter what you do.

Peter Norvig

I think one of the most important thing is being able to keep everything in your head at once. If you can do that you have a much better chance of being successful. That maks a small program easier.

One of the most important things for having a successful project is having people that have enough experience that they build the right thing. And barring that, if it's something that you haven't built before, that you don't know how to do, then the next best thing you can do is to be flexible enough that if you build the wrong thing you can adjust.

Dan Ingalls

Although I didn't go very far, my conclusion was that it isn't that young people learn that much faster; it's just they have more time. When I would put time in, I made progress.

L Peter Deutsch

The old idea of program correctness was that there were these assertions that were your expressions of what you intend the code to do in a way that was mechanically checkable against the code itself. There were lots of problems with that approach. I now think that the path to software that's more likely to do what we intend it to do lies not through assertions, or inductive assertions, but lies through better, more powerful, deeper declarative notations.

Language systems stands on a tripod. There's the language, there's the libraries, and there are the tools. And how successful a language is depends on a complex interaction between those three things.

Ken Thompson

Modern programming scares me in many respects, where they will just build layer after layer after layer that does nothing except translate. It confuses me to read a program which you must read top-down. It says "do something." And you go find "something." And you read it and it says "do something else" and you go find something and it says, "do something else" and it goes back to the top maybe. And nothing gets done. It's just relegating the problem to a deeper and deeper level.

You should do well but not really good. And the reason is that in the time it takes you to go from well to really good, Moore's law has already surpassed you. You can pick up 10 percent but while you're picking up that 10 percent, computers have gotten twice as fast and maybe with some other stuff that matters more for optimization, like caches. I think it's largely a waste of time to do really well. It's really hard; you generate as many bugs as you fix. You should stop, not take that extra 100 percent of time to do 10 percent of the work.

Fran Allen

One could never really write specs that were going to be adequate and useful at a detail level over the years of the life circle. That was a problem. And now we have another process, of course--just do it and throw it away, kind of.

Donald Knuth

The scientist gets older and says, "Oh, yes, some of the things that I've been doing have a really great payoff and other things, I'm not using anymore. I'm not going to have my students waste time on the stuff that doesn't make giant steps. I'm not going to talk about low-level stuff at all. These theoretical concepts are really so powerful -- That's the whole story. Forget about how I got to this point." I think that's a fundamental error made by scientists in every field. They don't realize that when you're learning something you've got to see something at all levels. You've got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.

I think programming is a lot like religion; people have their beliefs. Some people like to force their beliefs on others.

The first rule of writing is to understand your audience -- the better you know your reader the better you can write, of course. The second rule, for technical writing, is say everything twice in complementary ways so that the person who's reading it has a chance to put the ideas into his or her brain in ways that reinforce each other.

The problem is that coding isn't fun if all you can do is call things out of a library, if you can't write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who'd want to go into that as a career？

On one hand you have this impossibility of ever having something proved. Somebody will say they have a program that's verified and it's only verified because it met its specifications according to some verifier. But the verifier might have a bug in it. The specifications might have bugs in them. So you never know that the program is correct. You have more reason to believe it, but you never get to the end of the loop. It's theoretically impossible.

几点感想

貌似也没几个人从头到尾读过TAOCP

如何判断一个人是不是优秀的程序员，基本都是靠感觉。

程序证明这种事情工业届真的会去执行吗？preconditions, postconditions, 一个应用程序那么多函数，放在哪一层合适？

对Literate programming也有同样的疑问。

Knuth不愧“述而不作，信而好古”的名士风范