One of the great benefits of working with Datamole is the culture of curiosity, continuous learning and improvement. That is why I really enjoyed a Knowledge sharing session by our colleague Petr N. on the art of review. Applicable not only on the code, but any work output (products such as documents, slides or briefs), the thoughtful and effective review can make our lives much easier. And calmer - since usually, the review is associated with feeling of frustration, hesitancy, apprehension. 

If you have ever submitted a piece of work for review, you know this feeling. It is not about fear of being wrong. It is about not knowing what kind of response is coming. That uncertainty is what we set out to improve during our recent team session on the art of review.

What we mean by review‍

Reviewing doesn’t apply to just code but to any work artifact shared for feedback. This includes documents, dashboards, proposals, diagrams, presentations, and visuals. A review is when someone else looks at your work and offers input to help improve it. The goal is clarity, quality, and shared understanding.

A good review supports the author and improves the outcome. A poor review delays delivery, creates friction, and discourages collaboration. Reviewing well is not just a technical task. It is a communication skill and a team habit.

‍

Before you submit

You shape the review experience before the reviewer even sees your work. Here is the checklist we recommend before hitting submit:

• Do a self-review using the same tool you use to review others
  
• Make sure your work is complete and works as intended. If it is not, clearly explain what is missing and why
  
• Keep the scope small and focused
  
• Add context for anything non-trivial. Include reasoning, trade-offs, or a short summary
  
  

These small habits reduce confusion and help reviewers give thoughtful feedback faster.

‍

When submitting for review, I try to anticipate my reviewers questions and provide as much information as I can.

Petr N

‍

While reviewing someone else’s work

Reviewing is not about approval. It is about clarity, guidance, and support. A good reviewer looks at the work with fresh eyes and asks, “Is this ready? If not, how can I help?”

Here is our internal checklist for reviewers:

• Prioritize major issues first. Save lower-priority comments if the list is already long
  
• Make sure each comment adds real value. It can be technical reasons, business needs or learning purposes
  
• Use “observation, impact, suggestion” for complex feedback (or read more here)
  
• If you are unsure, ask a question instead of pretending to know
  
• Keep feedback impersonal and respectful. Talk about the work, not the person
  
• Do not approve unless you truly understand the work. Ask questions when needed
  
  

Avoid perceived authority bias. Do not assume something is correct just because a senior person submitted it. Everyone makes mistakes.

Common pitfalls to avoid

We also looked at some habits that turn reviews into a painful experience. These are the patterns to watch for:

LGTM (looks good to me) 

If there is nothing to point out, it is a great achievement - so say so. Or give your feedback if it’s not the case.

Delaying major concerns

Raising small issues first, then later introducing a large blocker. This causes rework and signals that the reviewer did not prioritize or respect the author’s time.

And even though not mentioned during the knowledge sharing, we compiled a list of other pitfalls:

Premature commenting

Reviewers sometimes stop reading after the first issue and begin commenting too early. This causes fragmented feedback and unnecessary iterations. Read the whole submission before giving input.

Bundling unrelated demands

Adding requests that are unrelated to the submitted work. This shifts the focus and makes the review feel like a power move, not a collaboration.

Uncoordinated feedback

Multiple reviewers give conflicting advice without aligning. The author ends up bouncing between contradictory requests. Reviewers should coordinate before pushing changes back.

Vague criticism without guidance

Pointing out a problem without explaining what is wrong or how to improve it. This forces the author to guess and often leads to frustration or wasted effort.

‍

The human side of reviews

Remember, there is always a human on the other side. Reviewing is not just technical. It is social. Feedback is easier to hear when it is clear and kind. Praise matters too. While criticism should stay focused on the work, good work deserves to be acknowledged. Positive feedback brings real satisfaction to the author and helps build trust.

Not every comment has equal weight. What matters in a company-wide guideline may not apply in the same way to a quick internal draft. Consider the context.

As AI-generated content becomes more common, the reviewer’s role is shifting. Tools like Copilot can help draft and review, but they cannot take responsibility. The final accountability lies with the human reviewer. That means reviewers must fully understand what they are approving.

The reviewer is now the last responsible person before the work is released. This role matters more than ever.

‍

Working better together

‍

Reviews do not have to be frustrating. With a bit of structure, empathy, and attention, they can become one of the best parts of the process. They make work clearer, decisions better, and teams stronger.

We are all still learning how to do this well. But when we treat reviews with care, we are not just improving artifacts. We are improving how we work together.

During his Knowledge Sharing session, Petr N. asked how it feels to submit and review work. The almost complete absence of frustration says a lot about the culture we’ve built at Datamole.

If you want to follow the recommendations we presented, you can use (and bookmark) the corresponding compact checklists:

Checklist - review as a submitter

https://pnevyk.github.io/posts/checklist-review-as-submitter/

Checklist - review as a reviewer

https://pnevyk.github.io/posts/checklist-review-as-reviewer/

‍

‍