The Best Programmers I Know | Matthias Endler
原文链接
https://endler.dev/2025/best-programmers/
创建时间
12 个月前
原文
The Best Programmers I Know | Matthias Endler
Tagged with
I have met a lot of developers in my life. Lately, I asked myself: “What does it take to be one of the best? What do they all have in common?”
In the hope that this will be an inspiration to someone out there, I wrote down the traits I observed in the most exceptional people in our craft. I wish I had that list when I was starting out. Had I followed this path, it would have saved me a lot of time.
Read the Reference
If there was one thing that I should have done as a young programmer, it would have been to read the reference of the thing I was using. I.e. read the Apache Webserver Documentation, the Python Standard Library, or the TOML spec.
Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written.
Know Your Tools Really Well
Great devs understand the technologies they use on a fundamental level.
It’s one thing to be able to use a tool and a whole other thing to truly grok (understand) it. A mere user will fumble around, get confused easily, hold it wrong and not optimize the config.
An expert goes in (after reading the reference!) and sits down to write a config for the tool of which they understand every single line and can explain it to a colleague. That leaves no room for doubt!
To know a tool well, you have to know:
- its history: who created it? Why? To solve which problem?
- its present: who maintains it? Where do they work? On what?
- its limitations: when is the tool not a good fit? When does it break?
- its ecosystem: what libraries exist? Who uses it? What plugins?
For example, if you are a backend engineer and you make heavy use of Kafka, I expect you to know a lot about Kafka – not just things you read on Reddit. At least that’s what I expect if you want to be one of the best engineers.
Read The Error Message
As in Really Read the Error Message and Try to Understand What’s Written. Turns out, if you just sit and meditate about the error message, it starts to speak to you. The best engineers can infer a ton of information from very little context. Just by reading the error message, you can fix most of the problems on your own.
It also feels like a superpower if you help someone who doesn’t have that skill. Like “reading from a cup” or so.
Break Down Problems
Everyone gets stuck at times. The best know how to get unstuck. They simplify problems until they become digestible. That’s a hard skill to learn and requires a ton of experience. Alternatively, you just have awesome problem-solving skills, e.g., you’re clever. If not, you can train it, but there is no way around breaking down hard problems. There are problems in this world that are too hard to solve at once for anyone involved.
If you work as a professional developer, that is the bulk of the work you get paid to do: breaking down problems. If you do it right, it will feel like cheating: you just solve simple problems until you’re done.
Don’t Be Afraid To Get Your Hands Dirty
The best devs I know read a lot of code and they are not afraid to touch it. They never say “that’s not for me” or “I can’t help you here.” Instead, they just start and learn. Code is just code. They can just pick up any skill that is required with time and effort. Before you know it, they become the go-to person in the team for whatever they touched. Mostly because they were the only ones who were not afraid to touch it in the first place.
Always Help Others
A related point. Great engineers are in high demand and are always busy, but they always try to help. That’s because they are naturally curious and their supportive mind is what made them great engineers in the first place. It’s a sheer joy to have them on your team, because they are problem solvers.
Write
Most awesome engineers are well-spoken and happy to share knowledge.
The best have some outlet for their thoughts: blogs, talks, open source, or a combination of those.
I think there is a strong correlation between writing skills and programming. All the best engineers I know have good command over at least one human language – often more. Mastering the way you write is mastering the way you think and vice versa. A person’s writing style says so much about the way they think. If it’s confusing and lacks structure, their coding style will be too. If it’s concise, educational, well-structured, and witty at times, their code will be too.
Excellent programmers find joy in playing with words.
Never Stop Learning
Some of the best devs I know are 60+ years old. They can run circles around me. Part of the reason is that they keep learning. If there is a new tool they haven’t tried or a language they like, they will learn it. This way, they always stay on top of things without much effort.
That is not to be taken for granted: a lot of people stop learning really quickly after they graduate from University or start in their first job. They get stuck thinking that what they got taught in school is the “right” way to do things. Everything new is bad and not worth their time. So there are 25-year-olds who are “mentally retired” and 68-year-olds who are still fresh in their mind. I try to one day belong to the latter group.
Somewhat related, the best engineers don’t follow trends, but they will always carefully evaluate the benefits of new technology. If they dismiss it, they can tell you exactly why, when the technology would be a good choice, and what the alternatives are.
Status Doesn’t Matter
The best devs talk to principal engineers and junior devs alike. There is no hierarchy. They try to learn from everyone, young and old. The newcomers often aren’t entrenched in office politics yet and still have a fresh mind. They don’t know why things are hard and so they propose creative solutions. Maybe the obstacles from the past are no more, which makes these people a great source of inspiration.
Build a Reputation
You can be a solid engineer if you do good work, but you can only be one of the best if you’re known for your good work; at least within a (larger) organization.
There are many ways to build a reputation for yourself:
- You built and shipped a critical service for a (larger) org.
- You wrote a famous tool
- You contribute to a popular open source tool
- You wrote a book that is often mentioned
Why do I think it is important to be known for your work? All of the above are ways to extend your radius of impact in the community. Famous developers impact way more people than non-famous developers. There’s only so much code you can write. If you want to “scale” your impact, you have to become a thought leader.
Building a reputation is a long-term goal. It doesn’t happen overnight, nor does it have to. And it won’t happen by accident. You show up every day and do the work. Over time, the work will speak for itself. More people will trust you and your work and they will want to work with you. You will work on more prestigious projects and the circle will grow.
I once heard about this idea that your latest work should overshadow everything you did before. That’s a good sign that you are on the right track.
Have Patience
You need patience with computers and humans. Especially with yourself. Not everything will work right away and people take time to learn. It’s not that people around you are stupid; they just have incomplete information. Without patience, it will feel like the world is against you and everyone around you is just incompetent. That’s a miserable place to be. You’re too clever for your own good.
To be one of the best, you need an incredible amount of patience, focus, and dedication. You can’t afford to get distracted easily if you want to solve hard problems. You have to return to the keyboard to get over it. You have to put in the work to push a project over the finishing line. And if you can do so while not being an arrogant prick, that’s even better. That’s what separates the best from the rest.
Never Blame the Computer
Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs.
The best devs don’t.
No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet!
The best keep digging until they find the reason. They might not find the reason immediately, they might never find it, but they never blame external circumstances.
With this attitude, they are able to make incredible progress and learn things that others fail to. When you mistake bugs for incomprehensible magic, magic is what it will always be.
Don’t Be Afraid to Say “I Don’t Know”
In job interviews, I pushed candidates hard to at least say “I don’t know” once. The reason was not that I wanted to look superior (although some people certainly had that impression). No, I wanted to reach the boundary of their knowledge. I wanted to stand with them on the edge of what they thought they knew. Often, I myself didn’t know the answer. And to be honest, I didn’t care about the answer. What I cared about was when people bullshitted their way through the interview.
The best candidates said “Huh, I don’t know, but that’s an interesting question! If I had to guess, I would say…” and then they would proceed to deduce the answer. That’s a sign that you have the potential to be a great engineer.
If you are afraid to say “I don’t know”, you come from a position of hubris or defensiveness. I don’t like bullshitters on my team. Better to acknowledge that you can’t know everything. Once you accept that, you allow yourself to learn. “The important thing is that you don’t stop asking questions,” said Albert Einstein.
Don’t Guess
“In the Face of Ambiguity, Refuse the Temptation to Guess” That is one of my favorite rules in PEP 20 – The Zen of Python.
And it’s so, so tempting to guess!
I’ve been there many times and I failed with my own ambition.
When you guess, two things can happen:
- In the best case you’re wrong and your incorrect assumptions lead to a bug.
- In the worst case you are right… and you’ll never stop and second guess yourself. You build up your mental model based on the wrong assumptions. This can haunt you for a long time.
Again, resist the urge to guess. Ask questions, read the reference, use a debugger, be thorough. Do what it takes to get the answer.
Keep It Simple
Clever engineers write clever code. Exceptional engineers write simple code.
That’s because most of the time, simple is enough. And simple is more maintainable than complex. Sometimes it does matter to get things right, but knowing the difference is what separates the best from the rest.
You can achieve a whole lot by keeping it simple. Focus on the right things.
Final Thoughts
The above is not a checklist or a competition; and great engineering is not a race.
Just don’t trick yourself into thinking that you can skip the hard work. There is no shortcut. Good luck with your journey.
Thanks for reading! I mostly write about Rust and my (open-source) projects. If you would like to receive future posts automatically, you can subscribe via RSS.
Submit to HN Sponsor me on Github My Amazon wish list
译文
我所认识的优秀程序员 | Matthias Endler
我一生中遇到过很多开发者。最近，我问自己：“要成为其中最优秀的一员，需要具备什么条件？他们都有哪些共同点？”
我希望这篇文章能给读者带来一些启发，因此我写下了我在那些卓越的程序员身上观察到的特质。如果我一开始就有这份清单就好了。如果我遵循这条道路，就能节省很多时间。
阅读参考文档
如果说我年轻时应该做的一件事，那就是 阅读我所使用的工具的参考文档 。例如，阅读 Apache Web 服务器文档 、 Python 标准库 或 TOML 规范 。
别去 Stack Overflow，别问大语言模型，别瞎 猜 ，直接看 官方文档 ！你会发现，它们通常写得很好，而且比你想象的更容易理解。
从根本上理解你的工具
优秀的开发者从 根本上 理解他们使用的技术。
只会 使用 工具是一回事，真正 理解 (grok)它又是另一回事。如果只是会用，那就会摸索不定，容易困惑，用不对方法，也优化不了配置。
而专家（在阅读参考文档后！）会深入研究，坐下来为工具编写配置，理解每一行代码，并且能给同事解释得明明白白。这样一来，所有问题都能迎刃而解！
要深入了解一个工具，你必须知道：
- 历史：谁创造的？为什么？为了解决什么问题？
- 现状：谁在维护？在哪里工作？在做什么？
- 局限性：什么时候不适用？什么时候会崩溃？
- 生态系统：有哪些库？谁在使用？有哪些插件？
例如，如果你是一名后端工程师，并且大量使用 Kafka，我希望你对 Kafka 有很多了解，而不仅仅是你从 Reddit 上看到的东西。至少如果你想成为最优秀的工程师之一，我希望你做到这一点。
阅读错误信息
认真阅读错误信息，并尝试理解其中的内容 。你会发现，只要静下心来仔细阅读错误信息，它就会给你提供线索。优秀的工程师能从极少的上下文中推断出大量信息，甚至只靠阅读错误信息就能自己解决大部分问题。
如果你能帮助那些不具备这种技能的人，会感觉自己就像拥有了超能力一样。
分解问题
最优秀的程序员知道如何走出困境。他们会把复杂的问题拆解成容易理解的小块，化繁为简。这需要丰富的经验才能掌握，当然，如果你天生就很聪明，那就另当别论了。
如果你是一名专业开发者，那么分解问题就是你获得报酬的主要工作。如果你做得对，你会觉得像作弊一样：你只是在解决简单的问题，直到完成任务。
不要害怕弄脏双手
我认识的优秀的开发者会阅读大量的代码，并且不害怕修改代码。他们从不说“那不适合我”或“我在这里帮不了你”。相反，他们直接开始学习。代码嘛， 说到底就是代码 。他们可以随着时间和努力掌握任何需要的技能。在你意识到之前，他们就会成为团队中任何他们接触过的事情的负责人。主要是因为他们是唯一一个从一开始就不害怕接触它的人。
乐于助人
这一点也和上面说的有关。优秀的工程师非常抢手，而且总是很忙，但他们总是尽力帮助别人。这是因为他们天生好奇，而且他们乐于助人的心态正是他们成为优秀工程师的原因。团队中有他们是一件非常快乐的事情，因为他们是问题解决者。
写作
大多数出色的工程师都乐于健谈和分享知识。
最优秀的工程师会通过某种渠道来表达他们的想法：博客、演讲、开源项目，或者这些方式的结合。
我认为写作能力和编程能力之间存在很强的关联性。我认识的所有优秀的工程师都至少精通一门人类语言——通常不止一门。掌握写作方式就是掌握思考方式，反之亦然。一个人的写作风格可以反映出他们的思考方式。如果写作风格混乱且缺乏结构，那么他们的编码风格也会如此。如果写作风格简洁、有教育意义、结构良好，并且偶尔带点幽默，那么他们的代码也会如此。
优秀的程序员会从玩弄文字中获得乐趣。
终身学习
我认识一些非常厉害的开发者，都已经六十多岁了，但技术水平仍然能轻松碾压我。这很大程度上归功于他们坚持学习。如果有他们没有尝试过的新工具或他们喜欢的语言，他们就会去学习。这样，他们总是能毫不费力地掌握最新的技术。
这是不应该被认为理所当然的：很多人在大学毕业或开始第一份工作后很快就停止了学习。他们固执地认为他们在学校学到的东西是做事的“正确”方式。所有的新事物都是不好的，不值得他们花时间。所以，有的人25岁就“提前养老”了，而有的人68岁仍然思维敏捷。我希望自己将来能成为后者。
与此有些相关的是，优秀的工程师不会追随潮流，但他们总是会仔细评估新技术的优势。如果他们不采纳某项技术，他们可以准确地告诉你 为什么 ，什么时候这项技术会是一个好的选择，以及有哪些替代方案。
头衔不重要
优秀的开发者与首席工程师和初级开发者都能平等地交谈。没有等级之分。他们尝试向所有人学习，无论年长还是年轻。新人通常还没有陷入办公室政治，并且仍然有新鲜的想法。他们不知道为什么事情会 很困难 ，因此他们会提出创造性的解决方案。也许过去的障碍已经不复存在，这使得这些人成为灵感的重要来源。
建立声誉
光 做 得好还不够，要让你的工作 被大家看到 ，你才能成为顶尖的工程师——至少在（较大的）组织内是这样。
有很多方法可以为自己建立声誉：
- 你为一个（较大的）组织构建并交付了一项关键服务。
- 你编写了一个著名的工具
- 你为一个流行的开源工具做出了贡献
- 你写了一本经常被提及的书
为什么我认为你的工作为人所知很重要？以上所有这些都是扩大你在社区中影响范围的方式。著名的开发者比不著名的开发者影响更多的人。你能编写的代码是有限的。如果你想“扩大”你的影响力，你必须成为一位思想领袖。
建立声誉是一个长期的目标。它不会一蹴而就，也不必如此。而且它不会偶然发生。你每天都出现并完成工作。随着时间的推移，工作会为自己说话。更多的人会信任你和你的工作，他们会想与你合作。你将参与更负盛名的项目，这个圈子会越来越大。
我曾经听说过这样一种观点，即你最新的工作应该超越你之前所做的一切。这是一个你走在正确道路上的好兆头。
保持耐心
你需要对计算机和人类都保持耐心。尤其是对自己。不是所有事情都会立即奏效，人们需要时间来学习。不是你周围的人很愚蠢；他们只是掌握的信息不完整。没有耐心，你会觉得世界与你作对，你周围的每个人都很无能。那是一个痛苦的地方。你太聪明了，以至于聪明反被聪明误。
要成为最优秀的程序员之一，你需要惊人的耐心、专注和奉献精神。如果你想解决难题，你就不能轻易分心。你必须回到键盘前才能克服困难。你必须努力工作才能将项目推过终点线。如果你能做到这一点，同时又保持谦逊，那就更好了。这就是区分最优秀和其余人的地方。
永远不要责怪计算机
大多数开发者会将那些不稳定的、看似“随机”的 bug 归咎于软件、其他人、他们的狗或天气。
最优秀的开发者不会这样做。
无论计算机的行为看起来多么古怪或恶作剧，总会有一个合理的解释：你只是还没有找到它！
最优秀的开发者会不断挖掘，直到找到原因。他们可能不会立即找到原因，他们可能永远找不到原因，但他们永远不会责怪外部环境。
有了这种态度，他们能够取得令人难以置信的进步，并学习到其他人无法学习的东西。当你把 bug 误认为是难以理解的魔法时，它将永远是魔法。
不要害怕说“我不知道”
在面试中，我会努力让候选人至少说一次“我不知道”。原因不是我想显得高人一等（尽管有些人肯定有这种印象）。不，我想触及他们知识的边界。我想和他们一起站在他们认为自己知道的边缘。通常，我自己也不知道答案。老实说，我并不关心答案。我关心的是人们在面试中胡说八道。
优秀的候选人会说“嗯，我不知道，但这是一个有趣的问题！如果我必须猜测，我会说……”然后他们会开始推导答案。这是一个你有可能成为一名伟大工程师的标志。
如果你害怕说“我不知道”，那么你就是出于傲慢或防御的立场。我不喜欢我的团队里有吹牛者。最好承认你不可能知道一切。一旦你接受了这一点，你就会允许自己学习。“最重要的是不要停止提问，”阿尔伯特·爱因斯坦说。
不要猜测
“面对模棱两可，拒绝猜测的诱惑”这是 PEP 20 – Python 之禅 中我最喜欢的规则之一。
而且，猜测是如此的诱人！
我经历过很多次，并且因为自己的野心而失败。
当你猜测时，可能会发生两种情况：
- 在 最好的情况下 ，你是错的，你错误的假设会导致一个 bug。
- 在 最坏的情况下 ，你是对的……但你永远不会停止并反思自己。你会在错误的假设基础上建立你的心智模型。这会长期困扰你。
再次强调，抵制猜测的冲动。提出问题，阅读参考文档，使用调试器，做到彻底。尽一切努力找到答案。
保持简单
聪明的工程师编写聪明的代码。卓越的工程师编写简单的代码。
这是因为在大多数情况下，简单就足够了。而且简单比复杂更容易维护。有时候，把事情做对确实很重要，但知道其中的区别才是区分最优秀和其余人的地方。
通过保持简单，你可以取得很大的成就。专注于正确的事情。
最后的想法
以上不是一个清单或一场竞赛；伟大的工程也不是一场赛跑。
所以，别想着能跳过努力就能成功，这世上没有捷径可走。祝你旅途顺利。
感谢阅读！我主要写关于 Rust 和我的（开源）项目。如果你想自动接收未来的文章，你可以通过 RSS 订阅。
提交到 Hacker News | Github 赞助 | 我的亚马逊愿望清单
本内容由 文润 转译引擎生成