Writing is not always the first thing that comes to mind when you think about software development.
Developers spend much of their time writing code, solving technical problems, testing applications, fixing bugs, reviewing requirements, and trying to make a product work the way it is supposed to. Sitting down to write an article about those experiences can easily become something that gets postponed.
We understood that feeling at Dropndot.
But we also believed there was a simple problem with treating writing as something separate from development: every developer has experiences worth sharing.
That idea led to a simple rule inside our team:
No mercy for non-writers.
It was a lighthearted way of encouraging everyone to write regularly and share something from their professional experience.
Why Should Developers Write?
You do not have to be a professional writer to write something useful.
In software development, we encounter problems almost every day.
Sometimes the problem is complicated. Sometimes it is a small issue that takes only a few minutes to solve. Sometimes we spend hours trying different approaches before finally discovering what was causing the problem.
Once we solve it, it can be tempting to move on and forget about it.
But the solution that seems obvious to us might not be obvious to someone else.
That is where writing becomes useful.
A short explanation of a problem, the approach we tried, and the solution we eventually found can save another developer time in the future.
It can also help us understand our own work better.
When we explain a technical problem in writing, we are forced to organize our thoughts. We have to identify what actually went wrong, what we tried, why a particular approach did not work, and what finally solved the problem.
That process is valuable in itself.
Every Development Problem Can Become a Lesson
One of the reasons people sometimes avoid technical writing is that they assume an article needs to cover something groundbreaking.
It does not.
A real development problem can be enough.
A browser compatibility issue, a confusing CSS behavior, a database problem, an API integration, a deployment issue, or a small debugging discovery can all become useful material.
The important thing is not how impressive the problem sounds.
The important thing is whether the experience can help someone else.
That was exactly the thinking behind our writing initiative at Dropndot.
A Small Problem on the Bangladesh Cricket Board Website
Around this time, I was working on the website for the Bangladesh Cricket Board, which was still under development.
The project needed to support multiple browsers, including older browsers that were still being used by some users.
At that time, Internet Explorer 6 (IE6) was still part of the browser compatibility landscape developers had to consider.
And, as developers quickly learned, supporting older browsers could sometimes turn a seemingly simple CSS problem into a debugging exercise.
One of those problems involved the site’s dropdown navigation.
The navigation was supposed to appear above other page elements. We initially used z-index to control the stacking order.
That seemed like the obvious solution.
But the navigation was still appearing underneath other containers.
When z-index Wasn’t Enough
The interesting part of debugging is that the first logical solution is not always the solution that works.
The navigation already had a higher z-index, but some of the surrounding containers were using position: relative.
The behavior of positioned elements and stacking contexts could make the result different from what we expected.
So simply increasing the z-index was not enough.
This is one of those moments familiar to anyone who has worked with front-end development: you look at the code and think, “This should work.”
Then the browser tells you otherwise.
Instead of stopping at the first attempted solution, we had to look more closely at how the elements were positioned in relation to one another.
Finding the Solution
The solution was to change the navigation’s positioning approach.
We set the navigation to use position: absolute, allowing it to be positioned relative to the appropriate containing hierarchy.
We also made sure that its z-index was higher than the elements it needed to appear above.
Once those changes were made, the dropdown navigation behaved correctly across the supported browsers, including IE6.
Today, a developer encountering this type of issue has access to a huge amount of documentation, browser tools, community discussions, and debugging resources.
But the fundamental development process remains the same:
Identify the problem → understand the behavior → test possible solutions → find what works → document the lesson.
Why Sharing the Solution Matters
The browser problem itself was relatively small.
But the lesson behind it was bigger.
A developer who solves a problem and keeps the solution entirely to themselves gains one piece of knowledge.
A developer who documents the problem and shares the solution can potentially help an entire team.
That is one of the strongest reasons we encouraged writing at Dropndot.
The goal was not to turn every developer into a professional blogger.
The goal was to create a habit of sharing knowledge.
If you solved a difficult problem today, someone else on the team might face the same problem tomorrow.
If you document it today, tomorrow’s solution might already be available.
Writing Makes Technical Experience More Valuable
Software development produces a huge amount of knowledge.
Much of that knowledge exists only in developers’ memories.
Someone remembers how a particular bug was fixed. Someone else remembers why a particular implementation was chosen. Another person knows about an unusual browser behavior or a workaround that was necessary for an older project.
Without documentation, much of that knowledge disappears when people move to another project or simply forget the details.
Writing gives that experience a longer life.
Even a short article can become a useful reference.
More importantly, writing encourages developers to think beyond the immediate task.
Instead of asking only, “How do I fix this?”, we can also ask:
- Why did this happen?
- What did I learn from it?
- Could someone else encounter the same problem?
- What would I do differently next time?
- Can I explain the solution clearly enough for another developer to understand?
Those questions turn a single debugging experience into reusable knowledge.
You Don’t Have to Be a Writer
The phrase “non-writer” was deliberately part of our internal joke.
The idea was simple: you do not need to consider yourself a writer before you can write.
Start with what you know.
Write about a problem you solved.
Explain a technology you recently learned.
Document something that confused you.
Describe an approach that worked—or one that did not work.
It does not have to be perfect.
It just needs to be useful and honest.
In fact, some of the most valuable technical articles are not written like formal essays. They are straightforward explanations from someone who has actually encountered the problem.
That kind of writing is practical because it comes from experience.
From One Small Problem to a Culture of Sharing
The “No Mercy for Non Writer” idea started as a simple internal rule, but behind the humor was a serious purpose.
We wanted people at Dropndot to recognize that their everyday work contained knowledge worth sharing.
Every project brings new problems.
Every problem can teach us something.
And every useful lesson can potentially help someone else.
That is true whether the lesson comes from a complex software architecture decision or something as small as figuring out why a dropdown menu is appearing behind another container.
The technology will change.
The browsers will change.
The tools will change.
But the habit of learning from problems and sharing what we learn will always remain valuable.
Keep Learning. Keep Solving. Keep Writing.
Looking back, the IE6 navigation issue was just one small technical problem from an earlier stage of web development.
But it also represented something we wanted to encourage within our team: learn from your work and share that knowledge with others.
You do not need to wait until you have solved the biggest problem in software engineering before you start writing.
Start with the problem you solved today.
Someone else may be facing it tomorrow.
And if your experience can save that person an hour of debugging, then the few minutes you spent documenting it were worth it.
So, to all the developers who think they are “not writers”:
Write anyway.
Share what you learn.
And most importantly, never underestimate the value of a problem you have already solved.