Why Taking Time to Explain Makes All the Difference
Why bother making a post to explain something that seems so basic? Who even cares?
Surprisingly, a lot of people do. What might seem simple or obvious to one person can be fascinating or utterly new to someone else. It reminds me of when I first learned how to code—I thought the basics of loops and conditionals were mind-blowing, but for an experienced developer, those things were trivial. I’ll never forget how much it meant when someone patiently broke it all down for me. I still think about that moment whenever someone asks me a “basic” question. Why mock someone’s curiosity? Everyone starts as a beginner, and the only way to improve is by finding people willing to share what they know.
Beyond that, it doesn’t make sense to criticise people for not understanding how difficult something is while simultaneously ridiculing any effort to explain it. It’s like expecting someone to navigate a maze while blindfolded, then scoffing when they bump into the walls.
I’ve seen this attitude a lot among software developers. Some would rather have everyone take their expertise at face value, no questions asked. “Just trust me; I’m the expert,” they say. I’ve worked with a few people like this, and it’s not pretty. And then there are those on the other side who see developers as nothing more than robots to execute their grand vision. “Just do what I say. The details are irrelevant.” Working in environments like that can feel dehumanising and demoralising.
I admit I used to be that kind of developer who inwardly sighed when a colleague asked a “silly” question. It’s easy to slip into that toxic “us versus them” mentality. It sometimes feels validating to roll your eyes and grumble about “those people” who just don’t get it.
But one day, I had a wake-up call. A coworker—someone I considered a friend outside of work—told me how hurt they felt by my dismissive attitude. That stung, and I felt guilty. I made the decision right then to change my approach. I treated every work interaction as if I were talking to a friend. If someone needed an explanation, I slowed down, put aside my impatience, and did my best to help. It didn’t matter if it took time away from my own tasks. It was worth it because these were people I cared about.
What started as a way to make amends turned into something transformative. Our team’s communication improved in ways I didn’t think were possible. We understood each other on a deeper level and tackled challenges together. Decisions that used to take forever suddenly became faster because we trusted each other and had fewer uncertainties. There was no more second-guessing what someone else might think. We just talked things out.
Not only were our decisions faster, but they were also better. We came up with creative solutions none of us could have imagined alone, simply because we had taken the time to communicate openly and thoroughly.
The time spent explaining things wasn’t a waste. It was an investment in our future efficiency and building a team culture where everyone felt heard and respected. That’s a lesson I’ll never forget.
Article by Dave
Related posts
Why We Sometimes Make Coding Harder (and How to Stop)
Let’s be honest—software development is complicated. It’s just the nature of the job. Bugs pop
Learning from Failing Fast
“Fail fast” is a phrase that gets tossed around often—and for good reason. In many sit
Microservices or Monolith? Why One Size Doesn’t Fit All in Software Development
Following the recommended methods and techniques may seem like common sense to many. It’s only