Advice for new software devs who've read all those other advice essays

Trusting Advice & “Experts”

• Many comments echo the essay’s point: people are followed because they write or speak well, not because they’re right.
• This applies to blog posts, books, YouTube, and even LLM outputs; confident presentation ≠ correctness.
• Several urge skepticism without cynicism: understand the reasoning and the “horror story” behind any best practice (Chesterton’s Fence analogy).

Software, Business Value, and Sales

• One recurring debate: “software never makes money, only sales does.”
  • Supporters say software is a cost center and profit comes from transactions and customer acquisition.
  • Critics counter that software creates value that is sold or rented; in many firms, software clearly drives revenue and developer compensation reflects this.
• Consensus nuance: business context matters; tech exists to serve the business, but undervaluing engineering leads to poor outcomes and eventual attrition.

Purpose of Software

• A strong claim appears: “the only purpose of software is automation.”
  • Supporters extend this even to video games as automated rule enforcement.
  • Opponents cite games, art, and non-automation uses as valid purposes; they view this as dogmatic overreach.

Job of a Developer

• Popular theme: your real job is solving business/user problems, not “writing code” or “writing Slack messages.”
• Some argue this is rhetorical exaggeration; it is often your job to write code, but the focus should be on solving the right problem, sometimes by not adding more code.

Docs, Specs, and Source Code

• One camp advocates reading documentation “cover to cover” and studying source of key tools; claims this yields long-term speed and “map awareness.”
• Large pushback:
  • Modern specs/libs are thousands of pages; impossible to read or retain fully.
  • People have different learning styles; many prefer iterative, problem-driven reading or skimming tables of contents.
  • Suggested compromise: deeply learn a small core toolset, skim broadly, and know “where to look” later.

Simplicity vs Complexity & the “Right Way”

• Strong support for “don’t make things more complicated than necessary” (KISS).
  • Critiques of over-abstraction, premature generalization, and elaborate frameworks for tiny projects.
  • Stories of “Right Way Guys” who enforce factories/builders/ORMs/staging for trivial code, or huge in-house frameworks as job security.
• Counterpoint: small side projects can be a safe place to practice “proper” infra and tooling; what looks like overkill may be deliberate learning.

Code Quality, Maintainability, and Excellence

• Many prefer “clear, working code that’s easy to debug” over “clever” or “excellent” code.
• Disagreement on “excellence”:
  • Some say it’s real but dangerous (hubris, over-engineering).
  • Others argue dismissing excellence is embracing mediocrity; the key is to target working, maintainable solutions, not ego.

Debugging, Reading Code, and Tools

• Multiple comments praise a certain debugging book and emphasize debugging as a core professional skill.
• Advice: learn to read code well (including stepping through it), not just write it.
  • One view: debuggers are a powerful learning tool, like exercises in a textbook.
  • Another view: over-reliance on debuggers is a crutch; senior engineers should reason about code without always executing it.

Collaboration, Reviews, and Humility

• Code reviews are seen as high-leverage: they improve code, teach reading skills, and surface design issues.
• Advice to juniors:
  • Drop the ego, accept direct criticism, ask questions, and admit mistakes early.
  • Understand that “best practices” and architectural decisions are contextual; seniors may be right for non-obvious reasons.

Health, Walks, and Cognitive Load

• The “take walks” advice resonates strongly.
  • People report walks or simply staring at a pond as powerful for debugging mentally and coping with stress.
• Broader point: manage “state” in your head; externalize via notes/wikis and protect your energy (avoiding unnecessary complexity).