The best programmers I know

Guessing, hypotheses, and time trade‑offs

• Many disagree with a blanket “don’t guess”: in most non‑safety‑critical work, making educated guesses and quickly testing them is seen as essential to avoid paralysis.
• Several distinguish “blind guessing” from forming hypotheses based on mental models, then validating with tests, logs, debuggers, etc.
• A recurring idea: the real skill is knowing where on the “analysis ↔ speed” slider to sit for a given decision, and when guesses are reversible and low‑risk.

Reading docs, source, and error messages

• Strong support for “read the reference” and “read the error message”; many note that beginners often speculate or ask others instead of checking straightforward diagnostics.
• Others say documentation quality varies greatly; for many tools, examples, blog posts, or source code are more effective than dry references.
• Some advocate browsing documentation and release notes for tools used daily, to discover capabilities you wouldn’t know to ask about.

LLMs, Stack Overflow, and learning

• Thread is split on “don’t ask the LLM / Stack Overflow”:
  • Supporters say over‑reliance produces shallow, fragmented understanding and discourages exploration.
  • Critics use LLMs as “semantic search” for terminology, pointing to official docs, summarizing large, messy sources, or as a way to debug cryptic errors.
• Several emphasize that how you use AI matters: precise questions + skepticism can accelerate learning; copy‑paste “vibe coding” is seen as harmful.

Collaboration, status, and communication

• Praised: talking to both juniors and seniors, valuing fresh perspectives, and questioning entrenched practices and unexplained rules.
• On “status doesn’t matter”: some argue low ego often reflects already‑recognized excellence; those obsessed with status are likened to “silver medalists” anxious about their place.
• Writing (docs, blog posts, teaching) is framed as both a learning tool and a hallmark of strong engineers.

Business/domain impact vs pure craft

• Multiple comments note the article focuses on “best programmers,” not “people best at having business impact.”
• Some argue that understanding the business domain and aligning technology to it is what gets people promoted to senior/staff/lead roles; others defend treating software purely as a craft done for intrinsic satisfaction.

Tools, frameworks, and blame

• “Never blame the computer” is mostly read as “don’t stop at complaining; dig to root causes,” though some warn that a culture that dismisses tool criticism as “whining” can entrench bad tech.
• There’s an extended debate on avoiding fragile libraries/frameworks versus the cost and risk of “roll your own,” especially for non‑critical CRUD systems.

Focus, mindset, and mastery vs “good enough”

• Beyond technical habits, commenters highlight focus, emotional regulation, and avoiding distraction as key differentiators between similarly skilled developers.
• Some stress that not everyone is aiming for “mastery”; for founders or generalists, “good enough to ship and solve problems” can be a more appropriate goal.

Meta: hosting and irony

• The article repeatedly hit Cloudflare Worker rate limits, spawning discussion about over‑engineering static blogs with compute‑bound infrastructure and the trade‑off between personal tinkering and robustness.