Merge pull request #2040 from Stevearzh/master

[translated by Stevearzh]20141108 When hackers grow old.md
赞！据说这篇比较难翻译，等我合并了仔细拜读:>

sources/talk/20141108 When hackers grow old.md

@@ -1,66 +0,0 @@
-[Translating by Stevearzh]
-When hackers grow old
-================================================================================
-Lately I’ve been wrestling with various members of an ancient and venerable open-source development group which I am not going to name, though people who regularly follow my adventures will probably guess which one it is by the time I’m done venting.
-
-Why it so freaking hard to drag some people into the 21st century? Sigh…
-
-I’m almost 56, an age at which a lot of younger people expect me to issue semi-regular salvos of get-off-my-lawn ranting at them. But no – I find, that, especially in technical contexts, I am far more likely to become impatient with my age peers.
-
-A lot of them really have become grouchy, hidebound old farts. And, alas, it not infrequently falls to me to be the person who barges in and points out that practices well-adapted for 1995 (or, in the particular case I’m thinking of, 1985) are … not good things to hold on to decades later.
-
-Why me? Because the kids have little or no cred with a lot of my age peers. If anyone’s going to get them to change, it has to be someone who is their peer in their own perception. Even so, I spend a lot more time than seems just or right fighting inertia.
-
-Young people can be forgiven for lacking a clue. They’re young. Young means little experience, which often leads to unsound judgment. It’s more difficult for me to forgive people who have been around the track often enough that they should have a clue, but are so attached to The Way It’s Always Been Done that they can’t see what is in front of their freaking noses.
-
-(News flash: I really don’t have a conservative temperament. I find it wryly amusing how often both conservatives and non-conservatives who argue politics with me fail to notice this.)
-
-OK, now let’s talk about GNU ChangeLog files. They were a fine idea, a necessary one even, in 1985. The idea was to use a single ChangeLog entry to document a group of related changes to multiple files. This was a reasonable adaptation to absent or extremely primitive version control. I know this because I was there.
-
-Even in 1995, or as late as the early 2000s, many version control systems didn’t have changesets. That is, there was no or only weak support for grouping multiple file modifications into a single retrievable object with a comment attached to the object rather than to individual file modifications. CVS, the system in widest use then, only faked changesets – and did it so badly that many people felt they couldn’t rely on that feature. ChangeLog files still made some functional sense.
-
-But then Subversion – with real changesets – achieved wide acceptance through its beta releases around 2003 and its 1.0 in 2004. It should have been obvious then, even before the new wave of DVCSes that began a year later, that there was a culture clash a comin’. Because if your project both has a DVCS and uses the ChangeLog convention, they’re fighting for control of the same metadata.
-
-There are different ways you can adapt. One is to continue to treat the ChangeLogs as the authoritative record of the evolution of the code. In that case, you tend to get stubby or pro-forma commit comments.
-
-Another is to treat the commit comment log as authoritative. If you do that, you soon begin to wonder why you’re still writing ChangeLog entries at all. The commit metadata has better coherence with the code changes, after all – that’s what it’s designed for.
-
-(Now imagine a project in which, with the best of intentions, different people are making opposite choices out of these two. Now you have to read both the ChangeLogs and the commit logs to know what’s going on. Friction costs are rising…)
-
-A third is to try to have it both ways – duplicating commit comment data in a slightly different format in a ChangeLog entry that’s part of the commit. This has all the problems you’d expect with a representation in which there is no single point of truth; one copy gets garbled, or the ChangeLog entry gets modified so that it’s no longer in sync with the allegedly matching commit data, and life gets very confusing for anyone who comes along later and tries to figure out what people were thinking.
-
-Or, as a senior dev on a Certain Project I Won’t Name just did in email, declaring that commits can include multiple ChangeLog entries and the commit metadata is irrelevant to the Changelogs. Which we still have to write.
-
-My eyes crossed and my gorge rose when I read that. What kind of fool fails to realize that this is begging for trouble – that, actually, the whole edifice of custom around ChangeLog files is just dead weight and friction drag in a DVCS world with good browsing tools for reliable commit logs?
-
-Alas, it’s a very particular kind of fool: a hacker who has grown old and rigid. All the rationalizations he will ever utter fail to hide this. He’s attached to tactics that made sense a decade ago but have become counterproductive ceremonies now. If you tried to explain not just about git summary lines but that the correct adaptation for current toolsets is to scrap ChangeLogs entirely … well, that would be insupportable, inconceivable, and just crazy talk.
-
-Functionally this infuriates me. It is substantially harder to work on that project because of this and related nonsense. And, as badly as it happens to need young developers, that’s a real problem. It has a G+ community well into 4 digits, they’re mostly kids, and they’re not stepping up. Evidently the message has been received on the outside; the devs on this project are ancient mossbacks with inexplicable tribal fixations, and best admired from a good long distance.
-
-What gives this extra emotional edge for me is that whenever I have to butt heads with a mossback, I keep wondering: will I be like this someday? Worse, am I looking in a mirror, already rigidified and not knowing it? I mean, I get the impression from his web presence that this particular specimen is younger than me. By a good fifteen years.
-
-I feel mentally agile. I don’t get frustrated by people moving faster than I can handle, I get frustrated by people who can’t keep up with me, who can’t see the obvious. But this self-belief could be just a bad case of Dunning-Krueger effect biting me where I least understand it. Very few things terrify me; this possibility is high on the short list.
-
-A separately disconcerting thing is that as I get older this sort of collision is happening more often rather than less. Somehow I expected my hacker peers to age more gracefully, to retain their neotenous flexibility even if they were physically aging. Some do indeed seem to be going that way; too many, alas, are not. It is a sadness.
-
-I’m not sure I have a good finish for this. If I’ve escaped mentally rigidifying (and that’s an if) I think I know at least in part why, but I’m very unsure whether it can be generally replicated – you might need to have a wired-in brain chemistry that matches the strategy. Nevertheless, for whatever it’s worth, here is my advice to young hackers and indeed the young of all kinds.
-
-You – yes, even you – cannot count on retaining your mental flexibility into middle and old unless you work at it. You have to practice busting out of comfortable mental grooves and regularly checking your assumptions when you’re young, and you have to develop a habit of it that sustains into old age.
-
-It’s said that the best time for a middle-aged person to start (physically) exercising is thirty years ago. I think the same goes for the habits that might (might!) keep you mentally agile at 56, or 65. Push your envelope. Develop the regular practice of challenging yourself and exiting your comfort zone now so you’ll have it established when you really need it.
-
-You have to be realistic about this; there’s an optimal-challenge level where you choose an attainable goal and work mentally hard for it. This month I’m going to learn go. Not the game, I already play that (though not very well); the programming language. Not because I really need to for a specific project, but because it’s time to stretch myself.
-
-Develop that habit. And never let it go.
-
---------------------------------------------------------------------------------
-
-via: http://esr.ibiblio.org/?p=6485
-
-作者：[Eric Raymond][a]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
-
-[a]:http://esr.ibiblio.org/?author=2

translated/talk/20141108 When hackers grow old.md

@@ -0,0 +1,65 @@
+黑客年暮
+================================================================================
+近来我一直在与某资深开源组织的各成员进行争斗，尽管密切关注我的人们会在读完本文后猜到是哪个组织，但我不会在这里说出这个组织的名字。
+
+怎么让某些人进入 21 世纪就这么难呢？真是的...
+
+我快56 岁了，也就是大部分年轻人会以为的我将时不时朝他们发出诸如“滚出我的草坪”之类歇斯底里咆哮的年龄。但事实并非如此 —— 我发现，尤其是在技术背景之下，我变得与我的年龄非常不相称。
+
+在我这个年龄的大部分人确实变成了爱发牢骚、墨守成规的老顽固。并且，尴尬的是，偶尔我会成为那个打断谈话的人，然后提出在 1995 年（或者在某些特殊情况下，1985 年）时很适合的方法... 但十年后就不是个好方法了。
+
+为什么是我？因为我的同龄人里大部分人在孩童时期都没有什么名气。任何想要改变自己的人，就必须成为他们中具有较高思想觉悟的佼佼者。即便如此，在与习惯做斗争的过程中，我也比实际上花费了更多的时间。
+
+年轻人犯下无知的错误是可以被原谅的。他们还年轻。年轻意味着缺乏经验，缺乏经验通常会导致片面的判断。我很难原谅那些经历了足够多本该有经验的人，却被<em>长期的固化思维</em>蒙蔽，无法发觉近在咫尺的东西。
+
+（补充一下：我真的不是老顽固。那些和我争论政治的，无论保守派还是非保守派都没有注意到这点，我觉得这颇有点嘲讽的意味。）
+
+那么，现在我们来讨论下 GNU 更新日志文件这件事。在 1985 年的时候，这是一个不错的主意，甚至可以说是必须的。当时的想法是用单独的更新日志文件来记录相关文件的变更情况。用这种方式来对那些存在版本缺失或者非常原始的版本进行版本控制确实不错。当时我也在场，所以我知道这些。
+
+不过即使到了 1995 年，甚至 21 世纪早期，许多版本控制系统仍然没有太大改进。也就是说，这些版本控制系统并非对批量文件的变化进行分组再保存到一条记录上，而是对每个变化的文件分别进行记录并保存到不同的地方。CVS，当时被广泛使用的版本控制系统，仅仅是模拟日志变更 —— 并且在这方面表现得很糟糕，导致大多数人不再依赖这个功能。即便如此，更新日志文件的出现依然是必要的。
+
+但随后，版本控制系统 Subversion 于 2003 年发布 beta 版，并于 2004 年发布 1.0 正式版，Subversion 真正实现了更新日志记录功能，得到了人们的广泛认可。它与一年后兴起的分散式版本控制系统（Distributed Version Control System，DVCS）共同引发了主流世界的激烈争论。因为如果你在项目上同时使用了分散式版本控制与更新日志文件记录的功能，它们将会因为争夺相同元数据的控制权而产生不可预料的冲突。
+
+另一种方法是对提交的评论日志进行授权。如果你这样做了，不久后你就会开始思忖为什么自己仍然对所有的日志更新条目进行记录。提交的元数据与变化的代码具有更好的相容性，毕竟这就是它当初设计的目的。
+
+（现在，试想有这样一个项目，同样本着把项目做得最好的想法，但两拨人却做出了完全不同的选择。因此你必须同时阅读更新日志和评论日志以了解到底发生了什么。最好在矛盾激化前把问题解决....）
+
+第三种办法是尝试同时使用两种方法 —— 以另一种格式再次提交评论数据，作为更新日志提交的一部分。这解决了所有你期待的有代表性的问题，并且没有任何缺陷遗留下来；只要其中有拷贝文件损坏，日志文件就会修改，因此这不再是同步时数据匹配的问题，而且导致在其后参与进来的人试图搞清人们是怎么想的时候将会变得非常困惑。
+
+或者，如某个<em>我就不说出具体名字的特定项目</em>的高层开发只是通过电子邮件来完成这些，声明提交可以包含多个更新日志，以及提交的元数据与更新日志是无关的。这导致我们直到现在还得不断进行记录。
+
+当我读到那条的时候我的眼光停在了那个地方。什么样的傻瓜才会没有意识到这是在自找麻烦 —— 事实上，针对更新日志文件采取的定制措施完全是不必要的，尤其是在分散式版本控制系统中
+有很好的浏览工具来阅读可靠的提交日志的时候。
+
+唉，这是比较特殊的笨蛋：变老的并且思维僵化了的黑客。所有的合理化改革他都会极力反对。他所遵循的行事方法在十年前是有效的，但现在只能使得其反了。如果你试图解释不只是git的总摘要，还得正确掌握当前的各种工具才能完全弃用更新日志... 呵呵，准备好迎接无法忍受、无法想象的疯狂对话吧。
+
+幸运的是这激怒了我。因为这点还有其他相关的胡言乱语使这个项目变成了很难完成的工作。而且，这类糟糕的事时常发生在年轻的开发者身上，这才是问题所在。相关 G+ 社群的数量已经达到了 4 位数，他们大部分都是孩子，他们也没有紧张起来。显然消息已经传到了外面；这个项目的开发者都是被莫名关注者的老牌黑客，同时还有很多对他们崇拜的人。
+
+这件事给我的最大触动就是每当我要和这些老牌黑客较量时，我都会想：有一天我也会这样吗？或者更糟的是，我看到的只是如同镜子一般对我自己的真实写照，而我自己却浑然不觉吗？我的意思是，我的印象来自于他的网站，这个特殊的样本要比我年轻。通过十五年的仔细观察得出的结论。
+
+我觉得思路很清晰。当我和那些比我聪明的人打交道时我不会受挫，我只会因为那些不能跟上我的人而
+沮丧，这些人也不能看见事实。但这种自信也许只是邓宁·克鲁格效应的消极影响，至少我明白这点。很少有什么事情会让我感到害怕；而这件事在让我害怕的事情名单上是名列前茅的。
+
+另一件让人不安的事是当我逐渐变老的时候，这样的矛盾发生得越来越频繁。不知怎的，我希望我的黑客同行们能以更加优雅的姿态老去，即使身体老去也应该保持一颗年轻的心灵。有些人确实是这样；但可是绝大多数人都不是。真令人悲哀。
+
+我不确定我的职业生涯会不会完美收场。假如我最后成功避免了思维僵化（注意我说的是假如），我想我一定知道其中的部分原因，但我不确定这种模式是否可以被复制 —— 为了达成目的也许得在你的头脑中发生一些复杂的化学反应。尽管如此，无论对错，请听听我给年轻黑客以及其他有志青年的建议。
+
+你们 —— 对的，也包括你 —— 一定无法在你中年老年的时候保持不错的心灵，除非你能很好的控制这点。你必须不断地去磨练你的内心、在你还年轻的时候完成自己的种种心愿，你必须把这些行为养成一种习惯直到你老去。
+
+有种说法是中年人锻炼身体的最佳时机是他进入中年的 30 年前。我以为同样的方法，坚持我以上所说的习惯能让你在 56 岁，甚至 65 岁的时候仍然保持灵活的头脑。挑战你的极限，使不断地挑战自己成为一种习惯。立刻离开安乐窝，由此当你以后真正需要它的时候你可以建立起自己的安乐窝。
+
+你必须要清楚的了解这点；还有一个可选择的挑战是你选择一个可以实现的目标并且为了这个目标不断努力。这个月我要学习 Go 语言。不是指游戏，我早就玩儿过了（虽然玩儿的不是太好）。并不是因为工作需要，而是因为我觉得是时候来扩展下我自己了。
+
+保持这个习惯。永远不要放弃。
+
+--------------------------------------------------------------------------------
+
+via: http://esr.ibiblio.org/?p=6485
+
+作者：[Eric Raymond][a]
+译者：[Stevearzh](https://github.com/Stevearzh)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
+
+[a]:http://esr.ibiblio.org/?author=2