Hello, I'm Maneshwar. I'm working on FreeDevTools online currently building **one place for all dev tools, cheat codes, and TLDRs* — a free, open-source hub where developers can quickly find and use tools without any hassle of searching all over the internet.*
In 1979, Singapore’s Prime Minister Lee Kuan Yew spoke about the importance of clear, simple written English in government.
Decades later, his message applies perfectly to today’s technology and software world.
Our industry builds complex systems distributed services, microservices, machine learning pipelines, cloud infrastructure, scaling architecture.
But while the technology has evolved exponentially, the quality of communication often has not.
We’ve all seen it:
- PRDs and RFCs filled with jargon that nobody understands
- Engineering emails and Slack threads that are twice as long as they need to be
- Documentation that explains everything except what you actually need
- Pull requests where the description is “fix” and the code changes 400 lines
We celebrate cleverness too much, and clarity too little.
Clarity moves teams. Complexity slows them down.
Lee Kuan Yew said:
“Do not try to impress by using big words; impress by the clarity of your ideas.”
Replace “government” with “software engineering” and it’s still true.
In tech:
- Poor writing leads to misunderstandings
- Misunderstanding leads to wasted time, broken features, and blame cycles
- Confusion multiplies when teams grow or when remote work makes communication primarily written
Most bugs aren’t caused by code, they’re caused by unclear assumptions.
Write so that anyone can understand
When writing a design doc, an onboarding guide, or even a commit message:
- Assume the reader knows nothing about the context
- Say what you mean in the simplest words possible
- Remove adjectives and filler
- Break long sentences
- Prefer specific statements over vague ones
If you write something that requires decoding, you’ve already failed.
Good test:
Can a new intern understand the core idea in one read?
If not, rewrite.
Bad writing destroys velocity
Lee shared examples of confusing sentences written by officials, technically correct English but logically meaningless. We do the same in tech with phrases like:
- “We should leverage strategic synergies across cross-functional service layers.”
- “Optimizing system throughput with asynchronous parallelized concurrency guarantees.”
- “Needs architectural refactoring for scalable resilience.”
What does that even mean?
Better:
- “Two teams can share the same service instead of duplicating work.”
- “Run tasks in parallel so the system finishes faster.”
- “Redesign so it doesn’t crash when traffic increases.”
If your ideas are strong, they don’t need decoration.
Writing = Thinking
You can’t write clearly if you don’t think clearly.
If you struggle to explain something simply, you haven’t understood it fully yet.
Writing forces clarity, that’s why the best engineers write great documents.
Make feedback normal
Lee said he asked his assistants to correct his writing.
In engineering, we need the same culture:
- Comment on unclear PR descriptions
- Ask: “What does this mean?”
- Point out ambiguity
- Encourage rewriting
Not to nitpick, but to prevent chaos later.
Open communication speeds progress, silence kills it.
Why this matters for the future of software
As companies scale, communication becomes the real bottleneck, not compute power.
Code can be refactored.
Infrastructure can be upgraded.
People wasting time trying to understand each other is the most expensive thing in tech.
The industry needs less grand vocabulary and more clean thinking.
Less “complexity worship” and more simplicity.
The takeaway
Write in a way that:
- Everyone can understand
- Ideas are obvious
- Ambiguity is zero
- Purpose is clear
Because in tech, just like in government:
If we cannot communicate clearly, we cannot build anything great together.
👉 Check out: FreeDevTools
Any feedback or contributors are welcome!
It’s online, open-source, and ready for anyone to use.
⭐ Star it on GitHub: freedevtools
Top comments (0)