Book Highlights: How to Win Friends and Influence People

Completed Book on: 8th August 2025

Why I read this book

I picked up this book after a particularly frustrating code review session where I realized I was being way too direct with feedback. A senior engineer recommended it, saying it changed how he approached technical discussions. I was skeptical—how relevant could a book from 1936 be for modern software teams?

Turns out, very relevant. The core principles translate perfectly to engineering work, especially in remote teams where every interaction matters more. Here are the highlights that actually changed how I work.

These ideas have been especially helpful in remote work environments. If you're working remotely, also check out Mastering the art of remote work.

Key principles that changed my approach

"Don't criticize, condemn, or complain."

This one hit me hard. I used to open code reviews with "This is wrong" or "Why did you do it this way?" - basically putting people on the defensive from the start.

Now I try: "I'm seeing some potential issues here. Let's walk through this together." Same message, but it invites collaboration instead of triggering defensiveness.

Real example: Instead of "This function is inefficient," I write "What do you think about optimizing this loop? I'm concerned about performance with large datasets."

"Give honest and sincere appreciation."

People need recognition, especially in engineering where good work often goes unnoticed. Be specific about what they did well.

Instead of generic "good job," try: "Thanks for fixing that deployment issue so quickly—you saved us from customer complaints and I learned a lot watching you debug it."

I started doing this more in team meetings and Slack. The impact on team morale has been noticeable.

"Remember that a person's name is to that person the sweetest and most important sound."

In async communication, using someone's name makes a huge difference. Instead of "Can someone review this?" try "Hey Sarah, could you take a look at this when you have time?"

It's such a small change, but people respond much more positively.

"Be a good listener. Encourage others to talk about themselves."

In technical discussions, I used to jump straight to my solution. Now I ask more questions first:

• "What's your thinking on this approach?"
• "What constraints are you working with?"
• "How would you prefer to handle error cases?"

Let people explain their reasoning before offering alternatives. You learn more, and they feel heard.

"Talk in terms of the other person's interests."

This is crucial for cross-team communication:

• To Product: Focus on user impact and business outcomes
• To Engineering: Talk about maintainability, performance, and technical debt
• To Design: Emphasize user experience and implementation constraints

Same technical change, but framed differently for each audience.

"The only way to get the best of an argument is to avoid it."

Technical arguments get heated fast. Instead of debating approaches, I try to establish shared goals first:

"We both want this to be maintainable and perform well. Let's compare how each approach handles that."

Most technical disagreements dissolve once you align on what success looks like.

"If you are wrong, admit it quickly and emphatically."

Own mistakes fast, especially in production incidents:

"My mistake on that deploy—rolling back now and will have a postmortem ready by tomorrow."

No excuses, no blame-shifting. Just quick acknowledgment and action.

"Begin in a friendly way."

I changed how I open PRs and incident discussions:

• ❌ "This code has several problems..."
• ✅ "Nice work on the core logic. I have a few suggestions for the error handling..."

Starting positive makes people more receptive to criticism.

"Let the other person feel that the idea is his or hers."

Instead of "Here's what we should do," try "What if we explored this approach?" Then build on their input.

People support solutions they helped create. This is especially important in architecture discussions.

"Throw down a challenge."

Clear, achievable goals motivate teams:

• "Let's get this feature shipped with zero critical bugs by Friday"
• "Can we reduce this API response time by 50%?"

Specific challenges create focus and energy.

How this applies to engineering

These principles aren't just for management—they're essential for any engineer who needs to:

• Give effective code reviews
• Resolve technical disagreements
• Onboard new team members
• Communicate with stakeholders
• Lead technical initiatives

The book is 90 years old, but human nature hasn't changed. People still want to feel respected, heard, and valued. Technical skills get you hired; people skills help you be effective.

If you enjoyed these insights, check out my notes on Atomic Habits for more practical self-improvement ideas.