I'll often do the "first draft" as a design doc with an API sketch or a quick prototype that I'll post in chat or email to the team but not actually "mail for r

I'll often do the "first draft" as a design doc with an API sketch or a quick prototype that I'll post in chat or email to the team but not actually "mail for review" per the tool. That way I get early feedback that I'm going in the right direction for a code change. That makes sense for some types of changes, but it's too high-level to address the actual well-factored nature of the code, which is one of the main things I'm thinking about in the "second draft" of my code. Nobody's design doc is going to address "what's the right set of helper functions to extract here?" or "what's the right way to structure this logic to make it the most readable?". Design docs are great and they're super important for bigger changes, but they're often completely orthogonal to "is the actual code that implements this design doc readable and maintainable", which is the biggest question I'm seeking to answer in code reviews. This is also completely orthogonal to "do I have tests for this", "have I run the linter", etc. Certainly there are types of readability problems that running the linter or writing tests for your code can catch. Having focused changes with test coverage is only one part of making sure your code is long-term maintainable by the rest of the team.