The Art of Feedback: Navigating Emotions in Software Engineering

Overview

In the software industry, meetings and discussions happen every single day throughout the development cycle. During these sessions, a ton of ideas and opinions are raised. However, if these ideas aren't well-built with the collective thoughts of the team, the product requirements cannot be finalized, and the feature cannot be released.

Problem Setup

Humans are essential in this cycle, and humans have emotions. Sometimes, those emotions can explode and damage the entire development process.

Some people say that a professional worker should put emotions away from their work, but in reality, that is impossible. Why? Because human beings are not machines. Not everyone can simply "turn off" how they feel. Therefore, giving feedback gently and effectively is essential to avoid unexpected emotional issues that can stop a project in its tracks.

As an experienced developer with over 6 years of experience across 8+ teams—from small startups to large scale—I have concluded that giving feedback is the fuel that helps a team grow. Mastering it helps you avoid conflicts that often lead to "human changes" (people leaving the team).

7 Techniques for Giving Effective Feedback

1. The SBI Model (Situation-Behavior-Impact)

When giving feedback, speakers often give "personality-based" feedback, which causes confusion and defensiveness. You should always be specific about the exact scenario using the SBI framework.

Situation -> Behavior -> Impact

With:

• Situation: Define the specific time and place.
• Behavior: Describe the observable action (not your interpretation).
• Impact: Explain how that behavior affected you or the project.

Let's check out these real examples:

• Bad Example:

• "You're difficult to work with in meetings."

• Why it fails: This is like a slap to the receiver. They might be good overall, but only bad in a certain scenario. Without concrete analytics, this is just an opinion.

• Good Example:

• "When I was in the meeting with you last week (Situation), you took 10 minutes to just make a judgment on a member (Behavior). This made me feel that it was hard to work with you in that meeting and we couldn't deliver the ideas on time (Impact)."

• 🎯 Best for: Addressing a specific negative behavior without attacking the person's character.

2. The Sandwich Feedback

Feedback should be written like a sandwich with bread and meat. One layer of bread (positive comment), one layer of meat (the constructive criticism), and the last layer is bread again (positive encouragement).

• Example:
  • (Bread): "I really like how you structured the database schema, it's very scalable."
  • (Meat): "However, the API response time is a bit slow because of the nested loops. We need to optimize that query."
  • (Bread): "Once that is fixed, this module will be perfect for release."

🎯 Best for: General performance reviews or when the receiver is sensitive to criticism.

3. Use Positive Words

Instead of using heavy, negative words like "bad," "terrible," or "wrong," we should use a more gentle way with positive words.

• Bad Example: "This code is terrible and slow."
• Good Example: "This code logic is not really optimized yet. It is not fast enough for production."

🎯 Best for: Text-based communication (Slack/Jira) to keep morale high.

4. Prefer Questions Instead of Commands

When giving feedback, especially in code reviews, developers usually say "Don't do it" or "Please do this instead." Keep in mind that there is no such thing as 100% correct; things vary based on conditions. Therefore, we should use questions to express the idea and listen for thoughts from the developer.

• Command: "Move this logic to the backend."
• Question: "What do you think about moving this logic to the backend to reduce the load on the client?"

🎯 Best for: Code reviews and technical discussions to encourage collaboration.

5. Feedforward (The Future Focus)

Unlike traditional feedback which acts like an archaeologist digging up past mistakes, Feedforward acts like an architect planning the future. You don't critique what happened; you only suggest options for what could happen next.

• Example: "To avoid this deployment error in the next sprint, let's add a pre-commit hook to catch these formatting issues automatically."

🎯 Best for: High-stress situations where looking at the past causes defensiveness.

6. Radical Candor (Care + Challenge)

This technique involves challenging the person directly while showing that you care about them personally. It builds trust because the receiver knows you are critiquing their work to help them grow, not to hurt them.

• Example: "I'm telling you this because I want you to get that promotion: your code logic is solid, but your documentation is confusing for the rest of the team. I can help you review the docs tomorrow."

🎯 Best for: Mentoring relationships and close teammates.

7. Depersonalization (The Third Party)

Shift the conflict away from "You vs Me" and toward "Us vs The System." Treat the code or the bug as a third party that you are both trying to fix.

• Example: Instead of "You made the app slow," say "The application latency is too high with this query; how can we optimize it?"

🎯 Best for: Discussing bugs, architectural flaws, or system failures.

---

Conclusion

In terms of collaboration, giving feedback isn't an easy activity. It requires us to practice frequently to calm down when we start giving feedback.

The Tip: You should take a deep breath before giving any feedback. This small pause helps you choose the right technique from the list above. By doing this, you will become a developer and a manager that everyone will like to work with.