卓越软件工程师有何特质？

导读

论文试图回答“卓越软件工程师与普通工程师究竟有何不同”，采用问卷调查让工程师对一组预先定义的特质/行为进行评价（据评论，样本为微软员工）。它归纳出若干被认为重要的特质，但评论对其方法和普适性提出质疑。

HN 关注点：顶尖工程师到底具备哪些特质，但讨论焦点很快转向研究方法：只调查微软员工、条目过于通用、缺少对照组。

关键词　软件工程工程师特质问卷调查Microsoft

HN 评论精选

这几条评论里：质疑 1　补充 2　亲历 1

亲历伟大工程师对工具和技术有从底层到美学的全面掌控，并写出清晰优雅的代码。

在 50 年编程生涯中，我遇到过几位这样的工程师。一个特征是：对他们接触的一切都有深入理解和掌控。比如我和 Bill Schelter（GNU Common Lisp）共事时，1980 年还没有互联网，我们在研究尾递归问题。他用 emacs 时发现了一个 bug，就停下手头的事，用 ftp 取来 emacs 源码，找到 bug 根源，修好并发出补丁，然后重启 emacs 继续刚才的工作。那是一场大师级表演，像看 Victor Borge 演出。我还认识一个弹吉他的人，他听一遍演奏就能像我看书打字一样复现，能即兴转调、加 riff、改调弦，甚至弦断了也能改成“五弦”指法弹完；他还懂吉他特性、效果器等一切关于吉他的东西。我见过的伟大软件工程师似乎也完全掌握所有想法、工具和技术，理解工具“下到金属、上到美学”。各行各业都有这样的人，比如木工。他们还会写出漂亮的、精心雕琢的代码。我正在为一个历史博物馆录入 FORTRAN 打孔卡程序，从代码能看出作者写得干净、仔细、清晰，几乎能感受到他有多优秀。

daly查看英文原文

In 50 years of programming I've worked with a few. One characteristic is a deep understanding and command of all that they touch. For example, I worked with Bill Schelter (GNU Common Lisp). In 1980, prior to the Internet, we were working on a problem (tail recursion). He was using the emacs editor and he found a bug. Bill stopped what he was doing, fetched the sources for emacs (using ftp), found the source of the bug, fixed it, and sent off a patch. After that he restarted emacs and continued right where he left off. It was a virtuoso performance. It was like watching Victor Borga (https://www.youtube.com/watch?v=dKeqaDSjy98). I know a guy who plays guitar. He can listen to a performance and repeat it as easily as I can type what I read. He can transpose keys, add riffs, change tuning "on the fly", and even play thru with a broken string, adjusting chords to the new "5 string" form. He also knows guitar characteristics, pedal effects, etc., basically "all things guitar". Great software engineers I've known seem to have complete command of all of the ideas, tools, and techniques. They understand their tools "all the way down to the metal" and all the way "up to the esthetics". You can see great people in all crafts (like woodworking). They also write beautiful "crafted" code. I'm keyboarding a FORTRAN punched card deck (for an historical museum). You can see from the code that the author wrote clean, careful, and clear code. You can almost feel how good he was. Greatness isn't about "team player", "hard working", "good at time estimation", or anything "social". Greatness is a property of the person, a deep love of the craft, and a focus on "doing it right".

质疑质疑调查只面向微软员工、条目过于通用且无对照组，结论可能没有信息量。

我没法说读完了全文，但读到方法部分，必须说它看起来并不特别令人印象深刻。这项研究是一份严格发给微软员工的问卷，让他们对一组预先定义的标准进行排序/评价，比如“努力工作”“诚实”“团队合作”“创造安全港湾”等。显然，微软员工不会说“懒惰、撒谎、把人当垃圾的人能成为伟大软件工程师”。至少，一项研究应该有对照组来过滤掉这些无用问题。比如把措辞类似的问卷发给杂货店收银员，问他们是否认为“努力工作、诚实、正直、长期思考、团队合作”能让一个人成为伟大工程师。我的假设是，从出租车司机那里得到的答案会和微软员工差不多，因此这项调查及其参与者选择没多大价值。我不是专家，可能判断错了，但坦率说它看起来非常无用。

Kranar查看英文原文

Can't claim I read the entire thing, but I got down to methodology and must say it doesn't look particularly impressive. The study is a survey sent out strictly to Microsoft employees asking them how they rank a set of pre-defined criteria about what makes a great software engineer. That criteria includes things like "hard working", "honesty", "team player", "creates a safe haven" etc... Obviously no Microsoft employee is going to say something like "Lazy liars who treat people like crap make great software engineers." At the very least you'd expect a study to have a control group in order to filter out these useless questions. For example send a similarly worded survey to a group of grocery cashiers and ask them if they think attributes such as "Hard work, honesty, integrity, long term thinking, being a team player." make someone a great engineer. My hypothesis is you'd end up getting similar answers from taxi drivers as you would from Microsoft employees and consequently that there isn't much value derived from this survey or their selection of participants. Anyways, I'm by no means an expert and could be misjudging this research but frankly it looks to be beyond useless.

补充软件工程优劣难有共识，因为失败不像建筑倒塌那样可见；好工程师降低复杂性，差工程师放大复杂性。

有趣的是，每次问这个问题，答案都多种多样。如果问“什么造就了好外科医生”，或者像另一条评论说的“什么造就了伟大篮球运动员”，争论似乎会少一些。在我看来，这场争论与另一个问题有关：“为什么那么多软件项目失败，却看不到摩天大楼因自身重量倒塌？”如果建摩天大楼的规则只受想象力限制，那也许我们会看到更多大楼倒塌；而鉴于失败如此频繁，我们也会更多争论什么才是卓越的建楼能力。也许更好的问题是：“什么造就了差软件工程师？”这个问题似乎容易回答得多。差工程师花很长时间写出不可读、不可维护、有 bug 的代码，只部分解决没人需要的问题。讽刺的是，这种代码常因自身性质而不被注意：它要很久才存在；存在时又 bug 太多，失败看起来像 bug 问题而不是“解决无意义问题”；不可读又被误认为本质复杂性，而非偶然复杂性。最后一点最接近答案：好工程师降低复杂性，差工程师放大复杂性。托尔斯泰写过……

wildermuthn查看英文原文

It’s interesting there are so many different answers given to this question whenever it is asked. If we asked, “What makes a good surgeon?” or as pointed out in another comment, “What makes for a great basketball player?” it seems that there would be less debate. It seems to me that this debate is related to another question, “Why do so many software projects fail when you don’t see any skyscrapers collapsing under their own weight?” If you could build a skyscraper according to rules limited only by our imagination, then perhaps we’d see a lot more of them collapsing. And given that frequency of failure, we’d see a lot more debate about what makes for excellence in skyscraper-building. Maybe a better question to ask is, “What makes for a poor software engineer?” That question seems a lot easier to answer. A poor engineer takes a long time to write unreadable, unmaintainable, buggy code that only partially solves problems that no one has. Ironically, such code often goes unnoticed by its very nature: it takes a lengthy period of time to even come into existence, when it does exist it is so buggy that its failure seems related to bugs rather than that it solves no problems, and the unreadable nature of the code is mistakenly attributed to essential complexity rather than incidental. And that last point is where I think we get closest to an answer: Good engineers reduce complexity. Bad engineers magnify complexity. Tolstoy wrote, “All Happy families resemble one another, but each unhappy family is unhappy in its own way.” It seems to me that the same could be said of software engineers.

补充认为论文内容泛泛，推荐 Lawrence Kesteloot 的《Norris Numbers》作为更有信息量的替代阅读。

正如其他评论者指出，这篇文章相当泛泛，很少具体到软件工程。要读同主题但信息量更大的内容，推荐 Lawrence Kesteloot 的《Norris Numbers》：https://www.teamten.com/lawrence/writings/norris-numbers.html

calcsam查看英文原文

As other commenters have noted, this is a quite generic article with very little specific to software engineering. For a much more informative take on the same topic, read "Norris Numbers" by Lawrence Kesteloot: https://www.teamten.com/lawrence/writings/norris-numbers.html

历次讨论

2020Hacker News 讨论帖305 分 · 164 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

卓越软件工程师有何特质？

导读

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木