What should tech docs be written for and how do you write good ones?

• Tech docs are indeed mainly for planning how to execute a project. The process is to create a technical design document and then align the team around it in a tech review meeting.
• The alternative type of tech docs aside from project planning is using them to document how code works, usually in some sort of wiki. This is a bad idea. In any good tech company (i.e. the kind of company you want to work for), the codebase simply changes too fast for this to be sustainable. For almost all engineers, writing wikis is one of the more boring things they can do, so what will almost certainly happen is that the documentation will become outdated quickly. The documentation will then start adding negative value by confusing new engineers to the team as they use this now incorrect information to try to understand the codebase.
• Writing technical design documents and going through the tech review process is very beneficial to junior engineer growth as it teaches them to be more mindful and proactive about how they build software. This is one of the things I pushed all my junior engineer mentees to do after they established very solid coding proficiency, and it's also a big factor growing from mid-level to senior properly as well.
• How to write a good technical design doc is an entire course in and of itself, but here are the principles I follow at a high-level:
  • Outline pros and cons
  • Propose multiple approaches
  • Have a section dedicated to what can go wrong

Related resources:

• "How to write wiki type documents effectively?"
• Frontend System Design Masterclass - Building Playlists