Empathy for Software Engineers
Build deeper connections with users, teammates, and future maintainers.
Empathy - the ability to understand and share the feelings of another - is often dismissed as a "soft" skill, something nice to have but not essential for building software. This is a fundamental misunderstanding of what software development actually is.
Software is built for people. Code is read by people. Systems are operated by people. APIs are consumed by people. Every technical decision has human consequences. The engineer who can't consider others' perspectives will write code that's technically correct but impossible to maintain, build features that pass tests but frustrate users, and design systems that work until someone gets paged at 3 AM.
The most impactful engineers aren't just technically skilled - they're empathetically skilled. They anticipate the 3 AM page. They imagine the confused user. They consider the junior developer who'll read this code in two years. They recognize that the colleague who seems obstructionist might be dealing with something they can't see.
This isn't about being "nice." It's about building better software by understanding the humans who will interact with it.
The Four Directions of Engineering Empathy
Empathy in software engineering flows in four distinct directions, each requiring different skills and considerations:
1. Empathy for Users
The people who use what you build. This includes end users, but also internal users, customers, and anyone affected by your software's behavior.
2. Empathy for Future Code Readers
Your code will be read far more than it will be written. Future maintainers - including future you - need to understand not just what the code does, but why.
3. Empathy for Operators
Someone will be woken at 3 AM when your code fails. Someone will need to debug production issues with limited context. Someone will need to deploy, monitor, and maintain what you build.
4. Empathy for Teammates
Your colleagues have contexts you can't see - deadlines, personal challenges, different mental models, varying experience levels. Understanding these contexts makes collaboration possible.
User Empathy: Beyond "The User"
The Says/Thinks/Does/Feels Framework
From Nielsen Norman Group's empathy mapping methodology, understanding users requires examining four dimensions:
Says - What users say out loud in interviews and feedback:
- "I just don't understand what to do from here"
- "It was pretty straightforward"
- "Why would this be here?"
Thinks - What occupies their mind that they might not verbalize:
- "This is so annoying"
- "Am I stupid for not understanding this?"
- "I hope I don't break something"
Does - Physical, observable behaviors:
- Refreshes the page multiple times
- Abandons the form halfway through
- Calls a colleague for help
- Tries the same action repeatedly
Feels - Emotional states with the context that caused them:
- Impatient: pages load too slowly for their workflow
- Confused: too many options, unclear which to choose
- Anxious: worried about irreversible actions
- Frustrated: forced to repeat information already provided
Key insight: The gaps between these quadrants reveal the most important truths. A user might say "it's fine" while feeling frustrated and doing workarounds. A user might think "I'm probably doing something wrong" while the reality is the design failed them.
Choosing the Right Research Method
Understanding users requires choosing the right tools. Two common methods serve different purposes:
Quantitative methods (A/B tests, analytics) tell you what users do:
- Which button placement gets more clicks
- How long users spend on each page
- Where users drop off in a funnel
Qualitative methods (user interviews, observations) tell you why users do it:
- What they were trying to accomplish
- What confused them and why
- What mental models they bring
When to use each:
- Use A/B tests when you have a hypothesis to validate and enough traffic for statistical significance
- Use user interviews when you're exploring a problem space, don't understand user motivations, or need to understand edge cases
- Use both together: interviews generate hypotheses, A/B tests validate them
The common mistake is over-relying on A/B tests because they feel more "scientific." But A/B tests can only tell you which option performs better - not whether either option is what users actually need.
Users Are Not One Group
The Google code review guide makes a crucial distinction:
The 'users' are usually both end-users (when they are affected by the change) and developers (who will have to 'use' this code in the future).
Every piece of software has multiple user populations:
| User Type | What They Need | What Failures Look Like |
|---|---|---|
| End users | Task completion, reliability, clarity | Confusion, abandonment, support tickets |
| Developers using your API | Clear contracts, good errors, documentation | Misuse, workarounds, incorrect integrations |
| Future maintainers | Understandable code, context, tests | Bugs during changes, regression, fear of touching code |
| Operators | Observability, debuggability, graceful failure | Long incident times, alert fatigue, burnout |
| Support staff | Reproducible issues, clear error messages | Inability to help, escalations, frustrated customers |
Design for the Margins
From the accessibility perspective:
True inclusivity can only come when you include people with disabilities and accessibility best practices into the full product lifecycle - from planning, to designing, to coding, and more.
The numbers: Over 15% of the world's population - 1.3 billion people - self-identify as having a disability. But accessibility benefits everyone:
- Temporarily disabled: Broken wrist, post-surgery, medication effects
- Situationally disabled: Bright sunlight, noisy environment, holding a baby
- Mildly impaired: Needs reading glasses, has mild hearing loss
- Non-native speakers: Needs more time to read, benefits from captions
- Older users: Needs larger text, bigger touch targets
Accessibility isn't just for people with disabilities. I had elbow surgery, and it temporarily changed how I managed my daily digital activities. - Melissa
The curb cut effect: Features designed for accessibility often become preferred by everyone. Voice controls, designed for mobility impairment, are now mainstream. Captions, designed for the deaf, are used by people in noisy environments and non-native speakers.
Types of Disabilities to Consider
| Category | Examples | Pain Points | Tools They Use |
|---|---|---|---|
| Visual | Blindness, low vision, color blindness | Products that don't work with screen readers, color-only differentiation, poor contrast | Screen readers, magnification, Braille output |
| Mobility | Paralysis, arthritis, repetitive strain | Elements requiring mouse only, small click targets, time-limited interactions | Switches, eye tracking, voice input |
| Hearing | Deafness, hard of hearing | Missing captions, audio-only content, auto-generated captions | Captions, transcripts, sign language |
| Cognitive | ADHD, dyslexia, autism | Busy interfaces, walls of text, small fonts, justified text | Screen readers, text highlighting, summarization |
| Vestibular | Vertigo, motion sensitivity | Autoplay videos, parallax effects, excessive animation | Reduced motion settings |
The "Why" Behind User Empathy
Understanding why users behave as they do matters more than observing what they do:
- They're not "clicking randomly" - they're trying to find something the interface hides
- They're not "ignoring instructions" - the instructions didn't fit their mental model
- They're not "making errors" - the system didn't prevent an easy mistake
- They're not "stupid" - they have different expertise, context, and goals
Code Empathy: Writing for Future Readers
The Fundamental Truth
Code is written once but read many times. The Google engineering practices guide captures this:
'Too complex' usually means 'can't be understood quickly by code readers.' It can also mean 'developers are likely to introduce bugs when they try to call or modify this code.'
Every function you write, every abstraction you create, every decision you make will be encountered by someone - possibly yourself - trying to understand it later. That person will have:
- Less context than you have now
- A different problem they're trying to solve
- Time pressure
- Possibly a bug to fix at 2 AM
Comments: Explain Why, Not What
Usually comments are useful when they explain why some code exists, and should not be explaining what some code is doing.
Poor comment (explains what):
// Increment counter by 1
counter++;
Good comment (explains why):
// We track retries separately from attempts because billing
// only counts successful attempts, but SLA measures total retries
retryCount++;
Essential comment categories:
- Historical context: "We do it this way because [external system] requires..."
- Surprising behavior: "This looks wrong but is necessary because..."
- Performance reasons: "We denormalize here to avoid N+1 queries..."
- Safety constraints: "This must happen before X because..."
- Future readers: "If you're modifying this, be aware that..."
Commit Messages as Empathy Practice
Commit messages are gifts to future readers - including future you. A commit that says "fix bug" tells readers nothing. A commit that says "Fix null pointer when user has no shipping address" tells them exactly what changed and why.
Good commit messages:
- Explain what changed and why
- Include context that won't be obvious from the diff
- Reference related issues, discussions, or decisions
- Help readers understand if this commit might be relevant to their problem
Bad commit messages:
- "Fix bug"
- "Updates"
- "More changes"
- "WIP"
Your commit history is documentation. Future maintainers will use git blame to understand why code exists. Write messages that help them.
If You Can't Understand It, Neither Can They
From Google's code review guidance:
If you can't understand the code, it's very likely that other developers won't either. So you're also helping future developers understand this code, when you ask the developer to clarify it.
When reviewing code:
- If you need to ask "what does this do?", the code needs clarification, not just your understanding
- Your confusion is data about the code's maintainability
- Don't assume you're "not smart enough" - assume the code could be clearer
The Over-Engineering Trap
Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates might need to be solved in the future.
Over-engineering is an empathy failure - it prioritizes the author's desire to solve interesting problems over the reader's need to understand actual behavior:
| Premature Abstraction | Why It Hurts Readers |
|---|---|
| Factory for one type | Reader wonders what other types exist |
| Interface with one implementation | Reader looks for other implementations |
| Generics with one use | Reader assumes multiple types are supported |
| Configuration for one value | Reader doesn't know which values are valid |
The empathetic approach: Solve today's problem clearly. Comment on potential future needs. Refactor when those needs become real.
Code Review as Empathy Practice
Google explicitly includes positive feedback in code reviews:
Code reviews often just focus on mistakes, but they should offer encouragement and appreciation for good practices.
Empathetic code review:
- Explains why something should change, not just that it should
- Offers alternatives, not just criticisms
- Acknowledges good decisions, not just problems
- Considers the author's context and constraints
- Distinguishes "must fix" from "consider changing"
Operational Empathy: The 3 AM Test
The On-Call Reality
From Google's SRE book on being on-call:
When on-call, an engineer is available to perform operations on production systems within minutes. Typical values are 5 minutes for user-facing or otherwise highly time-critical services.
Consider what the on-call engineer faces:
- They were just woken up
- They have limited context on recent changes
- They're under time pressure
- They need to understand what's wrong, fast
- They need to fix it without making it worse
What Operators Need From Your Code
| Need | What This Means | Examples |
|---|---|---|
| Observability | The ability to understand internal state from external outputs | Structured logging, metrics, distributed tracing |
| Debuggability | The ability to isolate problems | Clear error messages, correlation IDs, runbooks |
| Graceful degradation | Failure of parts doesn't cascade | Circuit breakers, fallbacks, timeouts |
| Clear ownership | Knowing who to escalate to | Documentation, on-call contacts, service registries |
| Actionable alerts | Knowing what to do when paged | Runbooks, context in alerts, links to dashboards |
Write Errors for Operators, Not Developers
Poor error:
Error: null pointer exception at line 847
Better error:
Error: Unable to fetch user profile (user_id=12345)
- Cause: User service returned 503
- Impact: Profile page will show cached data
- Action: Check user-service health at [dashboard link]
Questions your errors should answer:
- What happened?
- What's the impact?
- What should the operator do?
- Where can they find more information?
The Invisible Operations Tax
Charity Majors on operational work:
It's so much easier to notice and reward shipping shiny features than 'something didn't break'.
Operations work is often invisible:
- Preventing incidents that never happen
- Maintaining systems so they don't degrade
- Cleaning up technical debt before it causes problems
- Writing documentation no one reads until they desperately need it
Recognizing this invisible work is an empathy practice.
Shared Pain, Better Systems
In a well functioning engineering team, the pain of the team is tied as closely as possible with the pain of the customers, which means your incentives are automatically aligned.
When developers don't experience operational pain:
- They don't prioritize operability
- They don't feel the cost of poor logging
- They don't understand why observability matters
- They design systems that are hard to debug
Solutions:
- Everyone participates in on-call
- Shadow operations rotations
- Include operability in code review criteria
- Share postmortems widely
Teammate Empathy: Understanding Contexts You Can't See
The Invisible Contexts
Every teammate carries contexts you can't see:
Technical contexts:
- Their mental model of the system differs from yours
- They know things about their area you don't
- They've tried approaches that didn't work
- They have constraints you're not aware of
Personal contexts:
- Sick family member
- Immigration stress
- Imposter syndrome
- Burnout
- Learning a new domain
Professional contexts:
- Pressure from their manager
- Performance review coming up
- Job insecurity
- Career uncertainty
Ask Before Assuming
The most common empathy failure is assuming intent:
- They're not "blocking progress" - they have concerns you don't understand
- They're not "being difficult" - they see risks you haven't considered
- They're not "nitpicking" - they've been burned by similar issues before
- They're not "slow" - they're being thorough about something that matters
The empathetic approach: Ask questions before forming judgments.
Instead of: "Why are you blocking this?" Try: "Help me understand your concerns."
Instead of: "This is taking too long." Try: "What's getting in the way? How can I help?"
Instead of: "You're overcomplicating this." Try: "Walk me through your thinking."
The 5 Whys With Empathy
The 5 Whys technique - repeatedly asking "why" to find root causes - is powerful but can feel like interrogation if done poorly.
Without empathy:
- Feels like blame assignment
- Makes people defensive
- Surfaces incomplete answers
- Damages relationships
With empathy:
- Frame as curiosity, not accusation: "I'm trying to understand the system, not find fault"
- Ask "what led to" instead of "why did you": "What led to this decision?" vs "Why did you do this?"
- Accept first answers as starting points, not final answers
- Thank people for helping you understand
Reviewing Stuck Pull Requests
A pull request that sits unreviewed for days sends a message: "Your work doesn't matter." A PR that's been commented on but not responded to might indicate:
- The author is stuck and doesn't know how to address feedback
- The author is overwhelmed with other work
- The feedback was unclear or felt harsh
- The author has moved on mentally
Empathetic approaches:
- If a PR has been open too long, reach out directly: "I noticed this PR has been open for a while - anything I can help with?"
- If you've left comments that aren't being addressed, check in: "Were my comments clear? Happy to discuss synchronously."
- If someone is clearly overwhelmed, offer to pair on the changes
- Don't let "waiting for review" become an excuse for blocking someone
Balancing with focus time: This doesn't mean reviewers must be constantly available. Time Management rightly advocates for batching shallow work. The balance: batch, but with reasonable SLAs (e.g., same-day code reviews). Predictable responsiveness protects both focus and teammates.
Onboarding Empathy
New team members are in a uniquely vulnerable position. They don't know:
- The unwritten rules and tribal knowledge
- Who to ask for what kind of help
- What questions are "okay" to ask
- Whether their confusion is normal or concerning
Empathetic onboarding:
- Remember how overwhelming your first week felt
- Proactively share context they couldn't know to ask about
- Explicitly normalize confusion: "Everyone is confused for the first month"
- Check in frequently without making them feel monitored
- Celebrate when they get something working, even if it's small
The goal is to make asking questions feel safe. New team members who feel judged for not knowing things will stop asking and learn more slowly.
Psychological Safety Enables Empathy
From Google's Project Aristotle research, psychological safety - the belief that you won't be punished for mistakes - is the foundation of effective teams.
In psychologically safe environments:
- People share their actual concerns
- People admit what they don't know
- People ask for help early
- People challenge ideas without personal attacks
- People give feedback honestly
Without psychological safety, empathy is impossible - people hide their true thoughts and feelings.
The Three Responses to Difference
When someone disagrees with you or does something differently, you have three options:
- Assume incompetence: "They don't know what they're doing"
- Assume malice: "They're trying to block me"
- Assume context: "They know something I don't"
The third option is almost always correct and almost never chosen by default.
Practicing Empathy: Concrete Techniques
The 3 AM Test
Before merging any change, ask:
- If this fails at 3 AM, what will the on-call engineer see?
- Can they understand what's wrong from the logs?
- Can they fix it without understanding all the code?
- Is there a runbook they can follow?
The New Team Member Test
For any code you write, ask:
- Could a new team member understand this in their first week?
- What context would they be missing?
- What questions would they have?
- Have you documented the answers?
The Frustrated User Test
For any feature you build, ask:
- What if the user's internet is slow?
- What if they have a disability I don't have?
- What if they're stressed and rushing?
- What if they made a mistake - can they recover?
The "They Might Be Right" Test
For any disagreement, ask:
- What would need to be true for their perspective to be correct?
- What do they know that I don't?
- What experience shaped their view?
- What am I missing?
The Credit vs. Blame Test
When something goes wrong:
- Do I assume individual failure or system failure?
- Do I ask "who did this?" or "how did the system allow this?"
- Do I look for blame or learning?
When something goes well:
- Do I claim individual credit or acknowledge the team?
- Do I recognize the invisible work that made it possible?
- Do I share success as broadly as I'd share blame?
Empathy by Level
Junior Engineers
Focus Areas:
- Recognizing that users exist beyond the happy path
- Understanding that your code will be read by others
- Learning to ask clarifying questions instead of making assumptions
- Accepting feedback as help, not criticism
Practice:
- Watch a real user try to use something you built
- Have a teammate explain code you wrote back to you
- Shadow the support team for a day
- Read postmortems from other teams
Common Misconception: "Empathy is about being nice." It's about understanding others deeply enough to make good decisions.
Mid-Level Engineers
Focus Areas:
- Writing code that communicates intent
- Considering operational impact of changes
- Recognizing when teammates have different contexts
- Giving feedback that's actionable and kind
Practice:
- Participate in on-call rotations
- Do accessibility testing on features you build
- Document the "why" behind architectural decisions
- Review code with attention to maintainability, not just correctness
Common Misconception: "I know what users want." You know what you would want. Users are different.
Senior Engineers
Focus Areas:
- Designing systems that are operable by others
- Creating abstractions that readers can understand
- Recognizing invisible work and glue work
- Building psychological safety on teams
Practice:
- Write runbooks for everything you build
- Mentor juniors through problems rather than solving for them
- Advocate for accessibility and inclusivity in designs
- Champion operational excellence across the team
Common Misconception: "Technical excellence is enough." Technical excellence without empathy creates systems that only you can operate.
Staff+ Engineers
Focus Areas:
- Setting organizational standards for user empathy
- Creating systems that distribute operational burden fairly
- Recognizing and elevating invisible work
- Building empathy into processes and culture
Practice:
- Ensure new engineers shadow operations
- Advocate for accessibility as a first-class concern
- Create spaces for diverse perspectives in design
- Model asking clarifying questions publicly
Common Misconception: "Strategy doesn't require empathy." Every technical strategy affects people. Understanding those effects is part of the job.
Architects
Focus Areas:
- Designing systems that operators can understand
- Considering how decisions affect developer experience
- Understanding impact across organizational boundaries
- Building systems that gracefully handle human error
Practice:
- Talk to end users regularly
- Understand the operational burden of your designs
- Consider accessibility from the architecture level
- Document decisions for future architects
Common Misconception: "The architecture should be self-explanatory." It never is. Context and intent need to be explicit.
The Empathy Paradox
There's a tension at the heart of engineering empathy: you can't empathize with everyone equally. Sometimes user needs conflict with operator needs. Sometimes code clarity conflicts with performance. Sometimes teammate comfort conflicts with shipping.
The resolution isn't to choose one over another - it's to make these tradeoffs explicitly and transparently:
- Acknowledge the tension: "This is more complex than ideal because we prioritized..."
- Document the decision: "We chose X over Y because..."
- Revisit the tradeoff: "If circumstances change, we should reconsider..."
- Accept imperfection: You can't optimize for everyone, but you can consider everyone.
Empathy in Difficult Situations
Empathy is easiest when things are going well. The true test comes during difficult situations - when colleagues are struggling, when organizations are changing, or when people are in crisis.
Recognizing Burnout in Colleagues
Burnout doesn't announce itself. It creeps in through changes in behavior:
Warning signs:
- Cynicism that wasn't there before: "What's the point?"
- Withdrawal from team activities and discussions
- Visible exhaustion that rest doesn't fix
- Detachment: "I don't care anymore"
- Irritability over small things
- Declining quality of work
Empathetic responses:
- Notice and name it privately: "I've noticed you seem more tired lately. How are you doing?"
- Don't try to fix immediately - just listen
- Offer concrete help: "I can take that review off your plate this week"
- Normalize rest: "Taking time off isn't weak - it's necessary"
- If appropriate, gently suggest professional support
What not to do:
- Ignore it and hope it goes away
- Add more work because "they're so reliable"
- Publicly call out changes in behavior
- Offer toxic positivity: "Just think positive!"
Supporting Colleagues Through Organizational Change
Layoffs, reorganizations, and leadership changes create fear and uncertainty. Even if you're not directly affected, your colleagues might be.
During layoffs:
- Acknowledge the reality: "This is hard. It's okay to feel uncertain."
- Don't pretend everything is fine when it clearly isn't
- Check on people who might be more affected (newer employees, contractors, those with visa dependencies)
- If you're a survivor, don't disappear - remaining colleagues need support too
- Respect that people may need time before they're ready to "move forward"
During reorganizations:
- Recognize that even positive changes create stress
- Don't dismiss concerns: "But this will be better eventually" doesn't help right now
- Share information you can share - uncertainty is often worse than bad news
- Maintain routines where possible to provide stability
Walking Alongside Struggling Teammates
Sometimes teammates go through personal crises - health issues, family emergencies, loss. You can't fix these problems, but you can walk alongside them.
Helpful approaches:
- Simply acknowledge: "I heard about X. I'm sorry. I'm here if you need anything."
- Be specific with offers: "I'm handling the deployment this week - don't worry about it" vs. "Let me know if I can help"
- Follow up later - people often need support after the initial crisis passes
- Respect boundaries - some people want to talk, others want distraction
- Don't require them to be "strong" or "inspiring"
The key insight: You don't need to have the right words. Showing up and being present matters more than saying something perfect.
Crisis Communication
When systems fail or projects collapse, communication requires extra empathy - because everyone is stressed.
During incidents:
- Keep communication clear and factual
- Don't add stress by expressing frustration with teammates
- Assume everyone is doing their best under pressure
- Save retrospectives for after the crisis
- Thank people for their efforts even when things are hard
After crises:
- Acknowledge the stress people went through
- Create space for people to decompress
- Focus on systems, not blame
- Recognize that recovery takes time
TL;DR
- Empathy flows in four directions - users, future code readers, operators (the 3 AM pager), and teammates; each requires different considerations
- Write code for the reader - comments explain why not what, commit messages tell the full story, and if you can't understand it, neither can they
- Pass the "3 AM test" - before merging, ask: can someone woken from sleep understand what's broken from your logs, and fix it without understanding all your code?
- Assume context, not incompetence - ask "What would have to be true for their perspective to be correct?" before assuming malice; context differences explain most friction
- Design for the margins - features built for disabilities often become preferred by everyone (voice controls, captions); accessibility benefits all users
References
On User Empathy
- Nielsen Norman Group. "Empathy Mapping: The First Step in Design Thinking." nngroup.com
- Ladau, Emily. Demystifying Disability: What to Know, What to Say, and How to be an Ally
On Accessibility
- web.dev. "Learn Accessibility: What is digital accessibility, and why does it matter?"
- World Health Organization. "World Report on Disability"
On Code Readability
- Google. "Code Review Developer Guide: What to look for in a code review." eng-practices
On Operational Empathy
- Majors, Charity. "WTF is Operations? #serverless." charity.wtf
- Google SRE Book. "Chapter 11: Being On-Call"
- Google SRE Book. "Chapter 12: Effective Troubleshooting"
On Team Empathy
- Edmondson, Amy. "Psychological Safety and Learning Behavior in Work Teams"
- Google re:Work. "Project Aristotle: Understanding Team Effectiveness"