Approval and Comparison: Why Do Others Matter So Much?

⚡ 1-Minute Summary: The constant itch to win workplace applause and measure yourself against other developers comes from your ego trying to protect a fragile self-image. Understanding how your mind manufactures this anxiety helps you stop letting other people's opinions control your mood—and gives you a clear path to build software without fear.

💬 In plain words: Most software engineers measure their personal value through the reactions of their coworkers. Getting praised for clean system architecture makes our whole week, while getting ten change requests on a pull request ruins our weekend. This happens because we have glued our human worth directly to external opinions.

📌 Example: You spend three days building a complex Salesforce Lightning Web Component (LWC) wired up to an autonomous Agentforce custom action using the Atlas Reasoning Engine. It runs without a single bug on the first try. Instead of enjoying the engineering win, you spend the next four hours refreshing Slack and GitHub to see if the Principal Architect or Product Owner dropped a thumbs-up emoji.

🎬 Real-Life Tech Example: The Engineer Addicted to Comparison

The Old/Bad Way: A mid-level developer spends every lunch break scrolling through LinkedIn and Salesforce Trailblazer profiles. They obsessively compare their current salary, certification count, and job title against tech influencers and former bootcamp classmates.
Why this fails: Their inner peace rises and falls based on heavily filtered online highlight reels they have zero control over.

The New/Good Way: The developer catches this craving for validation in real time, spots the hidden insecurity driving it, and redirects that mental energy back into mastering their daily craft.
The payoff: Their career growth is now fueled by real curiosity and deep platform knowledge, cutting out burnout and impostor syndrome.

See also: Fear: What Am I Afraid To Lose?

🧠 The Core Concept: How the Ego Builds a Hierarchy

In plain human terms, the ego is just a fragile mental picture you hold of yourself—like the label "I am the smart senior dev." Because a mental picture has no solid reality of its own, it requires non-stop maintenance. Comparison is the ego's favorite power tool. All day long, your mind quietly builds an invisible scoreboard, ranking whether you are "smarter" or "dumber" than the architect sitting on your Zoom call.

In the modern 2026 Salesforce and tech landscape—where autonomous Agentforce agents, Data Cloud (Unified Data Platform) zero-copy integrations, and AI coding assistants like Agentforce for Developers are shifting the ground under our feet—this comparison engine goes into overdrive. You aren't just comparing your Apex trigger logic or GraphQL wire adapters to your teammates anymore; you are comparing your output speed against AI-assisted builders across the globe.

Self-enquiry does not ask you to repeat fake positive affirmations in the mirror. Instead, it asks you to shine an honest light on your own thought process and ask: Why do I give external validation so much power over my mental state?

Here is the exact decision tree your mind runs behind the scenes when it falls into the comparison trap:

Root: Social Comparison Triggered (e.g., Peer gets promoted or praised in Slack)
 ├─ Step 1 [Measurement]: "How does my code, salary, or Trailhead rank stack up against theirs?"
 ├─ Step 2 [Identity Fusion]: "If they know more Data Cloud & Prompt Builder than me, I am falling behind and worthless."
 └─ Step 3 [Approval Hunger]: "I need the Tech Lead to praise my next Pull Request so I feel safe again."

🧠 Quick Mental Check: Next time you feel an urgent need for a manager or architect to praise your work, pause for ten seconds and ask yourself: "Does my actual technical skill change if they say nothing? What part of me feels threatened by silence?"

🔑 Key Points

• Comparison measures two totally unequal things: You are comparing your messy, behind-the-scenes debugging struggles against someone else's polished, public highlight reel. That math is rigged to make you feel like a failure every single time.
• Approval is a leaky bucket: Even if you get praised during Monday's sprint standup, the high wears off by Wednesday. When you rely on applause to feel okay, you hand the remote control for your emotions to your coworkers.
• Your code is not your soul: Writing a bulkified SOQL query in USER_MODE or building a fault-tolerant record-triggered Flow makes you a sharp engineer; hitting a governor limit does not make you a defective human being.
• Fear kills good system architecture: Developers who crave approval build "safe," outdated solutions just to avoid criticism, rather than proposing bold, scalable designs that actually solve the business problem.
• Observation beats suppression: You cannot stop your brain from comparing by getting angry at yourself. You weaken the habit simply by watching the thought pop up without acting on it.

🧭 360 Card — Mastering Approval Dynamics in Engineering

Rule: Watch the psychological itch for approval without blindly obeying it.
Gain: Rock-solid focus and calm that cannot be shaken by tough code reviews or office politics.
Price: Giving up the cheap sugar-rush of fishing for compliments and feeling superior to junior devs.
Limits: Human brains are hardwired for tribe survival; the initial flash of comparison will still fire in milliseconds.
Mirror (One Transaction): During sprint demo day, another developer gets huge applause for a simple UI button tweak while your heavy backend Apex asynchronous refactoring goes unnoticed. Watch the sting of jealousy arise in your chest without complaining.
Later: You will spot how often you change your words in architecture meetings just to sound smart.
At Volume: Your technical decisions, learning roadmap, and career moves become 100% driven by real engineering value rather than fear of judgment.

⚠ COMMON DEVELOPER TRAP: Do not confuse freedom from approval with arrogance. Many engineers think "not caring what others think" means ignoring coding standards, dismissing PR feedback, and acting like a lone wolf. True self-awareness removes emotional fragility so you can accept harsh technical feedback openly—without taking it as a personal insult.

🛠️ Real-World Step-by-Step: How to Handle a Brutal Code Review

Want to put this into practice today? Here is how you handle a pull request covered in twenty red comments using plain awareness:

Step 1: Catch the Physical Reaction
You open GitHub or DevOps Center and see 18 change requests on your Apex class. Notice your chest tighten and your brain immediately shout, "This architect hates me, or I'm a terrible coder." Do not type a reply yet.

Step 2: Separate the Fact from the Story
The fact is: Line 42 is missing WITH USER_MODE and might expose field-level data, and Line 88 could hit a heap size limit. The ego story is: "I am incompetent and everyone knows it." Drop the story; keep the fact.

Step 3: Respond to the Code, Not the Emotion
Read each comment as free QA testing. Fix the logic, learn the pattern, reply with a simple "Good catch on the FLS check—updated to USER_MODE in commit a4f89c," and move on with your afternoon completely unbothered.

❓ Core Q&A: Understanding the Approval Engine

🎯 Know this first: Is it wrong to enjoy appreciation when a major production deployment goes smoothly?

Not at all. Feeling warm when a teammate or manager says "great job" is normal and human. The danger only starts when appreciation turns from a nice bonus into oxygen—where you cannot work happily or feel secure unless people are clapping for you.

Q1: Why does criticism on my pull requests hurt so much?

A: Because your mind has welded your personal identity to your code. If you secretly hold the mental badge of "I am the smart senior developer," then a teammate pointing out an unbulkified loop or a missing null-coalescing operator (??) feels like an attack on your survival. Once you separate who you are from what you typed, a PR comment is just a helpful guardrail keeping bad code out of production.

Q2: Why do I constantly compare my career progress and salary with my friends?

A: The ego has no built-in way to know if it is safe on its own. It needs an external ruler. It uses your college friends, former coworkers, and anonymous forum posts as a yardstick to measure status. When you see this clearly, a friend's promotion stops feeling like an insult to your pace and becomes simple market data showing what is possible.

Q3: Can I still achieve high-level engineering success without seeking approval?

A: Yes—and you will actually get there much faster. When you build systems because you genuinely love solving tough puzzles (what psychologists call the "Flow State"), you dig deeper, read official release notes thoroughly, and build clean architecture. When you only work to impress a boss, you cut corners wherever the boss isn't looking.

Q4: How does social media (like LinkedIn or X) supercharge developer comparison?

A: Social feeds run on algorithms specifically tuned to poke your insecurities for clicks. You see twenty posts a day saying, "Thrilled to announce I passed my 20th Salesforce certification!" or "Just built an autonomous multi-agent workflow in 10 minutes!" You never see the four failed exam attempts, the broken scratch orgs, the Data Cloud ingestion errors, or the anxiety behind the screen. Your brain compares your raw, uncut backstage footage with everyone else's movie trailer.

Q5: How can I spot my need to be liked during daily standups and architecture meetings?

A: Pay attention to your body and your voice. Do you nod along with a loud Solution Architect even when you know their data model will break LDV (Large Data Volume) limits and cause record-locking errors? Do you over-explain simple bugs for five minutes so nobody blames you? Do you feel your stomach tighten right before unmuting your mic? That tightness is your ego bracing for judgment.

Q6: How does building this awareness change my relationships with my engineering team?

A: When you stop using your coworkers as mirrors to make yourself feel big, toxic competition vanishes. You stop hoarding tribal knowledge to protect your job security. You become the engineer who happily helps a junior fix a deployment error in Code Builder and genuinely celebrates when a peer nails a tough MuleSoft integration—because their shine no longer dims yours.

Q7: What happens when I actually win the comparison game and feel superior to my team?

A: That is the flip side of the exact same trap! Feeling superior ("I write way cleaner LWC and Apex code than everyone else here") still chains you to comparison. It creates a terrifying pressure to stay on top, makes you afraid to ask basic questions when a new feature drops, and stops you from joining stronger engineering teams where you might be the beginner again.

Q8: How do I handle impostor syndrome when learning new 2026 Salesforce tools like Agentforce and Prompt Builder?

A: Impostor syndrome happens when you compare your Day 1 of learning a brand-new technology against someone else's Day 500. Remember that in 2026, generative AI architecture, grounding prompts with Data Cloud vector databases, and configuring Agentforce topics are evolving every single release. Nobody knows it all. Give yourself permission to be a clumsy learner in a sandbox without demanding that you look like an instant expert.

🔗 Connecting the Dots (Follow-up Q&A)

Q9: How does dropping the need for approval improve pair programming or mob debugging?

A: Pair programming is torture when your ego is driving the car. You waste half your brainpower trying not to look stupid, hiding the fact that you forgot a basic JavaScript array method, or fighting over control of the keyboard. When you drop the need to look impressive, you freely say, "I have no idea what this error means, let's check the docs." Pairing turns from a stressful live audition into effortless problem-solving.

Q10: How can Tech Leads give code review feedback without triggering a junior developer's ego?

A: Keep your language 100% focused on the code and platform limits, never the person. Instead of writing, "You wrote this query wrong," write, "This SOQL query inside the for loop will hit the 101 governor limit when Data Cloud syncs a batch of 5,000 records." Frame comments as curious questions (e.g., "What happens here if the external REST API returns a null payload?"). This pulls the developer out of self-defense mode and straight into engineering mode.

Q11: What practical daily habit helps separate my personal self-worth from my Jira sprint velocity?

A: Practice "Clean Ticket Logging" at 5:00 PM. Before shutting your laptop, look at your unfinished Jira stories. Notice how your brain tries to turn an incomplete ticket into a moral failure: "I was too slow today." Consciously rewrite that sentence in plain engineering facts: "This OAuth 2.0 integration had undocumented token-refresh edge cases; two subtasks remain for tomorrow." Treat story points like weather forecasts—useful for planning team capacity, completely useless for measuring human worth.

Q12: How do I handle annual performance reviews without falling back into the approval trap?

A: Treat your performance review like a system health log, not a personal judgment day. Keep a simple private document ("Brag Doc") all year listing the production bugs you resolved, the architectural bottlenecks you removed, and the teammates you unblocked. Walk into the meeting looking for objective calibration on your career growth. If you get fair criticism, treat it as a free roadmap for what to study next quarter. If you get praised, say thank you, take the bonus, and leave your core identity untouched.

Q13: When AI tools generate boilerplate code faster than I can type, where should my engineering confidence come from?

A: If your confidence came from memorizing syntax and typing boilerplate Apex test classes fast, AI will naturally make you feel insecure. Shift your pride from typing speed to system judgment. An AI assistant can spit out code in three seconds, but it takes a grounded human engineer to verify security permissions, design clean Agentforce guardrails, understand real business pain points, and make sure the architecture won't collapse two years from now.