⚡ In a hurry? Skip straight to the rules ⚡
Don't Make the Same Mistake I Did
I have plenty of regrets, and one of them is not starting to write my own content years ago. Better late than never, as they say, but still.
I want to make sure you don't make the same mistake. Every week I see more people joining this amazing community, and it reminds me how excited I was when I first signed up back in 2018. (If you're curious how I ended up here, I wrote about it in my previous article.)
Back then, I thought writing was only for seasoned veterans. I couldn't have been more wrong. I know plenty of engineers with years of experience who still can't write a single technical article. Not because they have nothing to say, but because they never tried.
Time to Take the Leap
Trust me, you don't need decades of experience. You're fine.
Your first article will probably feel tricky, awkward and hard. Speaking from experience, though, it gets so much easier after that. And your first one will always be special, no matter how good or bad it turns out. You might cringe at it in a year or two, but that's a special kind of cringe. It's proof of how far you've come a long way since then.
Not Sure What to Write About?
You don't need a groundbreaking idea. Some of the best first articles are simple:
- A bug that took you way too long to fix, and what finally solved it
- Something you learned this week that you wish you'd known earlier
- How you got into programming
- A small project you built, even if nobody uses it
- A concept that finally clicked for you, explained the way you wish someone had explained it to you
And so many other ideas that you can think of.
If it was interesting to you, it'll be interesting to someone else.
✍️ The Rules
Alright, I'm going to be your first reader.
👉 Write your first article on DEV. Any topic, any length. Short is perfectly fine.
👉 Drop the link in the comments.
👉 Optional: tell me what finally made you hit "Publish".
I'll read EVERY SINGLE ONE OF THEM and give you honest, thorough feedback. I promise! 🤝 I always deliver whatever I promise.
One small request: write it yourself. Use AI to check your grammar if you like, but the voice and the story should be yours. That's what makes a first article worth reading.
Already a Writer? You're Invited Too
If you've been writing for a while, drop a link to your very first article in the comments, or share one piece of advice you wish someone had given you before you published it. Nothing calms first-time nerves like seeing that everyone started somewhere.
The Hall of Fame Is Waiting
A few weeks ago, I asked you to share the article you're most proud of, and it turned into the DEV Hall of Fame: 65 authors, 65 masterpieces. If you start now, your work could earn a spot when I put together the next volume.
Let's get the journey started! 🚀
Let's stay connected!
Top comments (158)
@georgekobaidze Sir, you already know my first technical article but this one is latest:
A humbling reminder that passing tests can lie
I'm Not on the DEV Team. I Still Debugged Their Missing Badges From Public Code. (And My First Test Was Wrong.)
Have A Great Day!
Thanks for sharing, I'll read it! However this one's dedicated only to first articles and first-time writers. 🙏
No worries Sir. I'll be just glad for you to read it.
Have A Great Day!
This is actually great. I'm happy you're finding these issues. That's the first step towards making this platform better.👏
Thank you for this ✊.
I built using AI a tool that can help send message locally from a device to another.
I'm very proud because I'm trying to understand better how to create automation tools to help devs
today I did my second post related to Cthrone my project:
dev.to/fiwon123/cthrone-v0191-2jio
Really interesting concept. I wonder how you'll solve the "not in the same network" problem. Well done!👏
Ty very much, rly appreciate that 🙂
Though this clearly isn't your first post, is it?😄
Not the first one, but my post I considere more. I started posting on the 25th of last week just letting you know.
My first one was more a experience then something useful: dev.to/fiwon123/my-experience-usin...
Well, this takes me back more than ten years.
kenwalger.com/blog/css/numeric-inp...
And wow, I had some typos and grammatical errors in there. 🤦♂️No editors, no AI to check things, just the ramblings of someone wanting to start a tech(ish) blog.
First on Dev.to: dev.to/kenwalger/indexing-in-mongodb
More typos and grammatical errors.
I've learned a lot over the years, not just in technology, but in the content generation and publication process.
Great article, it really shows how much difference a well-placed index can make.
It took me back to when I first started working with databases. For the first few weeks, I had no idea indexes even existed. Then I was implementing a CRUD operation, and one of the developers told me, "Hey, you can use an index there."
I looked it up, and the article I found said indexes make queries faster. My first thought was: OK, then why don't we put them everywhere? So I googled exactly that and learned about the trade-off: slower writes. Every insert or update also has to update every index on the table.
That's when I got curious about what an index actually looks like under the hood. In PostgreSQL, the default is a B-tree. It keeps the data sorted like a sorted array, so lookups and range scans are fast, but it splits the data into pages arranged as a tree. That way an insert only touches one leaf page instead of shifting everything around. Seeing that design made the whole read-vs-write trade-off click for me.
I ended up reading about indexes for the rest of the day. Good old days 😄
A truly heartening gesture! One need not be an expert to share valuable knowledge. I sincerely admire your generosity in encouraging budding writers and offering them your time. Such kindness makes a community flourish. Much appreciated!
Thank you! I’m here doing what I can to help the community.🫡
I started this blog a few months ago but in reality the thought crossed my mind more than a year ago. I found it so hard to start because I didn't know where and I thought that my articles would be kind of useless as a beginner, I even forced myself to write about something but didn't really work. At a certain point I learned about Windows permissions dev.to/encryptedscenes/windows-isn..., got so confused with terminologies, lists, etc. and I thought I could explain it in an easier way and this was my spark. This was, however, not my first post because, since I'm interested in so many things and I'm still exploring, I thought it would be kind of random to just talk about a different topic every day that aren't or don't seem related every time without explaining why. So I wrote a relatively short post to explain my journey dev.to/encryptedscenes/the-beginni.... After that, you're right, it's getting easier to write posts
I loved this article. People really underestimate how tricky Windows can be, just because it's known as the more user-friendly option compared to Linux.
Your points really resonate with me. I learned system administration back when I was a student, and Windows was sometimes even trickier than Linux. At the core level, I'd say Linux is more intuitive, and more things just make sense.
Not to mention PowerShell. I still haven't fully grasped it. It feels kind of weird to me.
Great article, thanks for sharing!
By the way, I also checked out the actual first article on your profile, and it's really good too. You write about cybersecurity and similar topics, which I find fascinating.
I'm planning to write a separate article featuring people who've shared their work with me here, with links to their first articles. Which one would you like me to include: this one or your actual first one?
Thank you for your feedback!
PowerShell should be "easier" because of the structure of commands (verb-noun) but for some reasons I always need to search for commands on the Internet or on Notion because I can't remember them. Not to mention PS modules. At the moment I haven't really practiced it yet, just learned it on the HTB Academy
I'd be fine with you choosing whichever you like or fits best your article's theme, but I'd choose the Windows one, it was the one that I first thought about and means more to me
Looking forward to reading your article!
Using Notion as a "cheat sheet" is really relatable.
Great insights, thanks for sharing those details! And keep writing, your style is really catchy and interesting.
Thank you!
"If it was interesting to you, it'll be interesting to someone else" is the line every hesitant first-time writer needs to hear. As someone who only started writing here this year, the thing that surprised me most is how kind and specific the feedback is. People don't just say "nice post", they add the tip you missed. Promising to personally read every first article is a really generous way to lower the barrier. Hope you get flooded with submissions!
Thanks! I really hope so. I want this to reach more and more people.
Thanks for encouraging! I am new here. I was searching for a community to belong too, so here I am! Next week I will publish my first article and since you promise to read, I am looking forward for my first reader😀
Hey fellow .NET dev! I’m looking forward to reading it! Take your time! Make it special💥
Here it is, as promised! :)
dev.to/yonka/modernizing-yonkadev-...
Promise delivered! You're clearly someone who lives up to expectations, and that's a valuable habit.
Now, the article itself: for a first article, I was surprised by how detailed and informative it is. So many points felt relatable.
First, as a fellow .NET developer, I know how hard it is to reach for anything other than .NET. It's our comfort zone, or happy place, where everything just feels easy. But we're software engineers first, and we should be comfortable across languages and frameworks. That's actually why most of my personal projects are in JS and Python rather than .NET... I gotta fix that though 😄
I really appreciate that you see it this way too. Good engineers don't get hung up on whatever stack they're handed, they just figure it out. And AI has made that easier than ever.
Copilot CLI was another relatable part. I won a hackathon with it, so it holds a special place in my heart, even though I mostly use Claude these days. It exceeded my expectations when I used it early this year, and I'm sure it's only gotten better since.
I also like how you walk through every step you took to reach your goal. The rubber duck agent idea is a great one.
And by the way, the website looks great. I'm a big fan of the minimalist design.
Keep writing, you're good at it, very very good!👏
Wow, Giorgi! Thank you so much for taking the time to read the article and share such thoughtful feedback! 😊
I had to smile at the .NET comfort zone part. I know exactly what you mean! And now you've made me curious about your Copilot CLI hackathon experience. 😄
I'm also happy you mentioned the rubber duck agent idea. It's something I want to explore further.
Your encouragement means a lot, especially as this is my first technical article on dev.to. There is definitely more to come!
And thank you for keeping your promise to read it! 🤗
You kept your promise, so who am I not to do the same? 😄
I'm glad my feedback was helpful to you.
And actually, that rubber duck idea is so interesting, it can make a great article only by itself.🦆
As for my Copilot experience, here it is: dev.to/georgekobaidze/metal-birds-...
Thanks for sharing, Giorgi! 😊 That's quite a long read, so I'll take some time to go through it properly. I'm curious to learn about your experience!
And you're right, the rubber duck agent might actually deserve an article of its own! 😄
Don't spend too much time on it, it's extremely technical with a lot of math involved 😄
Here's my first article (as a computer science student):
dev.to/fatimaaqaisar/what-my-termi...
Documented a little experiment I did to learn about network protocols before I had taken a computer networks course.
I'd really appreciate if you'd take some time to read. Thanks!
@fatimaaqaisar absolutely loved the article. It's technical and, at the same time, it's so interesting to follow through and read.
The reason is simple: it expresses your curiosity. Your ability to always ask the most important question: "why?"
That question is something that should always be asked, no matter what we're dealing with, not only in our industry, but in life in general. We should take absolutely nothing for granted. Absolutely love your mindset.
One of the parts that caught my attention was this:
Unsigned makes much more sense to me, since I can't think of any use for a negative TTL. I'm also surprised that slipped through in such a carefully structured and thoroughly reviewed document. Nice catch, by the way. Great attention to detail!
As for the TCP three-way handshake, I was literally about to suggest a separate article on it, and then I read your note at the end saying pretty much the same thing. You already have good writer's instincts!
This topic is extremely important for every developer to understand, because literally everything runs on it. I see more and more people skimming over it and taking it for granted, which is a really bad mistake. The moment you run into a complex problem, you have no idea where to even start. Abstractions are great because they make everything faster and easier, but we should still dig into what's going on behind the scenes.
Great job, and keep writing!
Thank you so much for such thoughtful feedback! I'm actually halfway through a Computer Networks course at this point, and most of the things I wrote in that article make far more sense now that I understand the bigger picture haha. And Ikr TTL shouldn't be negative! It was interesting to see that the inconsistency made it into the document in the first place.
I originally wrote it out of curiosity, but also partly to see whether I could actually write a technical article. I never ended up following up with the TCP handshake one, but I guess now would be the perfect time to pick it up again :)
Thanks again for the encouraging response. It really means a lot!
And yes, curiosity really is such a valuable quality. There's just so much to learn and discover.
Absolutely. We're never going to run out of things to learn and discover, so curiosity is the way to go!
cooking... in mind.
I appreciate this initiative.
Thank you!
This landed at the right moment, because we published our first article on DEV about an hour ago and were not sure it belongs here. It is a research note rather than a tutorial: what an AI agent should be allowed to do at three in the morning when nobody is awake to approve it, with sources and a few nights from our lab’s own notes. No code, no walkthrough, just the question and how we answered it. Our version of the fear was less “is it good enough” and more “is it technical enough for this place”. If anyone wants to tell us whether that kind of writing has a home on DEV, it is at dev.to/meho_ai/what-are-the-office... and we would take the feedback seriously.
Strong piece. Reframing the question from "when can the agent act" to "what operation, under whose identity" is sharp, and the lab stories make it believable. The point about guardian agents (one model grading another) is well argued too.
Thanks for sharing this!
Thanks a lot for checking it out:)
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more