I remember the first time I realized that the buildings and houses I passed daily were not just markers on a route from point A to point B. They were full of people living their own lives, having their own experiences, with no connection to me. People who saw the world through their own eyes, thinking their own thoughts.
That realization set me on a new course. One of looking outward instead of inward. Discovering how the same experience looks different depending on the eyes seeing it. Understanding that the history your eyes have seen greatly influences the future you can envision.
This applies directly to software development. Every feature request, every bug report, every code review — they all come from someone with a different perspective. If you can see through their eyes, you build better software.
The Contact Form Problem
Consider something as simple as a contact form. Ask a team what it needs:
- Person A: A really big message field — customers need space to explain everything
- Person B: A captcha — spam is overwhelming our mailing list
- Person C: Two contact fields — a typo in one means we lose the customer
- Person D: Proper tab order — keyboard-only navigation matters
- Person E: Keep it short — nobody wants to fill out a long form
- Person F: Good labels — screen readers need context
Everyone wants something different. It seems like the team is working against each other. But step back and listen to the experiences behind each requirement:
- Person A recently tried to submit a bug report and could not paste the full error message because the field was too small
- Person B manages a mailing list flooded with unverified spam posts
- Person C had a customer they could not help because the email had a typo
- Person D injured their elbow and could not switch between keyboard and mouse
- Person E gave up on a six-page questionnaire just to ask a simple question
- Person F relies on a screen reader and generic labels make forms unusable
Different people. Different experiences. Different insights. None of them are wrong. Every person brings their own successes, frustrations, and lived experience to the project. Taking the time to understand where each person comes from produces a far superior end product.
Reading Code with Fresh Eyes
The same principle applies to reading code. When you review a pull request, you bring assumptions. You assume the author made mistakes. You assume your way is better. Observation requires setting those aside.
Next time you review code, ask:
- What context did the author have that I lack?
- What constraints were they working under?
- What problem were they solving, and is it the same problem I think they were solving?
// Before judging this code, ask why it exists
function formatName(string $first, ?string $middle, string $last): string
{
$middle ??= '';
if ($middle === '') {
return "$first $last";
}
return "$first $middle[0]. $last";
}Maybe the author has a user base where middle initials are the norm. Maybe the legacy data always stores the full middle name but displays only the initial. Observation means understanding the “why” before judging the “what.”
Listening to Users
Users tell you what they need — rarely in the language of features or code. They tell you through frustration, workarounds, and the things they do not say.
A user who says “this form is too long” might really mean “I am anxious about sharing this information” or “I am on a mobile device and the page keeps scrolling back to the top.”
A user who says “the search does not work” might mean “I typed what I thought was the right term, but your system uses different terminology.”
The developer’s job is to translate frustration into understanding. That requires observation more than technical skill.
Community Signals
The PHP community constantly sends signals through blog posts, conference talks, package trends, and Twitter threads. Paying attention to these signals helps you anticipate changes before they become urgent.
When multiple community members start talking about a new static analysis tool, pay attention. When discourse shifts toward a particular security concern, investigate. When a package you depend on stops getting updates, plan your migration.
Observation at the community level is the same as observation at the code level — looking for patterns, understanding motivations, and acting before problems become crises.
Building Empathy Through Observation
Empathy is not a fixed trait. It is a skill you develop through deliberate practice. Every interaction with a user, a teammate, or a community member is a chance to practice.
Try this exercise: The next time someone disagrees with you on a technical decision, instead of defending your position, ask three questions:
- What experience led you to that conclusion?
- What outcome are you hoping for?
- What would you consider a win?
The answers will almost never be about the technology. They will be about past pain, desired outcomes, and personal values. Observation reveals that most technical disagreements are not technical at all.
A Practical Practice
Make observation a habit. Every day, pick one thing to observe closely:
- Monday: Observe how a user interacts with your application. Watch their mouse movements, hesitation points, and click patterns.
- Tuesday: Read a pull request without forming an opinion for the first five minutes. Just observe the changes.
- Wednesday: Listen to a conversation in a community Slack or Discord without contributing. Just absorb perspectives.
- Thursday: Review your own code from last month. Observe the decisions you made and try to remember why.
- Friday: Ask a teammate what they learned this week. Listen without interrupting.
The Payoff
Observation changes how you build software. When you understand that the contact form is not a contact form but a collection of individual user experiences, you design differently. You add the big message field and the captcha and the dual contact fields and the tab order and the concise layout and the accessible labels.
You realize these requirements are not competing. They are complementary. Each one exists because someone needed it. Your job is to see through all their eyes at once.
That is the developer’s role as everyone’s eyes and ears — not just writing code that works, but building solutions that understand.