成为高级工程师看什么书
Most commonly known for the creation of the Clojure programming language, Rich Hickey can easily be considered a brilliant and experienced engineer with 20-plus years of experience in the field.
Rich Hickey以创建Clojure编程语言最为人所知，可以轻松地视为具有20多年在该领域经验的出色而经验丰富的工程师。
But he’s also a great thinker and speaker who’s able to distill and give shape to ideas that are not easily put into words.
但是他还是一位伟大的思想家和演讲者，能够提炼和塑造不容易用语言表达的想法。
Let me put it this way: That's 20-plus years of deliberate practice in software development distilled into 20-30 minutes of talking.
让我这样说：在20到30分钟的交谈中提炼了20多年的软件开发实践经验。
Such talks are often related to broad problems and ways of thinking rather than one specific language or practice in our field. Here are the ones that I believe we can really benefit from listening to.
此类谈话通常与广泛的问题和思维方式有关，而不是与我们领域中的一种特定语言或实践有关。 以下是我认为我们可以真正从中受益的内容。
简单轻松 (Simple Made Easy)
In this talk, Rich explains how simple and easy are quite different things. He also discusses how we, as software developers, can make our own lives harder sometimes.
在本次演讲中，Rich解释了简单和轻松有何不同 东西。 他还讨论了作为软件开发人员的我们如何有时会使自己的生活更加艰难。
He also makes a point of how important — or better yet, absolutely necessary — simplicity is for building good, reliable software.
他还指出了简化对于构建良好，可靠的软件有多重要(甚至更好，但绝对必要)。
“[…] The first word is 'simple,' and what it means is one fold or twist. You can contrast that with 'complex,' which means to combine many things or to braid together things. And we distinguish that from easy, which in the derivation I like means 'to lie near.'”
“ […]第一个单词是“简单”，它的意思是折叠或扭曲。 您可以将其与“复杂”进行对比，“复杂”是指将许多事物组合在一起或将它们编织在一起。 我们将其与轻松区分开来，在我的推导中，我喜欢的意思是“靠近”。
Rich's point is that something being easy is always relative. It is subjective to each individual, depending on the experience or familiarity you have with a given problem or skill. Simple, on the other hand, is objective and analyzable.
Rich的观点是， 简单的事情总是相对的。 它取决于每个人，具体取决于您对给定问题或技能的经验或熟悉程度。 另一方面，简单是客观且可分析的。
"How does that connect to software?" you might be wondering. I'll let the man answer this one for you:
“那如何连接到软件？” 您可能想知道。 我会让这个人为您回答：
“But we can only think about a couple of things at a time and the main problem we have with things that aren't simple is that when it comes time for us to think about them, such as when I have to enhance a part of my system or fix a problem in it, I pull a string and I get this knot of other stuff that's connected to it. And I have to blow all of that stuff up in order to think about it, in order to solve my problem. So this tying of things together is going to fundamentally undermine our ability to understand and change them.”
“但是我们一次只能考虑几件事，而对于不简单的事情，我们面临的主要问题是，当我们需要考虑这些问题时，例如，当我不得不加强其中的一部分时，我的系统或解决了其中的问题后，我拉了一根绳子，并得到了与此连接的其他连接的结。 为了解决我的问题，我必须炸掉所有这些东西。 因此，将事物捆绑在一起会从根本上破坏我们理解和更改事物的能力。”
He also claims that we should be aware of good design, as design is, by definition, pulling things apart. This enables designs to be simpler and easier to use, substitute, and extend.
他还声称，我们应该意识到良好的设计，因为按照定义，设计就是将事物分开。 这使设计变得更简单，更易于使用，替换和扩展。
He then raises a number of things that software developers do to make our lives easier but our software worse — or at least not as simple as it should be. Ouch. He makes great suggestions on how to improve, though.
然后，他提出了软件开发人员要做的许多事情，以使我们的生活更轻松，但我们的软件却变得更糟-或至少没有应有的简单。 哎哟。 不过，他对如何改进提出了很好的建议。
Totally worth watching one or more times.
完全值得观看一次或多次。
吊床驱动的开发 (Hammock-Driven Development)
The idea that Rich defends in this one is that we should solve problems — not create features. Spend more time stating problems, understanding them, and then designing and analyzing solutions rather than coding straight away.
Rich为此辩护的想法是，我们应该解决问题，而不是创建功能。 花更多的时间陈述问题，理解问题，然后设计和分析解决方案，而不是立即进行编码。
“Problem-solving is definitely a skill. You shouldn’t take away from this talk that there is a certain kind of person who’s good at problem-solving and gets to do that part of the job. […] If you practice problem-solving, you will get good at it.”
解决问题绝对是一项技能。 您不应该离开这个话题，认为有些人善于解决问题并能胜任这项工作。 […]如果您练习解决问题，就会有所作为。”
According to Rich, being a good problem-solver provides way more leverage than being good at any other practice or methodology.
Rich认为，成为优秀的解决问题者比提供擅长任何其他实践或方法的方法所提供的杠杆作用更大。
But how? How can you practice problem-solving and be more aware of your solutions? According to Rich, you should:
但是如何？ 您如何练习解决问题的方式，并更加了解自己的解决方案？ 根据Rich所说，您应该：
- State the problem. 陈述问题。
- Understand the problem. 了解问题。
- De discerning, be critical. Be aware of trade-offs. 挑剔，要批判。 注意权衡。
- Maintain your focus when doing design work 在进行设计工作时保持专注
The title of the talk itself derives from this little “tactic” that can help you focus and be away from the computer and other sources of distraction:
演讲的标题本身就是这种“战术”，可以帮助您集中精力并远离计算机和其他干扰因素：
“There are some cool aspects to the hammock. One of the cool aspects to a hammock is that you can go on the hammock, close your eyes, and no one knows that you are not sleeping. But they won’t bother you because they think you might be sleeping. So it’s very cool!”
“吊床有一些很酷的方面。 吊床最酷的方面之一是您可以躺在吊床上，闭上眼睛，而且没人知道您没有睡觉。 但是他们不会打扰您，因为他们认为您可能正在睡觉。 所以这很酷！”
Rick then discusses some aspects of the way the human mind works, its different “modes” of operation, and how you can leverage that. This one is more of a lighthearted talk, but it brings great value nonetheless.
然后，Rick讨论了人脑工作方式的某些方面，其不同的“操作模式”以及如何利用它。 这只是一个轻松的话题，但仍然带来了巨大的价值。
设计，组成和性能 (Design, Composition, and Performance)
This talk is about software design and how it contrasts with implementation. The concept is explained through analogies with music and musical instruments. Initially, Rich focuses on explaining what good design is about and how you can benefit from it, but the content really shines once he starts making analogies with music. The core takeaways from this one are tips Rich gives on how to be a better engineer:
这次演讲的主题是软件设计及其与实施的对比。 通过类比音乐和乐器来解释该概念。 最初，Rich专注于解释什么是好的设计以及如何从中受益，但是一旦他开始对音乐进行类比，内容就会真正闪耀。 Rich的核心要点是Rich提出的如何成为一名更好的工程师的技巧：
- Take things apart — not by smashing them with a hammer, but with an eye for how you are going to put them back together. That is what design is about. 拆散物品-不是用锤子砸碎，而是要注意如何将它们放回原处。 这就是设计的目的。
- You want to design like a composer — not in the sense that you need to design every note for every player but how the things you are working on fit at every level. Bring design into the small things, the medium things, and the large things, and often apply different techniques and ways of thinking for each level. 您想像作曲家那样设计-不是要为每个演奏者设计每个音符，而是要在各个层次上适应各种情况。 将设计带入小型事物，中型事物和大型事物，并经常在每个级别应用不同的技术和思维方式。
You want to code like a jazz player. Jazz players improvise with apparent magical genius, but only after acquiring harmonic sensibility after studying a lot. Likewise, bring that design sensibility to the coding that you do. That is, write code backed by a solid design perspective.
您想要像爵士乐演奏者一样编码。 爵士乐演奏者即兴演奏具有明显的魔幻天才，但只有经过大量研究后才能获得谐音。 同样，将设计敏感性带入您执行的编码中。 也就是说，编写具有可靠设计观点支持的代码。
Design is like composition, whereas implementation is like performance and improvisation.
设计就像构图，而实现就像性能和即兴创作。
“When you hear an improvisation, what you end up hearing is an application of a lot of knowledge and a tremendous amount of vocabulary. It’s almost a dynamic composition that’s happening. […] So it’s this delicate balance of being able to be dynamic, but having compositional sensibilities to apply on the fly. That’s what developers need.”
“当您听到即兴演奏时，最终听到的是大量知识和大量词汇的应用。 这几乎是一种动态的组合。 […]这就是动态变化，但具有动态应用感的构图平衡。 这就是开发人员所需要的。”
Then a new analogy is made: Programming languages are like instruments — especially because both of them are limited. Instruments can’t produce any arbitrary sound, but the performer overcomes that via various techniques when necessary.
然后产生一个新的类比：编程语言就像工具-尤其是因为它们两者都是有限的。 乐器不能发出任何声音，但是演奏者在必要时可以通过各种技术克服这种声音。
Well, why aren’t there instruments that can produce any sound? That is, why aren’t there programming languages that can do anything? According to Rich, it would be extremely hard to build (or compose) using such complex targets. Those would become unpredictable.
那么，为什么没有可以产生声音的乐器呢？ 也就是说，为什么没有可以做任何事情的编程语言？ Rich认为，使用这样复杂的目标很难构建(或组成)。 这些将变得不可预测。
Rich also offers an interesting take on pair programming:
Rich还提供了有关配对编程的有趣观点：
“Instruments are for one person to play at the same time. And yet, we have these complicated tmux-whatever things. I don’t want to diss pairing because while I personally don’t understand it, I can see analogies. For instance, two musicians playing in the same room, and that obviously has good effects.
“乐器是一个人同时玩的乐器。 但是，无论这些东西如何，我们都有这些复杂的tmux。 我不想取消配对，因为虽然我个人不了解，但可以看到类比。 例如，两个音乐家在同一个房间里演奏，显然效果很好。
But you have to wonder: Is this just a way to keep somebody from typing all the time? If we had an otherwise built-in time for design, is pairing one way that we are trying to buy it? It’s a fair question.”
但是您必须怀疑：这仅仅是一种阻止某人一直打字的方法吗？ 如果我们有原本需要的内置设计时间，那么配对是我们尝试购买的一种方式吗？ 这是一个公平的问题。”
The point of developers “practicing” (i.e. studying somehow) is also important:
开发人员“练习”(即以某种方式学习)的观点也很重要：
“I don’t know why, as software developers, we think we can just show up. Everybody else practices. Obviously, we went to school and studied whatever we studied, but musicians are not like ‘Well, I went to school, so now I don’t need to practice anymore.’”
“我不知道为什么，作为软件开发人员，我们认为我们可以露面。 其他人都练习。 显然，我们去学校学习了所学的东西，但音乐家却不像“我去学校了，所以现在我不再需要练习了。”
This talk is great for more experienced developers or anyone more involved with architecture in design.
该演讲对经验丰富的开发人员或更多与设计架构有关的人员非常有用。
结语 (Wrapping Up)
If I had to summarize the lessons Rich teaches in those talks in a few sentences, those would be:
如果我不得不用几句话来概括里奇在这些演讲中所教的课程，那将是：
- Simplicity matters. Develop a grasp of simplicity. Be aware of what is simple, what is complex, what is easy, and what is hard. 简单很重要。 掌握简单性。 注意什么简单，什么复杂，什么容易，什么困难。
- Train yourself to see the trade-offs in every decision, as any technical decision will most likely be accompanied by them. Be discerning, be critical. 培训自己，以了解每个决策中的权衡，因为任何技术决策都很可能会伴随着它们。 敏锐，批判。
- See and solve the problems that are beyond code. Develop and use design skills to actually solve problems — not just write code. Use those skills to see design in code and code in design. 查看并解决代码之外的问题。 开发和使用设计技能来实际解决问题-不仅仅是编写代码。 使用这些技能来查看代码中的设计和设计中的代码。
成为高级工程师看什么书
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
