Several people at React Conf asked me for advice on becoming a better programmer. For some reason, people see me as a pretty advanced programmer worth listening to. I thought it would be worthwhile to write down my "mental model" for how I have approached programming over the years.
React Conf 上的几个人向我寻求关于成为一名更好的程序员的建议。出于某种原因，人们认为我是一个值得倾听的非常高级的程序员。我认为有必要写下我多年来如何进行编程的“心智模型”。

Some details about me: I'm 32 years old and have over 10 years of solid experience. It probably wasn't until the last few years until I really felt confident in what I was doing. Even now, though, I continually doubt myself. The point is that this feeling doesn't go away, so just try to ignore it, keep hacking, and keep building experience.
关于我的一些详细信息： 我今年 32 岁，拥有超过 10 年的丰富经验。可能直到最近几年我才真正对自己所做的事情充满信心。但即使是现在，我仍然不断怀疑自己。关键是这种感觉不会消失，所以尽量忽略它，继续黑客攻击，继续积累经验。

Let me be clear that these are only a few tips for improving your skills. Ultimately you need to figure out what works best for you. These are just things that I have found helpful.
让我明确一点，这些只是提高您的技能的一些技巧。最终，您需要弄清楚什么最适合您。这些只是我发现有帮助的事情。

• Find people who inspire you, but don't idolize them.
  寻找那些激励你的人，但不要崇拜他们。

  Over the years there have been many people that I looked up to and watched for new tech. I learned a lot by simply trusting they were right and digging into things they worked on. These people tend to be very productive, brilliant, and inspiring. Find them and let them inspire and teach you.
  多年来，我尊敬并关注许多人寻找新技术。通过简单地相信他们是对的并深入研究他们所做的事情，我学到了很多东西。这些人往往非常富有成效、才华横溢且鼓舞人心。找到他们，让他们启发和教导你。

  However, make sure not to idolize them. It's easy to seem intimidating from a twitter feed, but if you look at how they work in real life, you'll see that they aren't that different. Hacks everywhere, etc. We're all just experimenting. Lastly, don't blindly trust them; if you disagree, engage them and learn from it. Some of my most productive conversations happened this way.
  但是，请确保不要崇拜他们。推特上的内容很容易显得令人生畏，但如果你看看它们在现实生活中的工作方式，你会发现它们并没有那么不同。黑客无处不在，等等。我们都只是在尝试。最后，不要盲目相信他们；如果您不同意，请与他们接触并从中学习。我的一些最富有成效的谈话就是这样发生的。

  My Emacs config is a mess. I don't know why my OCaml autocompletion is broken (it's been broken for over a month). I don't automate stuff and have to dig around in my shell history to find commands I need sometimes. I write the ugliest code at first. I stick things on the global object until I know what I'm doing. The most experienced programmer uses hacks all the time; the important part is that you're getting stuff done.
  我的 Emacs 配置一团糟。我不知道为什么我的 OCaml 自动完成功能被破坏了（它已经被破坏了一个多月了）。我不会自动执行某些操作，有时必须在 shell 历史记录中查找我需要的命令。我一开始写的是最丑陋的代码。我把东西粘在全局对象上，直到我知道我在做什么。最有经验的程序员总是使用 hack；重要的是你正在把事情做好。

• Don't devalue your work.  不要贬低你的工作。

  Newer programmers tend to feel like their work isn't worth much because they are new. Or maybe you are an experienced programmer, but working in a new area that makes you uncomfortable. In my opinion, some of the best ideas come from newer programmers who see improvements to existing tech that those who have already-formed opinions don't see.
  较新的程序员倾向于觉得他们的工作不值得，因为他们是新的。或者，也许您是一位经验丰富的程序员，但是在新领域工作，这会让您感到不舒服。我认为，一些最好的想法来自较新的程序员，他们看到已经成立意见的人看不到的现有技术的改进。

  Your work is worthwhile, no matter what. In the worst case, if your idea doesn't work out, the community will have learned better why that approach doesn't make sense. (A note to the community: it's up to us to execute on this and be welcoming to newcomers.)
  无论如何，您的工作都是值得的。在最糟糕的情况下，如果您的想法无法解决，社区将更好地学会为什么这种方法没有意义。 （对社区的注释：由我们执行此操作，并欢迎新移民。）

• Don't feel pressured to work all the time.
  不要一直都感到压力。

  With new tech coming out every day, it can feel like the world will move on without you if you take a night off. That's not true. In fact, you will do better work if you disengage a lot. Your perspective will be fresh, and I find myself subconsciously coming up with new ideas when I'm not working.
  随着新技术每天的推出，如果您休假一个夜晚，就会感觉世界将继续前进。那不是真的。实际上，如果您脱离很多东西，您将做得更好。您的观点将是新鲜的，当我不工作时，我发现自己在潜意识中提出了新想法。

  The majority of the stuff being released every day is just a rehash of the same ideas. Truly revolutionary stuff only happens every few years. A good talk to watch on this subject is Hammock Driven Development.
  每天都会发布的大多数内容只是相同想法的重塑。真正革命性的东西只有每隔几年就会发生。吊床驱动的开发是一个很好的谈话。

• Ignore fluff.  忽略绒毛。

  One of the biggest ways you can objectively get better faster is by ignoring "fluff" that won't actually improve your skills very much. Another way to say this is "use your time wisely". You only have so many hours in the day and if you spend it on deeper things you will see a big difference over time.
  您可以客观地提高更好的速度的最大方法之一就是忽略“绒毛”，而“绒毛”实际上不会太大的技能。另一种说法是“明智地利用您的时间”。您一天只有这么多小时，如果您将其花在更深层次上，您会看到随着时间的流逝有很大的差异。

  So what is "fluff"? It's up to you, but I can give you some examples of what I consider fluff: language syntax, library APIs, and configuring build tooling. Learning a new ES7 JS syntax won't make you a better programmer nearly as much as learning how compilers work, for example. Adopting a new library that implements the same idea but with a new API isn't that interesting. All of those things are important, of course, but I recommend spending more time learning deeper concepts that will reward you for years.
  那么什么是“绒毛”？这取决于您，但我可以为您提供一些我认为绒毛的示例：语言语法，库API和配置构建工具。例如，学习新的ES7 JS语法并不会像学习编译器的工作方式一样多。采用一个实现相同想法但使用新API的新库并不有趣。当然，所有这些事情都很重要，但是我建议花更多的时间学习更深入的概念，以奖励您多年。

  Here's a question I like to ask: do you spend most of your time making your code look "nice"? If so, I recommend not focusing on it so much. Your code is going to change a lot over time anyway. It's better to focus hard on the core problems you're trying to solve and think hard about your layers of abstractions. After you've nailed all of that you can spend a little time polishing your code. (This also applies to the DRY principle. Don't worry about it so much. Feel free to duplicate.)
  我想问的是一个问题：您大部分时间都花费大部分时间使代码看起来“不错”？如果是这样，我建议不要那么关注它。无论如何，您的代码会随着时间的推移而改变。最好将重点放在您试图解决的核心问题上，并在抽象层面上进行努力思考。钉完所有这些后，您可以花一点时间抛光代码。 （这也适用于干燥原理。不必担心它。随意复制。）

• Dig into past research.  深入研究过去的研究。

  If you're excited about an idea, it's super tempting to sit down an immediately get going. But you shouldn't do that until you've done some cursory research about how people have solved it before. Spending a few days researching the topic always completely changes how I am going to solve it.
  如果你对一个想法感到兴奋，那么你很容易坐下来立即开始。但是，除非您对人们以前如何解决这个问题进行了一些粗略的研究，否则您不应该这样做。花几天时间研究这个主题总是会彻底改变我解决问题的方式。

  It's valuable to learn how to read academic papers. I don't know anything about denotational/operational/etc semantics so there are a lot of papers I can't read. But there are many that use code instead of math and aren't too hard to read. There is a huge amount of knowledge sitting in papers from the last 30 years. If you get good at extracting this, you'll be a thought-leader in no time.
  学习如何阅读学术论文很有价值。我对指称/操作/等语义一无所知，所以有很多论文我无法阅读。但有许多使用代码而不是数学，并且不太难读。过去 30 年的论文中蕴藏着大量知识。如果你善于提取这一点，你很快就会成为思想领袖。

  Prettier is a perfect example of this. I knew what I wanted but I had no idea how to implement it. After a little research I found this paper and after a few days I knew exactly what I needed to do. I had something basic working in a week. If I ignored previous research it would have taken a lot longer.
  Prettier 就是一个完美的例子。我知道我想要什么，但我不知道如何实现它。经过一番研究后，我找到了这篇论文，几天后我确切地知道我需要做什么。我在一周内完成了一些基本的工作。如果我忽略以前的研究，那将会花费更长的时间。

  If you're looking for papers, the Papers We Love GitHub repo is a great place to start.
  如果您正在寻找论文，我们喜欢GitHub Repo的论文是一个不错的起点。

• Take on big projects. Get uncomfortable.
  进行大型项目。变得不舒服。

  There's nothing better than experience. Not everyone is in the position to experiment, but if you have time, try and take on some big projects. You don't even need to finish them. Just trying to tackle something like writing a compiler will teach you tons in the first few weeks.
  没有什么比经验更好的了。不是每个人都有资格进行实验，但如果你有时间，请尝试承担一些大项目。你甚至不需要完成它们。仅仅尝试解决诸如编写编译器之类的问题就会在最初几周内教会您很多知识。

  I honestly hate the feeling where I have no idea how to solve a complex problem. It's uncomfortable. I know I'll have to do a lot of research and learning before I'm even close to a solution. But I'm always a much better programmer afterwards.
  老实说，我讨厌我不知道如何解决复杂问题的感觉。这是不舒服的。我知道我必须在接近解决方案之前进行大量的研究和学习。但是之后我总是一个更好的程序员。

  Start with learning a new language. It's the most effective way to force you out of your current habits and see things in a new light. For me, the best thing I did as a young programmer was learn Scheme. It's an extremely simple language and forces you to do everything in a functional style, and really learn the fundamentals of how code works. The few years I spent in Scheme are still paying off today; the way I see code is fundamentally changed. (I even named my company Shift Reset LLC after the shift/reset operators from Scheme.)
  从学习新语言开始。这是迫使您摆脱当前习惯并以新的眼光看待事物的最有效方法。对我来说，我年轻的程序员所做的最好的事情是学习计划。这是一种非常简单的语言，迫使您以功能风格的方式完成所有操作，并真正了解代码的工作原理。我花在计划上的几年仍在还清。我看到代码的方式从根本上改变了。 （我什至以Shift/Reset运算符的计划命名了我的公司Shift Reset LLC。）

  Here's a list of a few things I would recommend doing. These are all things that had huge impacts on my programmer career. Most of them continue to pay off to this day in subtle ways and help me to deconstruct new ideas mentally. You don't need to do these to become a good programmer, and there are many other things you can learn to improve yourself, but these are what helped me.
  以下是我建议做的一些事情的列表。这些都是对我的程序员职业生涯产生巨大影响的事情。其中大多数至今仍在以微妙的方式产生回报，并帮助我在精神上解构新想法。你不需要做这些才能成为一名优秀的程序员，还有很多其他的东西你可以学习来提高自己，但这些对我有帮助。

  • Learn C - Just the basics, if you don't already. I think it's valuable to understand why everyone complains about it.
    学习C-如果您还没有的话，只是基础知识。我认为了解每个人为什么都抱怨它是很有价值的。
  • Write a compiler - Perhaps the best way to get uncomfortable and learn. Check out the super tiny compiler.
    编写一个编译器——也许是感到不舒服和学习的最好方法。查看超小型编译器。
  • Learn macros - See Scheme, Lisp, or Clojure(Script). Macros will really change how you see code.
    学习宏 - 请参阅Scheme、Lisp 或Clojure(Script)。宏将真正改变您看待代码的方式。
  • SICP - SICP is an old book that I think is still relevant today (some people disagree). It assumes very little programming knowledge and walks you all the way up to implementing a meta-circular evaluator and compiler. Another book I really enjoyed and goes a lot deeper in compilers is Lisp In Small Pieces.
    SICP - SICP 是一本老书，我认为今天仍然有意义（有些人不同意）。它需要很少的编程知识，并引导您一路实现元循环求值器和编译器。我非常喜欢的另一本书是《Lisp In Small Pieces》，它对编译器进行了更深入的研究。
  • Understand continuations - Continuations are a low-level control flow mechanism. Scheme is the only language to implement them, and while you will never use them in production, they will change how you think about control flow. I wrote a blog post trying to explain them.
    理解连续 - 连续性是低级控制流动机制。方案是唯一实施它们的语言，尽管您永远不会在生产中使用它们，但它们将改变您对控制流的看法。我写了一篇博客文章，试图解释它们。
  • If anything, just try a new language - Regardless of what you do, you really should explore other languages. I would recommend any of the following: Clojure, Rust, Elm, OCaml/Reason, Go, or Scheme. All of them have unique features and will force you to learn a new way of thinking.
    如果有的话，只需尝试一种新的语言 - 无论您做什么，您都应该探索其他语言。我会推荐以下任何内容：Clojure，Rust，Elm，Ocaml/Reason，Go或Scheme。所有这些都有独特的功能，并将迫使您学习一种新的思维方式。