Seeing Without Defending Myself

⚡ 1-Minute Summary: Self-enquiry requires the absolute courage to view ourselves honestly. When colleagues or technical leads point out flaws in our code, our minds instinctively try to defend our self-image. Learning to see feedback without immediately defending yourself creates the space needed for real technical mastery.

💬 In plain words: Most of us naturally build walls when our work is questioned or criticized. Self-enquiry asks us to examine our own defensive reaction first, rather than instantly trying to prove that we are right.

📌 Example: A senior architect comments on your pull request: "This SOQL query inside the loop will hit governor limits." Your immediate ego response might be, "But I had to rush this for the sprint deadline!" A moment of awareness flips this to: "Am I actually listening to the architectural feedback, or am I just protecting my pride?"

🎬 Real-Life Example: The Developer Who Could Not Accept Feedback

The Old/Bad Way: A developer receives critique on a new Lightning Web Component and immediately starts arguing, making excuses, and explaining their logic before fully hearing the reviewer out.
Why this fails: The developer's focus shifts completely from writing scalable software to protecting a fragile professional image.

The New/Good Way: The developer listens fully, observes their own inner urge to interrupt and argue, and simply takes notes on the feedback.
The payoff: The feedback becomes a highly useful tool to improve their Salesforce expertise instead of a painful personal attack.

🧠 The Core Concept

In the AP Framework, self-enquiry involves observing our internal emotional movements with total clarity. In high-pressure tech environments, the ego constantly tries to protect its reputation as a "smart developer" by generating instant explanations, excuses, and justifications.

Seeing without defending does not mean you must blindly accept every piece of bad technical advice. It simply means understanding the feedback entirely first, stripping away your emotional reaction, and then responding with logic and clarity.

The anatomy of a defensive reaction usually looks like this:

Root: Trigger (Feedback received)
 ├─ Hurt: "My competence as a developer is being questioned."
 ├─ Defense: "I must immediately prove that I am right and they are wrong."
 └─ Awareness: "Let me pause and see what is actually happening in my mind."

🧠 Tip: The next time you feel a hot surge of adrenaline and the urge to defend your code, pause and ask yourself: "What exactly am I protecting right now? The software, or my ego?"

🔑 Key Points

• Listen first, code second: Give yourself space to process architectural feedback before rushing to justify your initial approach.
• Feedback is data, not an attack: Treat code reviews like automated test results. They exist to improve the system, not to insult the creator.
• Ego limits expertise: If you are too busy defending what you already know, you leave no room to learn the things you don't.

🧭 360 Card — Understand Before Defending

Rule: Seek to fully understand the critique before offering a single word of defense.
Gain: You develop a much more honest and accurate understanding of your own skill gaps.
Price: You will occasionally have to face uncomfortable truths about your technical abilities.
Limits: It requires intense, active self-awareness in the exact moment you feel attacked.
Mirror (One Transaction): The next time a QA tester logs a bug on your feature, actively notice your brain's urge to say, "It works on my machine!"
Later: You will begin to spot your own predictable patterns of making excuses.
At Volume: Your workplace relationships improve drastically because you become highly coachable and collaborative.

⚠ TRAP: A major mistake is thinking that self-enquiry means you must constantly blame yourself. The goal is not self-criticism or imposter syndrome. The goal is clear, objective observation of the facts.

❓ Core Q&A & Follow-ups

🎯 Know this first: Does accepting feedback mean the other person is always right?

Not at all. Seeing clearly comes before accepting or rejecting anything. Self-enquiry helps us remove our emotional, personal reactions first. Only then can we look at the code objectively and decide if the feedback is actually technically sound.

Q1: Why do I feel personally attacked when someone corrects my Apex code or Flow design?

A: Because you have intertwined your personal identity with your technical output. When your code is criticized, your brain mistakenly interprets it as a direct threat to your professional competence and value as a person.

Q2: How can I listen to a harsh code review without becoming defensive?

A: Focus entirely on the technical problem rather than the person delivering the message. Take a deep breath, write the feedback down, and repeat this mantra in your head: "This is about the system's performance, not about my worth."

Q3: Is defending my technical architecture always a bad thing?

A: No. Defending your logic with documentation, best practices, and performance metrics is the hallmark of a great engineer. Defending it simply because your pride is hurt is where the problem lies. You must understand the critique fully before you present a counter-argument.

Q4: How does the ego create explanations and excuses?

A: The ego acts like a desperate PR manager. When you make a mistake—like deploying a bug to production—the ego instantly generates excuses ("the requirements were bad," "the deadline was too tight") to shift the blame and protect your self-image from the pain of failure.

Q5: Can honesty with myself be uncomfortable?

A: Yes, it is often highly uncomfortable. Admitting that you wrote inefficient code or misunderstood a core Salesforce concept stings your pride. However, stepping into that discomfort is the only legitimate path to senior-level growth.

Q6: How can this practice improve my relationships with my Agile team?

A: When you stop reacting defensively, your peers and leads feel psychologically safe giving you honest feedback. You quickly become known as a mature, collaborative developer. This drastically accelerates team velocity, trust, and your own career trajectory.

Q7: What should I say when I catch myself getting defensive in a meeting?

A: Use a circuit-breaker phrase. A simple, "That's an interesting point, let me take a step back, review the logic, and get back to you," buys you the time you need to process your emotional reaction and return with a cool, logical response.