17 May 20222022 年 5 月 17 日

Last month, April 2022, marked the 10 year anniversary of my start as a professional programmer.上个月，也就是 2022 年 4 月，是我开始成为一名专业程序员的 10 周年纪念日。

I started programming earlier than that, but hadn’t been paid a salary. As a teenager I built websites and IRC bots and wrote tiny Python scripts. Then I stopped and played guitar for a few years. In my twenties, I rather coincidentally rediscovered how much I enjoy programming when I was asked to build another website and found out how much had changed about the web while I was away (it’s HTML5 now!).我比那更早开始编程，但没有拿到薪水。十几岁的时候，我建立了网站和 IRC 机器人，并编写了小型 Python 脚本。然后我停下来弹了几年吉他。在我 20 多岁的时候，当我被要求建立另一个网站时，我巧合地重新发现了我是多么喜欢编程，并发现在我离开时网络发生了多少变化（现在是 HTML5！）。

That made me wonder whether programming wouldn’t be the better career choice than continuing to study philosophy at university. Robin answered that question for me by generously offering me a paid internship.这让我想知道编程是否不是比继续在大学学习哲学更好的职业选择。罗宾慷慨地为我提供了带薪实习，为我回答了这个问题。

Now it’s been 10 years, which is, to be honest, neither a significant marker of my growth as a programmer nor my career, but realising that it’s been 10 years made me pause and reflect.现在已经 10 年了，老实说，这既不是我作为程序员成长的重要标志，也不是我职业生涯的重要标志，但意识到已经 10 年让我停下来反思。

The following is a loose, unordered collection of thoughts that come up when I look back on the past 10 years. Things I’ve learned, things I’ve unlearned, things I’ve changed my opinion on, things I never thought I’d believe in and now do.以下是我回顾过去 10 年时出现的松散、无序的想法集合。我学到的东西，我忘记的东西，我改变了看法的东西，我从没想过我会相信并且现在做的事情。

They’re very much products of the context in which I helped develop software: as an intern for Robin, then as a junior developer for Robin, as a software developer for a small German startup, as a senior software developer for a German startup inside a huge German corporation, and now as a staff engineer for a fully remote, asynchronous US startup. Take that as a disclaimer. I bet if I’d worked in a game studio, a hardware company, and a big tech corporation instead, this text would be very different.它们是我帮助开发软件的背景下的产品：作为 Robin 的实习生，然后作为 Robin 的初级开发人员，作为一家小型德国初创公司的软件开发人员，作为内部德国初创公司的高级软件开发人员一家巨大的德国公司，现在是一家完全远程、异步的美国初创公司的员工工程师。以此作为免责声明。我敢打赌，如果我在一家游戏工作室、一家硬件公司和一家大型科技公司工作，那么这篇文章会非常不同。

Fearlessness is undervalued无畏被低估

Most of the programmers I look up to and learned from share one trait that is rarely talked about: fearlessness.我仰慕和学习的大多数程序员都有一个很少被谈论的特质：无所畏惧。

They dive into an unknown codebase without fear. They open up the code of a dependency that they suspect is misbehaving without fear. They start working on something without knowing how they’ll finish.他们毫无畏惧地潜入未知的代码库。他们毫无畏惧地打开了他们怀疑行为不端的依赖项代码。他们开始做某事，却不知道如何完成。

It’s inspiring seeing someone being fearless, but becoming fearless yourself is one of the best learning accelerators I’ve found.看到有人无所畏惧是鼓舞人心的，但自己变得无所畏惧是我发现的最好的学习加速器之一。

You can’t predict the future; try and you might end up in trouble你无法预测未来；尝试一下，你可能会遇到麻烦

We all know this. Of course, we can’t predict the future.我们都知道这一点。当然，我们无法预测未来。

But it took me years to truly take it into account when programming.但是我花了好几年才真正在编程时考虑到它。

In the first third of my career I’d think: we will need this, so let’s build it now.在我职业生涯的前三分之一，我会想：我们需要这个，所以让我们现在就建造它。

In the second third: we might need this, so let’s prepare for it.在第二个三分之一：我们可能需要这个，所以让我们为它做准备。

Now: we don’t know whether we’ll need this, it’s a possibility, sure, and it looks like we might need it, yes, but things change all the time, so let’s build what we know we need right now.现在：我们不知道我们是否需要这个，这是一种可能性，当然，看起来我们可能需要它，是的，但是事情一直在变化，所以让我们现在就构建我们知道我们需要的东西。

Of course I write code so it’s easy to test当然我写代码所以很容易测试

I also write code so it’s easy to read and understand, or easy to delete, or easy to modify, or easy to review. I don’t write code only for the computer to execute.我还编写代码，使其易于阅读和理解，或易于删除，或易于修改，或易于审查。我写的代码不仅仅是为了让计算机执行。

Nothing really matters, except bringing value to the customer没有什么真正重要，除了为客户带来价值

Type safety, 100% test coverage, the ability to fluently express business logic in code, perfect development tooling, an efficient system that wastes no resources, using the best programming language for the job, an elegant API design, a fast feedback loop, writing great code – these are not the goal.类型安全、100% 的测试覆盖率、用代码流畅表达业务逻辑的能力、完善的开发工具、不浪费资源的高效系统、使用最好的编程语言来完成工作、优雅的 API 设计、快速的反馈循环、写作很棒的代码——这些不是目标。

Here’s the goal: providing value to your customers, by shipping software that solves their problem, repeatedly.目标是：通过反复发布解决客户问题的软件，为您的客户提供价值。

The things above help you do that – faster, cheaper, more efficiently, safer, with greater joy – but they’re not the goal. The goal is to provide value to your customers.上面的事情可以帮助你做到这一点——更快、更便宜、更有效、更安全、更快乐——但它们不是目标。目标是为您的客户提供价值。

The trap: it’s often easier to write software than to deliver it. But delivering is what it’s all about.陷阱：编写软件通常比交付软件更容易。但交付就是一切。

Perfection is unachievable完美是无法实现的

I’m not sure I ever thought it is, but now I’m certain it is not. Everything is the result of trade-offs.我不确定我曾经认为是这样，但现在我确定不是。一切都是取舍的结果。

You will never reach 100% on every axis that you care about. Something has to give. And when you think you did make it perfect, you’ll soon realise that you forgot something.您永远不会在您关心的每个轴上达到 100%。有些东西必须付出。当你认为你确实做到了完美时，你很快就会意识到你忘记了一些东西。

My aesthetics have changed too. Instead of looking for the beauty that lies in perfection I now think the program that succeeds despite its flaws is beautiful. Look at that little program go, holding the internet together, despite the 17 TODOs in it.我的审美也变了。与其寻找完美中的美，我现在认为尽管有缺陷但成功的程序是美的。看看那个小程序吧，它把互联网连接在一起，尽管里面有 17 个 TODO。

If you can’t connect it to the business, it doesn’t matter如果您无法将其与业务联系起来，那没关系

You can refactor a codebase and clean it up significantly, making it easier to understand for everybody and easier to extend, but all of that won’t matter if that codebase gets deleted four months later because the project didn’t help the business.您可以重构代码库并进行大量清理，让每个人都更容易理解并且更容易扩展，但如果该代码库在四个月后因为项目对业务没有帮助而被删除，那么所有这些都无关紧要。

You can spend weeks adding tracing and observability to all of the code you write, only to realise that nobody will ever look at it, because that code runs three times a day and never causes any problems.您可以花费数周时间为您编写的所有代码添加跟踪和可观察性，结果却发现没有人会看到它，因为该代码每天运行 3 次并且不会引起任何问题。

You can tweak and optimize your code to run so efficiently that the company can halve the number of machines required to run it and then see that the costs you saved are nothing in comparison to the salary you were paid while optimizing.您可以调整和优化您的代码以如此高效地运行，以至于公司可以将运行它所需的机器数量减半，然后看到您节省的成本与优化时支付的工资相比微不足道。

You can spend your time doing fantastic technical work and still waste it.你可以把时间花在出色的技术工作上，但仍然浪费。

Figure out what the rule is trying to prevent, then consider the rule optional弄清楚规则试图阻止什么，然后考虑该规则是可选的

If you’d asked me 5 years ago whether TDD, Clean Code, Software Craftsmanship, and other schools of thought are dogmatic, I would’ve said “no! Can’t you see? Clean and good code is important!”如果你在 5 年前问我 TDD、清洁代码、软件工艺和其他思想流派是否是教条主义的，我会说“不！你看不见吗？干净和好的代码很重要！”

Now I look back at the time when I thought that a rule such as “a method should not be longer than 5 lines” was useful and shake my head.现在回想一下我当时认为“方法不应该超过 5 行”这样的规则有用的时候，我摇了摇头。

It’s not about the rules! It’s about the problems these rules are trying to prevent. If you don’t have the problem they’re trying to prevent, or you can prevent it another way, you don’t need the rule.这与规则无关！这是关于这些规则试图防止的问题。如果您没有他们试图阻止的问题，或者您可以通过其他方式阻止它，则您不需要该规则。

Write tests that give you confidence that the system works as it should编写测试，让您确信系统可以正常工作

Don’t worry too much about whether a test is an integration or an end-to-end test, a unit test or a functional test. Don’t fight with others about whether you should test private methods or not. Stop worrying about whether you should hit the database in tests or not.不要太担心测试是集成测试还是端到端测试、单元测试还是功能测试。不要与其他人争论是否应该测试私有方法。不要再担心是否应该在测试中访问数据库。

Instead write tests that tell you the system is working the way it should. Ideally with 3 keystrokes and in less than 1 second.而是编写测试来告诉您系统正在以应有的方式工作。理想情况下，只需 3 次击键并在不到 1 秒的时间内完成。

This one took me a long time, a lot of ultimately useless discussions, and bugs in my code to learn.这个花了我很长时间，很多最终无用的讨论，以及我的代码中的错误来学习。

Best practices are often based on the assumption that you know what the code should do最佳实践通常基于您知道代码应该做什么的假设

If you know exactly what you want to build then best practices and patterns can help you, by giving advice on how to build it.如果您确切地知道要构建什么，那么最佳实践和模式可以通过提供有关如何构建它的建议来帮助您。

But if you don’t know yet what the program should do, or what it will look like in four weeks, then some best practices can make things even harder.但是，如果您还不知道该程序应该做什么，或者四个星期后会是什么样子，那么一些最佳实践可能会使事情变得更加困难。

Some practices are the best when applied to a rewrite, but the worst when you’re still exploring.一些实践在应用于重写时是最好的，但在你仍在探索时是最差的。

Using other people’s code is not as good as I thought使用别人的代码并没有我想的那么好

I started my career writing Ruby and JavaScript, with package managers being available and the question “isn’t there a package that does that?” always hanging in the air.我的职业生涯开始于编写 Ruby 和 JavaScript，包管理器可用，问题是“没有一个包可以做到这一点吗？”总是悬在空中。

Common sense dictated: if you can, try to use a library instead of writing it yourself. Reuse code as much as you can. Don’t reinvent the wheel. Don’t copy & paste. That was what I believed for years.常识要求：如果可以，请尝试使用库而不是自己编写。尽可能多地重用代码。不要重新发明轮子。不要复制和粘贴。这是我多年来所相信的。

But there are downsides to that. Sometimes writing that one function yourself might actually be better than adding a dependency.但这样做也有不利之处。有时自己编写一个函数实际上可能比添加依赖项更好。

Dependencies aren’t free. You have to keep them up to date. They increase your compile or loading times. They add strange things to your stack traces. And very often they do more than what you need them to do, which means you’re paying for more than you’re getting.依赖项不是免费的。您必须使它们保持最新状态。它们会增加您的编译或加载时间。他们在你的堆栈跟踪中添加了奇怪的东西。很多时候，他们做的比你需要他们做的多，这意味着你付出的比你得到的多。

When you’re glueing other people’s code together, there’s a very real danger that the glue is where complexity will accumulate. But glue code is the last place where you want your complexity to live. It hides complexity. What you want is to make complexity as visible as you can, shining a light on it with the hope that it turns into dust and disappears.当您将其他人的代码粘合在一起时，存在一个非常现实的危险，即粘合剂是复杂性累积的地方。但是胶水代码是您希望复杂性存在的最后一个地方。它隐藏了复杂性。你想要的是让复杂性尽可能地可见，照亮它，希望它变成灰尘并消失。

Sometimes it’s better to write it yourself than to use other people’s code.有时自己编写比使用其他人的代码要好。

Some companies get it, others don’t. But nobody’s perfect有些公司明白，有些公司不明白。但没有人是完美的

There is a big difference between developing software for a software company and developing software for a company that employs software developers because it has to. It’s a joy to work for a company in which leadership gets software and how it’s made.为软件公司开发软件和为雇用软件开发人员的公司开发软件之间存在很大差异，因为它必须这样做。为一家领导层获得软件及其制作方式的公司工作是一种乐趣。

That being said: I don’t think any company has it all figured out. Everybody’s winging it to some degree.话虽这么说：我不认为任何公司都想通了。每个人都在某种程度上推动它。

Investing in feedback loops is never wasted effort投资反馈循环绝不是浪费精力

I’ve never regretted improving a feedback loop. Faster tests, better test output, faster deploys, turning a manual feedback loop into something that gives me a signal with one keybinding.我从不后悔改进反馈循环。更快的测试，更好的测试输出，更快的部署，将手动反馈循环变成通过一个键绑定给我一个信号的东西。

Watch out, though: once you’ve seen the light of developing software with a really fast and high-signal feedback loop, you’ll long for it forever.但请注意：一旦您看到开发具有真正快速和高信号反馈循环的软件的光芒，您就会永远渴望它。

Always leave something unfinished at the end of the day总是在一天结束时留下未完成的事情

A failing test, a compiler error, a half-finished sentence – end your day with one of these and the next morning you can sit down and continue where you left off, skipping “hmm, what should I do today…” entirely.一个失败的测试、一个编译器错误、一个半成品的句子——以其中一个结束你的一天，第二天早上你可以坐下来继续你离开的地方，完全跳过“嗯，我今天应该做什么……”。

There’s nothing that gets me started as fast as a failing test that needs to pass.没有什么比需要通过的失败测试更能让我快速开始的了。

Perfectionism is a trap完美主义是个陷阱

Perfectionism is based on a lie. You’ll never get to the point where you’re done and sit and rest and say “ah, now it’s perfect”. There’ll always be something. You know it, I know it. There’s no perfect (see above). Accept it and ship and continue building.完美主义是建立在谎言之上的。你永远不会到完成的地步，坐下来休息，然后说“啊，现在完美了”。总会有事的。你知道，我知道。没有完美的（见上文）。接受它并运送并继续构建。

Aim for 80% and consider the other 20% optional. It’s freeing and gives you room to breath. You might end up at 99%, who knows?瞄准 80% 并考虑其他 20% 可选。它正在释放，让你有呼吸的空间。你最终可能会达到 99%，谁知道呢？

Sharpen the axe磨利斧头

I’ve gotten a lot out of investing in my tools: Vim, git, shells, the Unix environment, testing frameworks. I truly enjoy spending a Sunday morning with my Vim configuration.我从投资工具中获得了很多收益：Vim、git、shell、Unix 环境、测试框架。我真的很喜欢用我的 Vim 配置度过一个星期天的早晨。

But it’s possible to overdo it and get stuck in the configuration phase, doing endless tinkering. You have to use your tools to get feedback on how to best configure and use them.但也有可能过度使用它并陷入配置阶段，进行无休止的修补。您必须使用您的工具来获得有关如何最好地配置和使用它们的反馈。

Hiring is hard招聘很难

I’ve done hundreds of interviews now and the most important insight I’ve gained is that hiring is really, really hard. The verdict on an interview has so many random inputs that it makes everything between a Strong Yes and Strong No wobbly.我现在已经完成了数百次面试，我获得的最重要的见解是招聘真的非常非常难。面试的结论有很多随机输入，以至于它使“强烈是”和“强烈否”之间的一切都摇摆不定。

Often I wish there was a way to find out whether people have the get-shit-done gene.我经常希望有一种方法可以查明人们是否有“做坏事”基因。

The most important trait in developers: rolling up their sleeves because it has to get done开发人员最重要的特质：卷起袖子，因为必须完成

Here’s something that all the people I enjoyed working with have in common: they do the work. They know that some tasks aren’t fun or glamorous or interesting. But someone has to do them, so they do them.这是我喜欢与之共事的所有人的共同点：他们做的工作。他们知道有些任务并不有趣、不光彩或不有趣。但是必须有人去做，所以他们去做。

Work on a codebase with other people over a longer period of time在更长的时间内与其他人一起在代码库上工作

Nothing has helped me get better at software engineering as much as working with a group of other people on the same codebase over multiple years.多年来，没有什么比与一群其他人在同一个代码库上工作更能帮助我在软件工程方面做得更好了。

You’ll see how decisions play out.你会看到决策如何发挥作用。

You’ll see what ended up mattering and what didn’t.你会看到什么最终重要，什么不重要。

You’ll see how extensible your code truly is when your colleague tries to modify it 3 years after you wrote it.当您的同事在您编写代码 3 年后尝试对其进行修改时，您将看到代码的真正可扩展性。

You’ll see whether your prediction of “we have 2 of these now, but I’m sure there’ll be 5 in the future” will come true or not and can take the outcome into account when doing other predictions.你会看到你的“我们现在有 2 个，但我相信将来会有 5 个”的预测是否会成真，并且在做其他预测时可以考虑结果。

You’ll regret writing some code and you’ll be happy that you wrote some other code. You’ll learn from reflecting on the difference between the two.你会后悔写了一些代码，你会很高兴你写了一些其他的代码。您将从反思两者之间的差异中学习。

You’ll see tooling break down just because something somewhere changed and you had nothing to do with it but you still have to fix it.你会看到工具崩溃只是因为某处发生了变化，而你与它无关，但你仍然必须修复它。

You’ll say “I’ve never had to think about this in 3 years” about some pieces of software and cherish them.对于一些软件，你会说“我在 3 年里从来没有想过这个”并珍惜它们。

You’ll see what parts of the codebase new colleagues struggle to understand and which parts they immediately get productive in.您将看到新同事难以理解代码库的哪些部分，以及他们立即在哪些部分中发挥作用。

You’ll see what the code you wrote looks like 4 years later.你会看到 4 年后你写的代码是什么样子的。

Knowing the full stack了解全栈

There’s few things as motivating to me as hearing “you don’t really need to know how it works…”没有什么比听到“你真的不需要知道它是如何工作的……”更能激励我的了。

Sure, I might not need to, but I wouldn’t do the work I do today if I hadn’t tried to find out how a GC works, or how Unix works, or how multi-threading works, or how a database stores data, or how interpreters and compilers work.当然，我可能不需要，但如果我没有尝试了解 GC 是如何工作的，或者 Unix 是如何工作的，或者多线程是如何工作的，或者数据库是如何存储的，我就不会做我今天所做的工作数据，或解释器和编译器的工作方式。

It benefits the work I do, too. I can make better technical decisions by being able to weigh trade-offs more accurately, knowing what goes on under the hood.它也有利于我所做的工作。通过更准确地权衡取舍，我可以做出更好的技术决策，了解幕后发生的事情。

Typing can be the bottleneck打字可能是瓶颈

I’ve said it before. Don’t let typing be the bottleneck.我以前说过。不要让打字成为瓶颈。

Code reviews aren’t waterproof代码审查不是防水的

For the longest time I assumed it’s my fault when a bug made it through one of my code reviews. I missed that! How could I have missed that? It’s so obvious!很长一段时间以来，我都认为我的一个代码审查中出现了一个错误是我的错。我错过了！我怎么会错过呢？太明显了！

Later I found out that it’s not just me: other people miss bugs in code reviews too. In fact, they accept and freely talk about how code reviews aren’t infallible. I was relieved.后来我发现不仅仅是我：其他人也错过了代码审查中的错误。事实上，他们接受并自由地谈论代码审查如何不是万无一失的。我松了一口气。

It changed how I see code reviews: as something imperfect, something that needs to be combined with other ways to verify the code.它改变了我对代码审查的看法：作为不完美的东西，需要结合其他方式来验证代码的东西。

Not every code review is worth the effort并非每一次代码审查都值得付出努力

Not every code needs a really thorough review. Sometimes, if the risk is acceptable, it’s fine to drop a quick “LGTM!”. It unblocks your colleagues, keeps momentum and, somehow, builds trust.并非每个代码都需要真正彻底的审查。有时，如果风险是可以接受的，那么快速放弃“LGTM！”就可以了。它可以让您的同事畅通无阻，保持动力，并以某种方式建立信任。

Negativity begets negativity消极导致消极

The more you give in to negativity, the more you get. Always much more than you wanted.你越是向消极屈服，你得到的就越多。总是比你想要的多得多。

It’s viral. It starts with snark, it turns into cynicism, it then morphs into “everything sucks”. Soon after, the question of “why even bother?” starts to attach itself to everything. It ends with people hiding excitement and joy and ideas from you.这是病毒式的。它从蛇蝎美人开始，变成玩世不恭，然后演变成“一切都糟透了”。不久之后，“为什么还要打扰？”的问题。开始依附于一切。它以人们向你隐藏兴奋、快乐和想法而告终。

Being negative is too easy. At a certain point I realised that pointing at things and saying what’s bad about them and shrugging because, well, didn’t I expect this to be bad (everything’s bad, right?) - that’s easy. Easy to do and easy to mistake for an engineering mindset that can spot deficiencies and worst cases (which it is not).消极太容易了。在某个时刻，我意识到指向事物并说出它们的坏处并耸耸肩，因为，好吧，我没想到这会很糟糕（一切都很糟糕，对吗？） - 这很容易。容易做也容易被误认为是一种可以发现缺陷和最坏情况（事实并非如此）的工程思维方式。

What’s hard is seeing things for what they could be, what’s beautiful about them. Encouraging ideas even when they’re barely something to talk about. Creating and fostering joy. That’s challenging.很难看到事物的本来面目，事物的美丽之处。鼓励想法，即使它们几乎没有什么可谈论的。创造和培养快乐。这很有挑战性。

So at some point I decided I had enough and tried to do the challenging thing. So far it’s served me well.所以在某个时候，我决定我已经受够了，并尝试做具有挑战性的事情。到目前为止，它对我很有帮助。

Every dial at 100% all the time doesn’t work每次拨到 100% 都不行

I can’t do everything equally well all the time. I can’t write a book and make progress in my career and be a great father and set PRs in the gym and read two books. It won’t work for more than one or two weeks. It’s not sustainable.我不能一直把所有事情都做得一样好。我不能写一本书，不能在事业上取得进步，不能成为一个伟大的父亲，不能在健身房里设置公关，读两本书。它不会工作超过一两个星期。这是不可持续的。

Now I let my interests take turns: when I want to make progress on a specific thing, I focus on that for a while and accept that the other things have to go into maintenance mode.现在我让我的兴趣轮流了：当我想在一个特定的事情上取得进展时，我会专注于它一段时间，并接受其他事情必须进入维护模式。

Code has mass代码有质量

Code has mass. Every additional line of code you don’t need is ballast. It weighs your codebase down, making it harder to steer and change direction if you need to. The less code you need, the better.代码有质量。您不需要的每一行额外代码都是镇流器。它会降低您的代码库的重量，使您在需要时更难控制和改变方向。您需要的代码越少越好。

Code has to be read, it has to be tested, it has to be kept compatible, it has to stay secure, it has to keep working. Even if it’s not doing any useful work. It doesn’t hurt having it around, does it? Yes, it does. Delete it and move on. If necessary, restore from version control.代码必须被阅读，它必须被测试，它必须保持兼容，它必须保持安全，它必须继续工作。即使它没有做任何有用的工作。拥有它并没有什么坏处，不是吗？是的，它确实。删除它并继续。如有必要，从版本控制中恢复。

The same is true for tests, which I’ve only learned too late.测试也是如此，我只是学得太晚了。

Programming as a part of my life编程是我生活的一部分

Ever since I started as an intern I spent a considerable amount of time outside of work on programming: reading technical books, writing books, working on sideprojects, writing blog posts, giving talks, traveling to conferences, learning new languages and tools.自从我开始实习以来，我在编程之外花费了大量时间：阅读技术书籍、撰写书籍、从事业余项目、撰写博客文章、发表演讲、参加会议、学习新的语言和工具。

That some companies don’t care about your college degree if you can demonstrate that you’re really good at programming was fuel for me for years.如果你能证明你真的很擅长编程，那么一些公司就不关心你的大学学位，这对我来说是多年的动力。

I enjoy spending time on programming outside of work, but not all the time. Some of it feels like work. It takes effort to read some technical books. But some things don’t have to feel good while you’re doing them.我喜欢在工作之外花时间在编程上，但并非一直如此。有些感觉像是工作。阅读一些技术书籍需要努力。但是有些事情在你做的时候并不一定要让你感觉很好。

My career would be completely different if I had only programmed and learned about programming at my day job.如果我只在日常工作中编程并学习编程，我的职业生涯将完全不同。

Computers are fast电脑速度很快

Building web applications made me think that 100ms is fast and that 50ms is really fast. Writing a compiler has taught me that 1ms is an eternity for a modern computer.构建 Web 应用程序让我觉得 100 毫秒很快，而 50 毫秒真的很快。编写编译器告诉我，1ms 对于现代计算机来说是永恒的。

I still love programming very much我仍然非常喜欢编程

Some of what I wrote can be interpreted as me having grown cynical over the years. I mean: nothing matters and perfection is unachievable? Come on.我写的一些内容可以解释为我多年来变得愤世嫉俗。我的意思是：什么都不重要，完美是无法实现的？来吧。

But it’s the opposite. I still care. I care very much. But I care about fewer things and I still love programming very much.但事实恰恰相反。我还是在乎。我非常关心。但我关心的事情更少，我仍然非常喜欢编程。