As software engineers, we often get obsessed with the latest frameworks, cool architectures, or squeezing out that extra bit of performance. Those things matter, sure. But honestly, the biggest, most positive changes I’ve seen come from something much simpler: how we communicate, collaborate, and think.

The real lessons don’t come from big books or fancy courses. They come from small things you notice over time — like how someone asks a question, reports a bug, or gives feedback during a code review. They are the invisible gears of a high-performing team.

Over my career, I’ve collected a few simple practices that have really shaped the work I do and the health of the teams I’m on. They might seem small, but their impact is huge. They’ve changed how I debug, collaborate, and communicate—quietly, but completely.

Communication: Skip “Hello,” Ask the Question

You’ve probably been there—you’re in the middle of deep work, and a message pops up that just says “Hi” or “Hello”. That little pause eats up focus time for both of you.

The principle is simple: Don’t ping people just to ping. Ask your question directly.

Instead of:

You: Hey,

Them: Hi!

You: Do you know how to use the new logging library?

Try:

You: Hey, do you know how to use the new logging library? I’m stuck on Step 3.

This is the core idea behind what many call NoHello.net. It’s not about being rude; it’s about being respectful of everyone’s focus time. In the async world of modern engineering, clarity is compassion.

The same goes for “Ask to Ask” patterns. Don’t ask if anyone knows Kafka; just ask the Kafka question! The right person will jump in faster with context.

Problem Solving: Don’t Fall for the XY Problem

When you get stuck, it’s natural to try a solution (Y), hit a wall, and then ask for help on the wall you hit. This is often called the XY Problem.

• X is the real problem you have.

• Y is the broken solution you tried.

If you only ask about solution Y, you get answers about Y, which might not even fix X.

To fix this, step back. Explain what you’re trying to achieve (the “X”) instead of just what you tried (the “Y”). You’ll get better advice and sometimes, smarter architectural solutions you never considered.

Team Culture: Kindness & Psychological Safety

You can have a room full of the smartest engineers, but if they don’t feel safe to speak up, admit they’re confused, or share a mistake—your team will slow down. Psychological safety is the backbone of real collaboration. It means people feel comfortable asking for help.

The most high-performing teams I’ve ever been a part of had one core thing in common: kindness. Not just fake politeness, but genuine kindness—what many refer to as Kind Engineering. The kind that:

• Gives space to ask any question — big or small. (Remember, no question is ever “dumb.”)

• Doesn’t mock or blame when someone breaks production.

• helps a new engineer feel like they belong.

A culture built on inclusion, trust, and honesty is the absolute foundation for great, resilient work. Kindness isn’t a “soft skill”—it’s a scaling skill.

Development: Respectful Code Reviews

Code reviews are perhaps the most sensitive moment in the engineering workflow. This is where culture is truly tested.

A respectful code review is non-negotiable for a healthy team. It follows one rule above all: Critique the code, not the person.

• Focus on the Code’s Impact: Instead of writing, “This logic is terrible,” try, “Could we simplify the function for better readability and lower cyclomatic complexity?”

• Ask, Don’t Command: Frame suggestions as questions to invite discussion. “What do you think about handling this edge case here?”

• Acknowledge the Good: Don’t just point out flaws. Start by highlighting something smart the author did: “Great job with the performance fix on this loop!”

A good review makes the code and the engineer better. A bad review makes someone defensive, slows down the merge, and slowly erodes trust.

Development: How to Report Bugs Effectively

Bugs happen. It’s part of the job! But the way you report them can either speed things up or cause chaos. A good bug report is a gift. It’s clear, minimal, and actionable. It should include the essentials, often inspired by classic advice like How to Report Bugs Effectively:

• Steps to reproduce: Exactly what the developer needs to do to see the bug.

• Expected vs. Actual: What should happen versus what actually happened.

• Environment: Where did this happen (browser, OS, device)?

When you write a report that says: “The app crashes randomly sometimes.” That’s not helpful.

But if you write:

The app crashes on iOS 17.1 when switching from the Home tab to Wallet.
Steps: Open → Tap Wallet → Crash. Expected: Wallet page should open.

That’s gold. Taking an extra two minutes to write a clear report can save a developer 20 minutes of investigation. It helps them reproduce it, fix it faster, and trust your testing. This is clarity disguised as kindness. When you write clear reports, you build credibility. People start listening because they know you write good ones. And in any engineering team, credibility is currency.

Lessons I Try to Live By

Over time, I’ve turned these principles into daily habits. They aren’t perfect rules—just small reminders that keep me grounded and keep the team running smoothly.

1. Write clear messages: Before hitting send, I ask myself: “Can this person reply without asking me for more info?” If not, I will rewrite it.

2. Give full context: Attach logs, screenshots, or examples. Don’t make others guess what’s happening.

3. Document the “why,” not just the “how”: Future-you will thank you for explaining the reasoning behind decisions. Because code without context is just noise.

4. Take responsibility early: If you broke something, say it first. Transparency builds more trust than silence ever will.

5. Don’t hoard knowledge: If you learned something tricky, share it. Write a short doc, drop it in the chat, or add a comment to the repo. Teaching is the fastest way to learn.

The Bigger Picture: Clarity, Empathy, and Effectiveness

Individually, these practices might feel too small to matter. But that’s the beauty of them—they scale invisibly. They aren’t complicated or flashy; they’re just subtle, human ways of working.

But look at what they do when you tie them together:

• Clarity: They reduce ambiguity in messages, problems, and bug reports.

• Empathy: They show you respect your teammates’ time, context, and focus.

• Effectiveness: Less back-and-forth, fewer misunderstandings, and faster progress.

This is the people effect of these small habits:

• One clear message saves five follow-ups.

• One kind review sets the tone for the whole team.

• One great bug report saves a release cycle.

If you’ve ever worked on a team where things just work—where people trust each other and projects flow smoothly—chances are, they’ve mastered these little habits. The code might be great, sure. But the communication and respect behind it is even better. When you invest in solid communication and culture, your team becomes more resilient, creative, and aligned. It’s what transforms a collection of individuals into a high-performing team.

Further Reading (Highly Recommended)

• No Hello – why “hi” wastes time

• Don’t Ask to Ask – how to ask questions that get answers

• The XY Problem – ask about the problem, not your attempt

• Kind Engineering – building safe, kind tech teams

• How to Report Bugs Effectively

• Respectful Code Reviews

Building a Team Where These Habits Thrive (Join Us!)

After years in SaaS (Postman) and fintech (Novo), I’m now building an engineering team at ZZAZZ (AI) where these habits are the default—not the exception. The goal is simple: to create a space where engineers feel empowered to be direct, kind, and focused on solving the right problem, together.

If you believe that clarity is kindness, that the “human layer” of engineering is the most critical, and that small habits are what build great products, then you might just be who we’re looking for.

Interested in an engineering culture built on these principles? We’re actively hiring folks who are just as passionate about how we work as what we build. You can always apply here!

At ZZAZZ, we’re building the world’s first large pricing model (LPM) — turning any content into a valuable, tradable asset.

Final Thoughts

There’s a line I keep coming back to: “Good engineering isn’t just about logic — it’s empathy in motion.”

When we talk about “best practices,” we often mean code quality, design patterns, or scalability. But the real best practices—the ones that make you love your job and truly respect your team—are often human. They’re about how we talk, how we listen, how we handle mistakes, and how we help others grow. These are the things that don’t show up on a dashboard, but they definitely show up in how people feel when they work with you. And that feeling? That’s culture. You can’t measure it, but you can certainly build it.

If there’s one core takeaway from this post, it’s this: Clarity is kindness. Every time you write a better message, describe a bug clearly, or ask a sharper question—you’re making life easier for someone else.

So, the next time you open Slack, write an email, or file a bug report, take a second to ask: “How can I make this easier for the next person?” That one second might save ten later, and little by little, it makes work a whole lot more human.

What practices or resources do you swear by? I’d love to know what’s helped you and your teams succeed. Share them in the comments, and let’s keep learning together! Here’s mine: vinitshahdeo.com/practices