28. Review Your Code

In an earlier tile I talked about "Commit Often": commit more frequently, commit smaller, and write clear commit messages. This time we take the next step: how you review your own code before anyone else sees it. 🧐

Most developers see code review as something that happens to their code. Great developers understand: you are the first reviewer.

You are the first reviewer

Before you open a pull request, you should at least have done this:

• 🔍 Check your commits in detail
• 🧩 Commit small pieces of code
• 📝 Write clear commit messages

Your commits are a great lens to review your own work. Walk through your diff consciously: does what you see match what you intended, or did extra changes sneak in that do not belong there?

Create a useful audit trail

You always want to be able to see later:

• ⏱️ when something changed
• 👤 who changed it
• 💡 why it was changed

To make that possible:

• 🎯 keep your commits small and focused
• 📄 write commit messages that describe both what and why
• 🚫 avoid vague messages like "WIP", "fixes" or "more work"

That way, git blame becomes a helpful tool instead of a punishment. 🔍

Review your code again when you open a PR

One of the most powerful moments is when you create your PR. At that point the feature feels "done", and you finally see the complete picture. Use that moment to seriously review your own code one more time:

• ✅ Is everything included that needs to be there?
• ❌ Is there anything in the diff that should not be there, like debug messages, temporary logging, test data or commented-out code?
• 🧠 Are the names of variables, functions and components clear and consistent?

Especially when you just finished the feature and you have full overview, the rough edges become visible. ✨ Remove them yourself before someone else has to point them out.

Why this matters

The better you review your own code:

• 📉 the fewer issues others need to point out
• 🚀 the faster your PRs move through the review process
• 🏅 the stronger your reputation becomes as a developer who delivers "finished" work

"Review Your Code" does not mean "I glance over it quickly". It means looking at your own work consciously and critically, with respect for your future self and your team. 💻

• 🔎 At your next PR, take a few extra minutes to really study your diff: what can you still improve before you hit "Create"?
• 🤝 Talk with your team about self-review: is it an explicit part of your workflow, or just something everyone is "supposed" to do?