One year ago, I started writing for a very selfish reason.
I was an SDE3, interviewing, reviewing a lot of code, and repeatedly explaining the same things:
- why React rerenders spiral
- why "just memoize" doesn't scale
- why frontend system design interviews feel vague until you've done them wrong a few times.
I didn't start writing to grow a Medium account. I started writing to externalize how I think as a frontend engineer.
A year later, I've written 50+ posts, crossed multiple 10k+ view articles, and more importantly developed a much sharper mental model of frontend architecture, performance, and system design.
This post is not a highlight reel. It's an honest breakdown of what worked, what didn't, and what I've learned by writing in public for a year.
The Numbers (With Context, Not Chest-Thumping)
Over the last year:
- 50+ posts published
- Multiple articles crossing 9k–11k views
- Several long-tail posts that continue to bring readers months later
But the more interesting pattern wasn't how many views I got.
It was which topics consistently broke out.
For example:
- JavaScript Design Patterns for Frontend Developers (~10k views)
- Modern Frontend Architecture Patterns (~9k views)
- SOLID Principles in React (~9k views)
- Web Workers: The Secret to Smooth JavaScript Performance (~11k views)
These weren't beginner tutorials. They were opinionated, architectural, and written for engineers who had already felt pain.
The First Big Realisation: Seniors Read Differently
Early on, I tried to balance beginners and experienced engineers.
That never worked.
The moment I leaned fully into "writing for senior frontend engineers", engagement jumped.
Posts like:
- The Truth About React Context and Rerenders: It's Not What You Think
- Patterns for Massive Forms in React: Scalable, Performant and Maintainable
- Why Your React App Feels Slow (Even When Lighthouse Is Green)
performed better because they didn't teach APIs. They challenged assumptions.
Senior engineers don't want steps. They want explanations for things that feel wrong but are hard to articulate.
Interviews Turned Out to Be a Goldmine (For the Right Reason)
I didn't plan to write so much interview-focused content.
But posts like:
- Frontend Coding Interview Questions: 7 JavaScript Challenges Companies Ask
- Advanced Frontend Interview Challenges
- Frontend Interview Series: How to Explain React Fiber Like a Pro
consistently outperformed expectations.
The reason became obvious over time:
Engineers don't struggle with knowledge. They struggle with structuring explanations under pressure.
Writing forced me to structure answers the same way I'd explain them in interviews, and readers felt that immediately.
Ironically, writing about interviews made me better at interviews.
Machine Coding: Mixed Results, Important Lessons
Machine coding rounds were the most interesting experiment.
Some posts underperformed:
- Real-time Chat App
- Spreadsheet Editor
Others did surprisingly well:
- Build a Real-time Task Board (Like Trello)
- Real-time Whiteboard with Canvas + WebSockets
The difference wasn't difficulty. It was relatability.
Problems that mapped clearly to real products performed better than "generic interview problems".
That changed how I design machine coding content going forward:
Real-world first. Interview framing second.
Writing Changed How I Design Frontend Systems
This was the biggest personal takeaway.
Writing posts like:
- Frontend System Design: Scalable Dashboards
- Patterns for Managing Shared State Across Microfrontends
- How to Build AI-Assisted UIs: Architecture Patterns
forced me to slow down and justify decisions I previously made on intuition.
I now think more deliberately about:
- ownership boundaries
- state lifecycles
- performance tradeoffs
- how designs age over time
That has directly shown up in system design interviews and architectural discussions at work.
Writing didn't just document my thinking, it refined it.
What Didn't Work (And Why I'm Glad It Didn't)
A few things clearly didn't move the needle:
- Trend-driven posts without real pain behind them
- Overly "advanced" deep dives without enough narrative setup
- Short posts that skipped context for brevity
Those failures were useful. They clarified my lane.
I'm not writing to be first. I'm writing to be useful six months later.
The Compounding Effect Is Real (And Underrated)
One thing I didn't expect: older posts keep feeding newer ones.
Someone reads JavaScript Design Patterns → clicks Modern Frontend Architecture → lands on React Performance Internals.
That compounding effect only happens when posts are:
- concept-driven
- not tied to a single framework version
- written from experience, not docs
At some point, the account stopped feeling like a blog and started feeling like a knowledge graph.
What I'll Do Differently Next Year
Next year, I plan to:
- write fewer posts, but go deeper
- focus more on system design, internals, and architecture
- document real-world tradeoffs instead of ideal patterns
- keep writing for engineers who already know the basics
If You're a Frontend Engineer Thinking of Writing
Here's the most honest advice I can give:
- Write what you already explain in code reviews
- Don't try to teach everyone
- Your first 10 posts are practice
- Consistency matters more than confidence
Wrapping Up
If you've read or shared something I wrote this year, thank you.
The discussions and disagreements have mattered more than any graph.
Here's to another year of thinking clearly about frontend systems, breaking assumptions, and writing things I wish existed when I was earlier in my career.
If there's a topic you want me to explore next year, I'm listening.