惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Forbes - Security
Forbes - Security
A
Arctic Wolf
M
MIT News - Artificial intelligence
T
Threat Research - Cisco Blogs
T
The Exploit Database - CXSecurity.com
C
CERT Recently Published Vulnerability Notes
NISL@THU
NISL@THU
L
Lohrmann on Cybersecurity
Martin Fowler
Martin Fowler
A
About on SuperTechFans
P
Palo Alto Networks Blog
Project Zero
Project Zero
The GitHub Blog
The GitHub Blog
WordPress大学
WordPress大学
Blog — PlanetScale
Blog — PlanetScale
博客园_首页
大猫的无限游戏
大猫的无限游戏
Cisco Talos Blog
Cisco Talos Blog
P
Proofpoint News Feed
D
DataBreaches.Net
Cyberwarzone
Cyberwarzone
T
Tor Project blog
IT之家
IT之家
P
Proofpoint News Feed
Help Net Security
Help Net Security
S
Securelist
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
C
CXSECURITY Database RSS Feed - CXSecurity.com
Microsoft Azure Blog
Microsoft Azure Blog
V2EX - 技术
V2EX - 技术
K
Kaspersky official blog
Hugging Face - Blog
Hugging Face - Blog
MongoDB | Blog
MongoDB | Blog
B
Blog
N
News and Events Feed by Topic
The Cloudflare Blog
S
Schneier on Security
P
Privacy & Cybersecurity Law Blog
T
The Blog of Author Tim Ferriss
Recorded Future
Recorded Future
Last Week in AI
Last Week in AI
The Last Watchdog
The Last Watchdog
Hacker News - Newest:
Hacker News - Newest: "LLM"
L
LangChain Blog
I
InfoQ
F
Full Disclosure
The Register - Security
The Register - Security
阮一峰的网络日志
阮一峰的网络日志
H
Hacker News: Front Page
V
V2EX

Yusuf Aytas

When Code Is Cheap, Does Quality Still Matter? Why Crouching Tiger, Hidden Dragon Is a Masterpiece The Mirror Is Part of the Machine When Too Many Maps Overlap on One Person The Work Runs on Different Maps Your Work Introduces You Trial By Fire The Dude Why Headcount Math Lies Capacity Is the Roadmap The Roadmap Is Not the System Torres del Paine W Trek Escaping Status Theater Incentives Drive Everything Scaling Culture Without Dilution What Good Looks Like Why Airport Security Feels Random Why Politics Appear How to Work with Me The Janus Protocol Multi-Horizon Delivery Framework What Good Execution Looks Like Managing Your Manager Why Kingdom of Heaven’s Director’s Cut Is Better AI Broke Interviews Most of What We Call Progress Managers Have Been Vibe Coding All Along Stop Wasting Brainpower Why Over-Engineering Happens Prisoner's Dilemma Climbing No More The Weekly Win Mevlana Candy Brewing Turkish Tea Onboarding Your Engineering Manager Technical Deep Dives Yapay Zekâ Çağında Bilgisayar Mühendisliği Building Remote Teams From Idea to Launch in 2 Weeks Reflecting on Software Engineering Handbook Representing the Business New Manager Survival Guide Take Self Reviews Seriously Chasing Real Respect The Invisible Difference Learning the Johari Window Management is a Lonely Place Simple Task Management AI Balance in Work PIP Manager Insights Engineering Manager Interview Preparation Work-Life Balance as a Manager Bridging the Management Disconnect Tech Hiring Bubble Bursts Traits for EMs Simple Acts of Recognition Matter The Question I Ask Every New Report The Reality of an Employer's Market Bridging Ideals and Reality Hiring Red Flags Why The Godfather Is So Damn Good Subteam Tenets No Fluff Please Losing a Top Performer Balancing Act of Reliability Building Trust in Engineering Teams Ideal Number of Direct Reports Overriding a People Leader’s Decision From Misperception to Promotion Perception vs Perspective Setting Goals From Engineer to Manager Getting Delegation Right Interviewing Your Future Boss Celebrating Our Book in Iceland Operational Skills Needed On Writing Software Engineering Handbook Charlie Munger Quotes Working with Dependencies From Las Vegas to Canyons Navigating Layoffs Handling Competitive Dynamics A Weekend Getaway to Malta Engineering Health Essentials Should Dev Managers Code? Confronting the Life on Pause Winning Eleven Kindness is A Choice Bireysel Katılımcılar ve Yöneticiler Leading from Where You Are The Subtle Art of Listening Coding in Leadership The Power of Consistency The Making of a Leader The Path to Leadership Embracing TikTok Talent Sourcing Journey Leading Self Managing Teams Cracking Coding Bottlenecks Quick Reflexes in Decision Making
Why We Ignore Advice
Yusuf Aytas · 2026-05-14 · via Yusuf Aytas

Published · 7 min read

The other day, I caught myself giving advice again. I do that a lot. Probably too much. While I was talking, something hit me. I have been told the right thing many times in my career, and in life, and I still did not follow it. They were right. I just did not listen.

My first boss in a three-person startup gave me career advice, but also real practical life advice. I ignored most of it. I thought I was different. Things would work out differently for me. I was wrong.

The problem with advice is not really correctness. A lot of advice is correct. The problem is that correctness without experience often feels like a nice sentence.

Agreement Is Cheap

I think a lot of advice fails because we confuse agreement with usability. Most advice is given in a calm state. Of course you should not overcommit. Of course you should talk to users first. Of course you should take care of your health. The advice makes sense.

Nonetheless, the moment where advice becomes useful is usually messier. You are tired, embarrassed, pressured, hopeful, afraid, or already invested. Saying no costs you something. Changing direction means admitting you were wrong. The easier path is right there.

Why We Ignore Advice MemeWhy We Ignore Advice Meme

Advice Competes With Your Beliefs

The other problem is that advice has to fight your existing beliefs. We already have a story in our head. Our version feels richer because we know the hidden details, the pressure, the fear, the hope, and all the little exceptions.

That is why “Yes, but…” is where most good advice dies. I have done a lot of projects in the past only to fail. One idea I carried for too long was that if I made a good product, it would sell itself. I heard the advice about talking to users before building. I understood it. Still, I thought our product was different.

Then came OffJar. We built the thing. I avoided finding enough people who had the problem, cared about it now, and would actually use what we made. Building felt like progress. Talking to users felt like a waste of time. So I picked the work that let me feel competent. That is the dangerous part. It does not feel like ignoring advice. It feels like adapting it to your special case. Most of the time, the special case is bullshit.

People Defend Before They Reflect

Advice often arrives as a threat to the self. Even when nobody means it that way, the recipient hears: your current way is wrong. Once that lands, resistance starts before reflection does.

“You need to stop doing this” is a verdict. It may be completely accurate, but it puts the other person in a corner, and cornered people do not reflect. They defend. “I made the same mistake, and here is what it cost me” carries almost the same information, but it gives the person more room. They are being shown the shape of a mistake before they have to claim it.

The instinct is to protect someone from the failure you can already see coming. The problem is that delivery can collapse the distance between “I see a risk” and “you are doing this wrong.” The person on the receiving end feels the accusation, even when you meant the warning.

I find this interesting because useful advice does not always need to be softer. Sometimes it needs more room around it. Hard truths can help, but only when they do not make someone protect their ego before they can inspect the idea.

The Scar Gets Lost in the Sentence

Then there is the weight missing from the sentence. People often take years of mistakes, pain, and correction, and compress all of it into one clean line of advice. By the time they say it, the lesson feels obvious to them. They know what it costs. The listener does not. So the advice arrives looking light, even though it was paid for heavily.

I remember one of my professors saying that if you truly understand a topic, you should be able to write a book, a paper, and a paragraph on it. Only then can you claim you have it. I liked it immediately. Filed it away as a smart thing a smart person said. That is usually the sign that nothing useful is about to happen.

At the time, I heard it as a clever sentence about learning. Later, it became useful at work, when I had to write executive updates on different topics. An executive update has to carry enough depth to be trusted, but not so much detail that the point disappears. You need to know what to include, what to leave out, what context matters, what risk needs visibility, and what would only create noise.

That is where my professor’s advice became useful. I finally understood that the book, the paper, and the paragraph are not just different lengths. They are different tests of control over the same idea. The book proves you can explore it. The paper proves you can structure it. The paragraph proves you know what survives compression.

The Conclusion Is Not Enough

Most advice-givers, including myself, hand over the conclusion without the context that produced it. "Do not overcommit" is a good example. I said it many times to managers and engineers. People still overcommitted. Looking back, I think I framed it too shallow.

A more useful version goes something like this. I used to overcommit because I trusted my ability to push through complexity. The plan always looked manageable in my head. The known work was clear, and I assumed the unknowns would get solved along the way. Then the hidden work showed up. One small integration exposed a bigger gap. One missing owner slowed the whole thing down. Now I try to separate confidence from commitment. I can believe something is possible without pretending the path is already understood.

You can see why the mistake was tempting, where the cost appeared, and what actually changed after it hurt. That has a much better chance of landing than tossing out the clean conclusion and hoping it turns into wisdom on its own.

Some Lessons Have to Hurt First

I think some lessons are not transferable at full strength. You can warn someone. You can show the pattern. You can share the scar. But they may still need to hit the wall themselves. Not because they are stubborn, but because the advice is pointing at an experience they have not had yet. You cannot shortcut someone into a context they have not lived.

That is how I feel about the life advice I got from my first boss. I had to fall a few times before I understood it. The dude was right. Annoyingly right. I came to the same conclusions much later and had that painful moment of recognition. He had already given me a lot of what I needed. I just did not have the context to receive it.

Now I understand the gravity of what he said. Back then, it was advice. Later, it became evidence.

Leave the Marker, Not Just the Answer

I still give advice, probably too much. I am trying to be less attached to whether someone follows it immediately, because that might be the wrong measure in the first place. Some advice is not accepted when it is given. It becomes useful later, when life creates the missing context and the person can finally see the shape of the thing you were pointing at.

So these days I care more about leaving a useful marker, not just the conclusion, but the situation that taught it, the mistake that made it expensive, the signal I ignored, the cost I paid, and the adjustment I made after.

Correct advice is cheap. The expensive part is being patient enough to let someone reach the same conclusion on their own timeline, not yours.