How to incorporate documentation well?

You could make the argument that it might be too early to introduce a strict documentation process since the company is so early and having a strict documentation process could slow your team down.

I would start with an onboarding doc to make it easy for new engineers to get started immediately in the codebase and incrementally add documentation as needed. If there's a pattern of different people asking the same questions, it's a good signal that documentation needs to be added about that topic.

If an engineer asks you a question, and it takes a 30 minute meeting to answer the question, and 3 engineers ask you the same question, it's a worthwhile investment to spend the time to write up documentation to answer the question.

What exactly does that mean when you say you have been "tasked with code reviews"? Code review is a shared activity that (ideally) everyone participates in.

In code review, you want to be able to point to prior design decisions or documentation as justification for changes that need to be made. That's where a strong writing culture is important.

The main role documentation plays when it comes to code quality is two-fold:

1. You can proactively plan your approach and discuss
2. You can provide additional context in your pull request to make it easier to review

I talk about this in-depth in my code quality course here: [Course] Level Up Your Code Quality As A Software Engineer

Once we're going to higher-level documentation, you break into the system design realm, which is also documentation-heavy: [Course] System Design Masterclass: Shipping Real Features To Production

In general, it's good to write things. Writing makes you retain information better and makes it easier to build alignment by having an organized information source to rally around.

Lastly, here's a nice thread about non-technical writing: "How does Alex write so well?"