During my first job, I was set on progressing as fast as possible. I wanted to work on bigger projects, earn more responsibility, and get there quickly. So I read a lot about what makes a good researcher, software engineer, and individual contributor (IC). This post is the short reference that I wish I had. It covers general career advice, SWE-specific advice, and a project checklist I made.

General advice

• Try to make the first company you work at a place where you think you'll learn a lot as it'll set expectations for future companies. I would optimize for learning over salary.
• Negotiate your salary, even if you only have one offer (McKenzie 2012)
• Choose your manager carefully as they'll determine how much you learn and how much you grow (Orosz 2021)
• Learn how your manager communicates (praise style, priority signals, update expectations)
• Get frequent 1-on-1s with your manager (Kuhn 2019)
• Ask your manager about providing frequent performance reviews
• Have goals for what you want to work on, and communicate them
• Become well-known for delivering on projects (Kuhn 2025)
• Choose to work on projects that matter to the company
• Surface issues early, with hypotheses and proposed solutions
• Ask for feedback early on work, and create as many feedback loops as possible (Boehm 2022)
• Have opinions that can survive one "why?"

SWE-specific advice

• Write design docs and get feedback on them (Ubl 2020)
• Try to understand software at your level, and one level below that (Elhage 2020)
• Get comfortable reading code and making changes in large codebases
• When debugging, always have a hypothesis and make sure to timebox yourself (Evans 2022)
• Write testable code (Beck 2020)
• Spend sometime to learn about best programming practices (Ousterhout 2018)
• Good logging solves a lot of issues
• Get good at using version control software
• Get good at BOTEC (back-of-the-envelope calculation) / Fermi estimates (Advanced Napkin Math: Estimating System Performance from First Principles 2019)

Project checklist

• What should the specs of this thing look like:
  • If it's code, ask:
    • what's the performance
    • what's the functionality
  • If it's a report, ask:
    • how formal
    • who's the end reader
      • when writing the report, have this audience in mind
    • how long
• Before reporting results or work, look at the results and think:
  • If I were {manager}, what would I have questions on.
    • Recursively make these changes until you think there are no questions left
  • List all of those, then try to go to the low hanging fruit
  • Spend time interpreting results before going to report
  • Have hypothesis of why things might be going wrong, have hypothesis of what you'd expect to happen
  • Work on doing your own thinking
  • Have a list of:
    • Open loops
    • Confusions
    • TODOs
• For codebases:
  • Always do your sanity checks to make sure that things behave as you expect
  • Keep a journal of problems you run into and why your current approach is correct
    • Make sure these are clear and readable, log the experiments and write down when and why you're doing them
    • Don't consider bugs new experiments, just log them under the same one
  • Test driven development, write tests as you go
  • If you're going to explore things, give yourself a time limit
  • If things are taking longer than expected, communicate that to the appropriate people
• For reports:
  • Google docs allows premade styling, do some of this so that you can just use those documents.

Recommended readings

Articles I'd read not mentioned above:

• Kuhn 2025
• McKenzie 2011
• Ludwig 2024
• Endler 2025
• Helton 2025

References

1. McKenzie, Patrick. "Salary Negotiation: Make More Money, Be More Valued | Kalzumeus Software". (2012).
2. Orosz, Gergely. "Reverse Interviewing Your Future Manager and Team". (2021).
3. Kuhn, Ben. "The Unreasonable Effectiveness of One-on-Ones". (2019).
4. Kuhn, Ben. "How I've Run Major Projects". (2025).
5. Boehm, Simon. "Becoming a Better Programmer by Tightening Feedback Loops". (2022).
6. Ubl, Malte. "Design Docs at Google". (2020).
7. Elhage, Nelson. "Computers Can Be Understood". (2020).
8. Evans, Julia. "Some Ways to Get Better at Debugging". (2022).
9. Beck, Kent. "TestDesiderata". (2020).
10. Ousterhout, John K.. "A Philosophy of Software Design". (2018).
11. "Advanced Napkin Math: Estimating System Performance from First Principles". (2019).
12. Kuhn, Ben. "Impact, Agency, and Taste". (2025).
13. McKenzie, Patrick. "Don't Call Yourself A Programmer, And Other Career Advice | Kalzumeus Software". (2011).
14. Ludwig. "On Becoming Competitive When Joining a New Company". (2024).
15. Endler, Matthias. "The Best Programmers I Know | Matthias Endler". (2025).
16. Helton, Graham. "Guideline For New Roles". (2025).