Ask HN: How can I grow as an engineer without good seniors to learn from?

Is the current job a good place to grow?

  • Many argue a fresh grad acting as “tech lead” with no seniors is risky: high responsibility, unknown unknowns, potential to cement bad habits and become an “expert beginner.”
  • Several recommend moving within 1–2 years to a medium-sized / established tech org or good consulting shop with real teams, code review, and mentorship.
  • Others see the role as a rare opportunity: early ownership, direct access to leadership, broad autonomy, and fast growth in leadership and decision-making. Advice: treat it as a springboard, but don’t stay so long that you plateau or get stuck.

Mentors, peers, and substitutes

  • Strong consensus that having more experienced people to ask questions and get feedback from accelerates growth and exposes unknown unknowns.
  • However, high-caliber “Yoda” teams are rare; many seniors are mediocre or dogmatic.
  • Suggested substitutes: meetups, user groups, Discord/Reddit/Stack Overflow, conferences, industry societies, networking into informal mentors, or hiring senior contractors/consultants for reviews.

Self-directed technical learning

  • Recurrent themes:
    • Read widely (books, docs, tech blogs, classic texts on design, data, architecture).
    • Build side projects and “breakable toys,” including nontrivial ones.
    • Contribute to open source to get real code review and see mature codebases; some note OSS feedback can be slow and uneven.
    • Read other people’s code extensively, not just write your own.
    • Keep a tech journal, decision logs, and revisit old work to see what you’d change.
    • Learn how you personally learn (practice, spaced repetition, teaching others).

AI, tools, and “industry standards”

  • Opinions on LLMs are split:
    • Some treat ChatGPT/Claude/Cursor as powerful reviewers, design sounding boards, and questioning partners.
    • Others warn against using them for code review or deep design; they can confidently suggest subtly wrong solutions and hide gaps in understanding.
  • Linters, IDE inspections, tests, monitoring, and simple, well-documented designs are recommended as practical quality safeguards.
  • Multiple comments argue there is no clear “highest industry standard”; even elite companies ship messy code. What matters more: solving business problems reliably, documenting assumptions, and learning from the real consequences of your own decisions.