Ask HN: How can I grow as an engineer without good seniors to learn from?
Early-career engineers thrown into “tech lead” roles at non-tech companies face a trade-off between rapid autonomy and a lack of senior mentors to guide their growth. Many argue the fastest way to develop strong engineering fundamentals is to move to a larger or more established team with experienced colleagues, while others see solo roles as rare opportunities to learn leadership, domain expertise, and end‑to‑end ownership—provided you’re self-directed and realistic about the risks. Across viewpoints, people stress supplementing on-the-job learning with books, open source contributions, meetups, and careful use of AI tools, and warn against relying solely on LLMs or staying too long in environments that don’t provide feedback or guardrails.
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.