<img attachment="matrix.webp" align="right">The article <a href="https://endler.dev/2025/best-programmers/" author="Matthias Endler" source="">The Best Programmers I Know</a> seems almost too good to be true. NGL I feel seen. I have cited heavily from it, highlighting the parts I find especially interesting. At the end are a few pallid notes from me, but the meat of this article is the quote. <bq><ul>Read the Reference Know Your Tools Really Well Read The Error Message <div>Break Down Problems If you work as a professional developer, that is the bulk of the work you get paid to do: breaking down problems. <b>If you do it right, it will feel like cheating: you just solve simple problems until you’re done.</b> </div> <div>Don’t Be Afraid To Get Your Hands Dirty [...] read a lot of code and they are not afraid to touch it. They <b>never say “that’s not for me” or “I can’t help you here.”</b> Instead, they just start and learn. Code is just code. They can just <b>pick up any skill that is required with time and effort.</b> Before you know it, <b>they become the go-to person in the team for whatever they touched.</b> Mostly because they were the only ones who were not afraid to touch it in the first place. </div> <div>Always Help Others Great engineers are in high demand and are always busy, but <b>they always try to help.</b> That’s because they are <b>naturally curious and their supportive mind is what made them great engineers in the first place.</b> It’s a sheer joy to have them on your team, because <b>they are problem solvers.</b> </div> <div>Write <b>Most awesome engineers are well-spoken and happy to share knowledge.</b> The best have <b>some outlet for their thoughts: blogs</b>, talks, open source, or a combination of those. I think there is a <b>strong correlation between writing skills and programming.</b> All the best engineers I know have <b>good command over at least one human language – often more.</b> 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. <b>Excellent programmers find joy in playing with words.</b> </div> <div>Never Stop Learning <b>If there is a new tool they haven’t tried or a language they like, they will learn it.</b> This way, they always stay on top of things [...] <b>the best engineers don’t follow trends, but they will always carefully evaluate the benefits of new technology.</b> If they dismiss it, they can tell you exactly <i>why</i>, when the technology would be a good choice, and what the alternatives are. </div> Have Patience <div>Never Blame the Computer <b>No matter how erratic or mischievous the behavior of a computer seems, there is <i>always</i> a logical explanation</b>: 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. <b>When you mistake bugs for incomprehensible magic, magic is what it will always be.</b> </div> <div>Don’t Be Afraid to Say “I Don’t Know” <b>The best candidates said “Huh, I don’t know, but that’s an interesting question! If I had to guess, I would say…”</b> and then they would proceed to deduce the answer. That’s a sign that you have the potential to be a great engineer. </div> <div>Keep It Simple Clever engineers write clever code. <b>Exceptional engineers write simple code.</b> That’s because most of the time, <b>simple is enough. And simple is more maintainable</b> than complex.</div></ul></bq> I disagree with the <iq>Don’t Guess</iq> one, in that I think "guessing"---forming a hypothesis---is the crux of scientific investigation. I think what the author probably meant was to "don't leave a guess unproven." An addendum to the "magic" one above is that you should also know when to cut bait, i.e., when it's not worth anyone's time to find out what the real reason was. This can happen in one-off scripts, or in tight-deadline situations. Sometimes, you have to back-burner an investigation and either never bring it back to the front burner or learn the lesson at a later time. But, yes, every problem solved is a bit of experience. It's all worth it. A couple of decades of doing that and you might really have something.