DEV Community: Mohit

The Anatomy of a Great DEV.to Post

Mohit — Mon, 15 Jun 2026 05:27:03 +0000

Before diving into the markdown editor, it helps to understand what makes a post succeed on the platform.

1. The Title (Clear > Clever)

DEV.to users browse quickly. Instead of an ambiguous title like "Thinking about writing?", go for something search-friendly and direct:

How to Write a DEV.to Post That People Actually Read
The Developer's Guide to Technical Blogging on DEV.to

2. Liquid Tags & Embedded Code

Since you are writing for developers, syntax highlighting is non-negotiable. DEV.to uses standard Markdown for code blocks, but it also supports Liquid Tags to embed interactive elements like GitHub gists, Tweets, or CodePens seamlessly.

{% stackblitz devto-example %}

3. Tags matter

You can add up to 4 tags. Choose them wisely because users follow specific tags (like #webdev, #beginners, #tutorial). Including #beginners or #productivity is highly recommended for a meta-post like this.

4. Leverage Official Challenges & Hackathons

DEV.to frequently hosts official community hackathons and writing challenges sponsored by major tech brands.

Participating in these is an incredible shortcut for growth because:

1. The platform actively boosts challenge submissions to the main homepage feed.
2. You get an exclusive badge on your profile just for submitting.
3. There are usually cash prizes, swag bags, or credit rewards for winners.

Crucial Rule: To officially enter, your post must include the specific challenge tag (e.g., #snykchallenge, #githubhackathon) and often requires a specific submission template structure.

📝The Draft Template

You can copy, paste, and tweak this exact Markdown template straight into the DEV.to editor.

---
title: How to Write a Post on DEV.to: A Beginner's Guide
published: false
description: A quick, no-nonsense guide to formatting, structuring, and publishing your first technical article on DEV.to.
tags: beginners, webdev, productivity, tutorial
---

Starting your technical writing journey can feel a bit daunting, but DEV.to makes the process incredibly smooth. Whether you want to document your learning, share a solution to a weird bug, or launch an open-source project, this platform is the perfect place to start.

Here is a quick guide on how to get your first post live.

## 1. Master the Markdown Editor
DEV.to uses Markdown, which allows you to format your text quickly without taking your hands off the keyboard. 

*   Use `##` and `###` for headers to keep your post scannable.
*   Use standard backticks for code snippets so fellow developers can easily copy your solutions.

## 2. Structure for Readability
Developers love scannability. Avoid massive walls of text. Instead, break your thoughts down using:
*   **Bullet points** for key concepts.
*   **Bold text** to highlight critical takeaways.
*   **Numbered lists** for step-by-step instructions.

> 💡 **Tip:** Use blockquotes like this one to highlight golden nuggets of advice or important warnings.

## 3. Leverage Liquid Tags
One of the coolest features of DEV.to is its support for Liquid Tags. You can embed rich media with a single line of code. For example, to embed a GitHub repository, you just type:

`{% github github_username/repo_name %}`

## 4. Pick Your Tags Wisely
You can choose up to four tags. Make sure they accurately reflect your content. If you are sharing a fundamental concept, use `#beginners`. If it's a step-by-step guide, use `#tutorial`. This helps the right audience find your work.

## Conclusion
The best way to start writing is simply to hit "New Post" and start typing. Don't worry about being perfect; the DEV.to community is notoriously welcoming to writers of all experience levels.

What are you planning to write about for your first post? Let me know in the comments below!

Pro-Tips for Maximizing Engagement

Set a Cover Image: Articles with a clean, high-contrast cover image (1000 x 420 pixels) get significantly more clicks from the main feed. Tools like Canva or Carbon (for code screenshots) work perfectly for this.
Engage in the Comments: The DEV.to algorithm rewards active discussions. If someone leaves a comment on your post, reply to them! It pushes your post back up the feed.
Use the Preview Tab: Before hitting publish, always toggle the "Preview" button next to the editor to make sure your code blocks and images are rendering correctly.

Don’t change humanity. Open source.

Mohit — Sat, 21 Mar 2026 07:03:52 +0000

Let’s clear something up.

Open source is not a mission to save the world.

It’s not:

the next big startup
a revolutionary framework
a “this will change everything” moment

It’s just… code.

Somehow, people think:

“If I open source this, it should be impressive.”

So they wait.

“I’ll clean it first.”
“I’ll refactor.”
“I’ll make it production-ready.”
“I’ll add more features.”

And then…
It never happens.

Reality check.

Most open source projects are:

small
specific
slightly messy
solving one random problem

Not everything is trying to become React.

That script you wrote once?
That basic CRUD app?
That weird tool you made at 2AM because something annoyed you?

Yeah.
That’s open source material.
Nobody is sitting on GitHub like:

“Hmm yes, this project did not advance humanity. Reject.”

Relax.

People care about:

“does this solve my problem?”
“can I use this?”
“can I learn something from this?”

Not:

“is this world-changing enough?”

Also, your code being messy is not a disqualifier.
Every repo has:

weird naming
random hacks
“temporary fixes” that stayed forever

You’re not special.

Open source is not where perfect projects go.
It’s where projects grow.

You don’t need:

the best idea
the cleanest code
the most scalable system

You need:

a repo
a README
and the courage to hit “public”

You’re not publishing perfection.
You’re publishing progress.

Don’t change humanity.
Open source.

DSA Doesn’t Make You a Better Engineer (Alone)

Mohit — Wed, 31 Dec 2025 04:50:14 +0000

Let’s address the elephant in the interview room.

DSA is a skill.
Not a lifestyle.
Not a personality.
Not a substitute for having hobbies.

Somehow, solving algorithm problems has turned into a moral flex.

“I’ve solved 487 LeetCode problems.”

Cool.
Do you remember what you built last month?

The Cult of Problem Counts

There’s always that one person:

Solves DSA before breakfast
Tweets screenshots of green checkmarks
Treats time complexity like astrology

“O(n log n) energy today.”

Relax.

Nobody is asking you to sort an array by hand at 2AM in production.

Reality Check: DSA vs Actual Work

At work, you mostly:

Read existing code
Fix off-by-one bugs
Rename variables
Debug why this worked yesterday

Nobody says:

“Quick, find the longest palindromic subsequence before the API times out.”

The Interview Paradox

Companies:

“We want problem solvers.”

Also companies:

“Please invert this binary tree you’ll never see again.”

You pass the interview.
You join the company.

Day 1 task:
“Can you add a button?”

When DSA Actually Matters

Let’s be fair.
DSA is useful when:

You work on performance-critical systems
You deal with large-scale data
You need to reason clearly under constraints
You want to train logical thinking

That’s it.

Not because:

“FAANG requires it”
“Everyone on Twitter/LinkedIn does it”
“I might need DP someday (you won’t)”

A Healthier Way to Treat DSA

Think of DSA like the gym.

Good:

Builds strength
Improves thinking
Helps confidence

Bad:

Comparing reps with strangers
Making it your entire personality
Judging others for not going

Do some.
Stay consistent.
Don’t become weird about it.

Final Thoughts

DSA won’t save bad architecture.
DSA won’t fix unreadable code.
DSA won’t teach you communication.

It’s a tool.
Not a crown.

Learn the concepts.
Build real things.
Come back to DSA when performance actually matters.

Your codebase cares more about clarity than your longest streak.

DoodleMates: Building a Multimodal Creature Generator

Mohit — Wed, 03 Dec 2025 07:40:11 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

I set out to build DoodleMates, an app that turns any photo and personality traits into a unique 3D doodle creature.

The core functionality relies on a single multimodal API call. The key prompt I crafted was designed to leverage both image and text inputs:

"Analyze the image’s aesthetic and colors, then generate a detailed 3D doodle-style creature sticker that reflects '[User’s Personality Notes]' and matches the image’s style."

I utilized the Studio's multimodal capabilities and the Prompt Engineering interface to rapidly iterate on the visual style and consistency.

Demo

Here is a quick look at the user experience, from input to output:

Input: The user shares a photo and simple text notes.

Output: The generated, custom DoodleMate.

My Experience

Working through the Google AI Studio track offered several key takeaways and surprises:

💡 What I Learned
True Multimodal Simplicity: I was surprised by how elegantly the model handles inputs that are fundamentally different (an image and a block of text) and processes them into a unified, creative output (a new image). I didn't need separate APIs for image analysis and generation.

Prompt as Code: The process truly felt like "prompt engineering." Tweaking words like "3D sticker," "whimsical," or "charming" acted like visual parameters, allowing me to refine the product's aesthetic without touching any traditional code.

🤯 What Was Surprising
Speed of Prototyping: I was able to go from a simple concept to having a functional core engine for a highly custom, image-to-image application in less than an hour. The ability to test the API directly in the Studio environment made iterating on the perfect prompt incredibly fast. This rapid development capability is a game-changer for solo developers.

If you're looking for a quick, creative project, using Google AI Studio for multimodal tasks is the perfect way to turn pixels into personality!

DoodleMates: Building a Multimodal Creature Generator

Mohit — Wed, 03 Dec 2025 07:34:53 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

I set out to build DoodleMates, an app that turns any photo and personality traits into a unique 3D doodle creature.

The core functionality relies on a single multimodal API call. The key prompt I crafted was designed to leverage both image and text inputs:

"Analyze the image’s aesthetic and colors, then generate a detailed 3D doodle-style creature sticker that reflects '[User’s Personality Notes]' and matches the image’s style."

I utilized the Studio's multimodal capabilities and the Prompt Engineering interface to rapidly iterate on the visual style and consistency.

Demo

Here is a quick look at the user experience, from input to output:

Input: The user shares a photo and simple text notes.

Output: The generated, custom DoodleMate.

My Experience

Working through the Google AI Studio track offered several key takeaways and surprises:

If you're looking for a quick, creative project, using Google AI Studio for multimodal tasks is the perfect way to turn pixels into personality!

DoodleMates: Building a Multimodal Creature Generator

Mohit — Wed, 03 Dec 2025 07:34:53 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

I set out to build DoodleMates, an app that turns any photo and personality traits into a unique 3D doodle creature.

The core functionality relies on a single multimodal API call. The key prompt I crafted was designed to leverage both image and text inputs:

"Analyze the image’s aesthetic and colors, then generate a detailed 3D doodle-style creature sticker that reflects '[User’s Personality Notes]' and matches the image’s style."

I utilized the Studio's multimodal capabilities and the Prompt Engineering interface to rapidly iterate on the visual style and consistency.

Demo

Here is a quick look at the user experience, from input to output:

Input: The user shares a photo and simple text notes.

Output: The generated, custom DoodleMate.

My Experience

Working through the Google AI Studio track offered several key takeaways and surprises:

If you're looking for a quick, creative project, using Google AI Studio for multimodal tasks is the perfect way to turn pixels into personality!

CRUD Isn’t a Lifestyle: Stop Turning It Into a Spiritual Journey

Mohit — Wed, 03 Dec 2025 06:32:24 +0000

Let’s clear something up.

CRUD is not a religious ritual.
It’s not a PhD thesis.
It’s not the final exam before you become a Senior Engineer™.

It’s four actions:

Add a thing
Fetch a thing
Modify a thing
Remove a thing

Yet somehow developers manage to turn this into an intergalactic architecture conference.

Give someone a simple Express + MySQL task, and suddenly you’re staring at folders inside folders inside folders like you just opened a Russian nesting doll of “why?”

Symptom #1: The Onion Architecture That Nobody Asked For

A normal person:
“Can you save this user?”

A developer with too much time:
“Absolutely. First, let me introduce our 19-layer pipeline.”

And now your humble CRUD is wrapped in:

A controller
A service
A handler
A repository
A provider
A manager
A coordinator
A mysterious *utils * folder that everyone is afraid of

All so we can put a name and email into a table that has… two columns.

Congratulations, you have architected a sandwich.

Symptom #2: The ‘One Day We Might’ Disease

MySQL today.
Mongo tomorrow.
Postgres in our dreams.
Neo4j if our tech lead gets bored on a weekend.

And because of that hypothetical fantasy migration:
"You now have a database abstraction thicker than a phone book."

But let’s be honest:

Your schema isn’t portable
Your queries aren’t portable
Your team isn’t portable
Even your tech lead isn’t portable

If the database ever changes, you’re rewriting everything from scratch anyway.
Your abstraction layer?
That thing is going straight into the trash with the sprint leftovers.

Symptom #3: Turning Validation Into a Broadway Production

Form with three fields?
Cool. Should take 10 minutes.

But no.
We get:

Input schemas
Pre-schemas
Post-schemas
Meta validation pipelines
“Error sanitizers”
A whole philosophical debate about whether IDs are truly integers

Buddy.
It’s an email and a password.
Calm down.

Symptom #4: The Generic CRUD Base Class Catastrophe

A developer discovers inheritance and suddenly every resource in the system must “extend” a universal CRUD class.

At first it sounds genius:
“Everything will be reusable!”

Until every resource has slightly different rules, and now the base class looks like:
“If it’s a user: do this.
If it’s a product: do that.
If it's neither: pray.”

You didn’t reduce duplication.
You invented a glorified switch statement wearing a tuxedo.

So What Should CRUD Look Like?

Brace yourself.
This is controversial.

Just write it.

Yeah.
Directly.
In plain English.
No mystical abstractions.
No 47 folders.

A route handles the request.
A service does the work.
The database stores the data.

That’s all a CRUD needs to be.
You wouldn’t put a fork inside another fork just to eat food.
Don’t wrap CRUD in unnecessary layers.

But What If My App Grows?!

Then you refactor.
That’s the secret.
There is no prophecy demanding you predict every possible future requirement like some backend fortune-teller.

Write code that’s easy to improve, not code that tries to impress the ghosts of architects past.

Good CRUD is boring.
Boring is good.
Boring means everyone understands it.
Boring means your onboarding isn't a hazing ritual.

When Structure Actually Helps

Not all structure is evil.
Use it when it reduces noise, not when it increases suffering.

Good reasons:

You have cross-cutting rules (logging, soft deletes, permissions)
You genuinely reuse logic across multiple endpoints
The logic is complicated enough that it deserves its own home
You need real contracts, like in SDKs or shared libraries

Bad reasons:

“My code looks more enterprise this way”
“I saw a YouTube video about hexagonal architecture”
“Our app might scale”
“It feels cooler”

Final Thoughts

CRUD is not where genius happens.
CRUD is where clarity happens.
It’s the salad of backend engineering: simple, healthy, and not worth reinventing.

Save your creativity for parts of your system that actually deserve it; Not for wrapping a basic insert operation inside a spiritual quest for architectural enlightenment.

Make CRUD clean.
Make CRUD readable.
Make CRUD boring.

Your team will thank you.
Your future self will thank you.
Your database doesn’t care, it just wants the data.

He3.in – Research Workspace

Mohit — Sat, 27 Sep 2025 18:23:00 +0000

🌐 A modern collaborative platform for managing research papers. Users can create papers, add collaborators, and chat with AI to generate insights. Designed as an MVP but already functional with authentication, paper creation, collaboration, and additional feature listings.

🔗 Live: https://www.he3.in/

⛏️ Built with KendoReact components: Card, CardBody, CardTitle, Button, ButtonGroup, Grid, GridColumn, Avatar, Dialog, Input, DropDownList, TabStrip and more!!!