If you want a real judge of just how “dry” or “humid” it will feel outside, look at the dew point instead of the relative humidity. The higher the dew point, the muggier it will feel.

General comfort levels that can be expected during the summer months:

≤ 55: dry and comfortable
55 – 65: becoming “sticky” with muggy evenings
≥ 65: lots of moisture in the air, becoming oppressive

Source

What is the purpose of a code review? Many teams struggle to define this clearly, leading to ineffective review processes.

Code reviews are not there to catch bugs. For that, we have our automated tests. If the code passed all stages of the deployment pipeline and has been thoroughly tested, the code is releasable. In our case, the purpose of the code review was to convey knowledge, a learning tool and increase code quality.

Source

The Hidden Dangers of Poorly Executed Reviews

It is common sense that releasing code without any review at all is prone to danger. But, is there a danger in a code review itself?

Many times, the way teams execute code reviews adds little or no value other than slowing down delivery. Or even worse, it introduces dysfunctions in the team. Stories of one person solely deciding what comes in[to] the codebase and what not because they are so-called senior, are not uncommon.

Source

Ineffective reviews can create bottlenecks, damage team morale, and establish unhealthy power dynamics. When reviews become gatekeeping exercises rather than collaborative discussions, they undermine their intended purpose and can lead to resentment and reduced productivity.

Creating an Inclusive Review Culture

Who should review who? This question often reveals underlying power dynamics in development teams. Establishing a democratic review process where everyone participates regardless of seniority creates a culture of mutual respect and continuous learning.

There was no hierarchy of who reviews who. Seniors review from seniors and juniors. Juniors review from seniors and juniors. It avoided creating any bottlenecks.

Source

This approach distributes knowledge more evenly across the team and prevents the formation of single points of failure. Junior developers gain confidence and insight by reviewing senior code, while seniors benefit from fresh perspectives.

Clear Expectations for Review Outcomes

What is the expected outcome of a code review? Without clear expectations, reviews can become unfocused and inefficient.

A code review should have one of four outcomes:

1. LGTM [looks good to me]

2. Approved; left some suggestions for your consideration

3. Specific changes requested

4. This whole approach needs to be re-evaluated, let's talk

Source

When providing feedback, Conventional Comments is a great tool to use during Outcomes #2 and #3. This structured format, prefixing the comment with a label like suggestion, nitpick, issue, or question, transforms vague feedback into actionable insights. By clearly signaling intent (and tone), reviewers avoid the common pitfall of ambiguous comments that leave authors wondering, “Is this a blocking concern or just a thought?”

Pair Programming serves as a preventative measure. While it may help reduce instances of Outcome #3 (specific change requests), it excels at preventing Outcome #4 scenarios altogether. Rather than discovering fundamental issues during review, real-time collaboration catches misalignment early, when course correction requires minimal effort. The continuous knowledge exchange during pairing often eliminates the need for extensive post-implementation reviews.

When faced with Outcome #4, recognize it as a clear signal: “stop typing and have a conversation”. Text-based discussions quickly reach diminishing returns when addressing architectural concerns or approach problems. A brief face-to-face conversation can resolve in minutes what might otherwise spiral into days of comment threads and mounting frustration.

Just take five minutes and go talk to them or set up a call if they are working at another location. It almost always works better. For posterity, always note what was discussed/agreed offline back to the PR.

Source

Having clearly defined outcomes helps set expectations and streamlines the review process. When reviewers and authors understand the possible results, they can communicate more effectively and resolve issues more efficiently. Remember that the most productive discussions often happen face-to-face rather than through comments on a pull request.

Best Practices for Effective Reviews

To maximize the value of code reviews:

1. Focus on knowledge sharing rather than just finding issues

2. Be timely - quick feedback cycles maintain momentum

3. Use a consistent approach with clear standards and expectations

4. Separate style from substance - automate style checks where possible

5. Maintain a positive tone that encourages collaboration

6. Know when to talk instead of continuing a comment thread

More reading

Be sure to check out these resources:

• Google’s code review processes and policies

• Simon Tatham’s code review antipatterns

• Max Chernyak’s mindful code reviews

• Philipp Hauer's code review guidelines for humans

• Dr. Michaela Greiler’s

  • code review workshops

  • code review challenges that slow down your productivity

• Awesome Code Reviews

https://photos.app.goo.gl/cJDjSQUgr4YXxai29

Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.

Working in a rhythm of coding, pulling, testing, pushing, and getting feedback from integrated tests several times a day is electrifying. And it isn’t possible with pull requests that introduce a human delay into the rhythm.

Source

It's far more important to have a team that trusts each other and feels confident to push changes fast than it is to have gatekeepers whose role ends up being one of needlessly putting breaks on a team for no justifiable reason.

Source

The PR-based workflow still common to many engineering teams is at best inefficient, at worst fundamentally broken. In the journey of code from developer fingertips to user’s hands, the review stage of Github flow is usually the most drawn out and least productive. Code that could be delivering value to users is languishing on a branch, waiting for another engineer to pay the price of context switching to look at it. Add in the feedback cycle of comments being left, then being addressed, then looked over again — a cycle potentially repeated multiple times — and this stage of the voyage looks like a veritable doldrums.

Source

My biggest concern regarding pull requests is they block the flow of work. It is a gating process that blocks the delivery of functionality. The code review becomes definitive to merging and releasing. This again increases the time to market and introduces a non-negligible opportunity cost. Finally, it disables timely feedback from production.

Source

You need to have a Keeping The Lights On (KTLO) budget. Think of it, if you ran a zoo, you’d need to spend some time and money to replace and maintain the fences every now and then or all the monkeys and tigers would be roaming free otherwise.

Source

This zoo analogy perfectly illustrates why budgeting for system maintenance isn't optional. While "upkeep" rarely tops priority lists, neglecting it leads to inevitable consequences.

Stop calling them “technical debt” because it sounds like a new coat of wax on a car... which seems to address ego needs more than business needs. Start calling them “Business Continuity” projects, like a car needs an oil change or brake maintenance.

This shift in terminology is crucial. By framing technical needs in business terms, we enable stakeholders to better grasp their critical nature and why they deserve proper prioritization in our planning cycles.

• Democracy

  • Principle: Decisions are made by majority vote

  • Application: Widely used in governmental and organizational settings

  • Pros: Satisfies the majority

  • Cons: Can leave minority significantly dissatisfied

• Consensus

  • Principle: Everyone must agree

  • Application: Collaborative problem-solving and group engagement

  • Pros: Achieves complete group alignment and commitment

  • Cons: Often slow and can lead to deadlock (requiring authoritarian intervention)

• Dictatorship

  • Principle: Someone (the dictator) makes the decision

  • Application: Useful when clear accountability is needed

  • Pros: Can be effective with a competent and benevolent leader

  • Cons: Risks poor outcomes if the leader lacks expertise or good intentions

• Consent

  • Principle: All participants find the decision acceptable

  • Application: Effective when compromise is viable

  • Pros: Creates broad acceptance across stakeholders

  • Cons: May not generate enthusiasm from any party

Corry increasingly advocates for Consent as the most effective approach to group decision-making. For more reading, check out The University of Minnesota Extension's guide on group decision-making.

We consistently pray that the LORD would keep us open for as long as we are useful. And that He would shut us down the instant that we are not… We don’t fight for survival; we fight for service.

Quality Control

I love that they have a rigorous quality control process (as outlined below). The upside is you are sure to get great quality books. The downside is, they may not have the exact book you are looking for.

They assess whether the content is:

• Biblically rich

• Theologically robust

• Pastorally relevant

• Useful in ministry

In addition, they have a very high regard for book endorsements. But, they then also combine that with their own internal reading.

Summary

I highly recommend Westminster Bookstore (and have bought many books from them). Take a look and I doubt you will be disappointed.

https://wtsbooks.com (⇐ this link is my referral link; you get $5 and so do I)

There are 3 things you can do at a meeting:

• Learn something

• Teach something

• Make a decision

If you're not involved in any of those things, don't go.

Source

When meetings are organized & ran well, they are worthwhile. They typically result in a decision and action item to follow up on. Ask yourself when was the last meeting you had where a clear decision and action item was defined?

Rather I propose that you think about meetings differently. Instead of jumping straight into scheduling a meeting because it’s process or information, go through these questions to make sure you need to meet in the first place.

1. What is the goal of the meeting if we held one?

2. Can a decision & action items be made asynchronously?

3. Are the right people involved?

4. Do I have the attention of the people involved?

5. When does a decision need to be made?

Source