Leave a comment below to introduce yourself! You can talk about what brought you here, what you're learning, or just a fun fact about
yourself.Reply to someone's comment, either with a question or just a hello. 👋
- Come back next week to greet our new members so you can one day earn our Warm Welcome Badge!
Top comments (270)
Hi! Not sure why I ended up in here... I'm a Finnish ICT student and programmer, I looove rhythym games and I love tinkering with them, especially arcade infra stuff!! I also mess around with electronics. Looking forward to meeting some awesome people here :P
Welcome!
great to be here
Welcome to the community!
wht up
Lets gooooo Jess
Welcome!
Welcome 🙂
Hey! I wasn't sure how I ended up here either, but it sure is fun :)
Welcome to DEV.to Sorsax! Hope you enjoy the community here and share some of the projects you’re working on!
hi!
Hello, Welcome to the community!
HI!
Hello :)
Welcome!
Welcome to the community
Hey, I’m Art.
An old-school developer with 30+ years of experience in software development.
I enjoy helping junior developers because I’ve made plenty of mistakes myself over the years and if sharing those experiences helps someone avoid the same traps, that’s a good thing.
Over time I’ve also built a few things of my own:
Both are part of a small software stack built on top of Godot, aimed at creating native applications without relying on large web frameworks. The idea is simple: create native applications without needing a large web stack.
One problem I keep running into is this:
Modern software stacks keep getting more complex — dependencies, frameworks, build tools, layers on layers.
Sometimes I wonder if we are solving the problem or just adding more complexity.
So I’m curious:
How do you deal with growing complexity in modern software stacks?
Looking forward to hearing your thoughts and learning from the community here.
Gah, yes!!! Too many fancy tools, too much separation from the basics.
Broken web pages because I forgot to give a type after years of using framework components rather than real HTML elements (the button was submitting and the page refreshing and wiping form entries instead of taking the correct action).
Cluttered and hard-to-read HTML because we're dropping dozens of Tailwind classes on a component rather than putting all the styles in a CSS block at the bottom of the file (I do Vue, huge fan of single file components).
Vulnerable packages identified which need resolving, turns out someone had decided to import a package just to adjust string casing because that seemed more natural to them than writing a three line function in house.
Some external frameworks and packages are truly fantastic, especially for many things datetime-related, but I do agree with you that in some places we seem to have gone waaaaaaaay too far down the road of 'bring in a tool' for just about anything.
How do I deal with? I strip out unjustified complexity where I can, and go back to basics.
Welcome to the community 👋. I get the impression you have a lot of interesting experience to share!
I do...
I am fighting the browser war since 1900. You have to support various browser and their versions. This all leads to many test cases and leaves no time for architecture thinking. Not even for coding, because you spend most of the time debugging. Im for example using ChatGPT on my mac...all fine, its a native app. Then I switch to Linux via Moolight (remote) and ChatGPT there is based on Electron, based on web tech. And often this thread is on 100% CPU waiting for a response from the cloud. Pure Horror!!
Oh, that sounds painful. You have my sympathies!
I fight it like a dying lion. I'm actually working on three FOSS projects this year to address the rising unnecessary complexity in core dev tooling. I just posted about one today.
In general, the way I approach my clients on this topic is to explain that reducing complexity is like washing your clothes. Clothes get dirty from use and have to be washed to stay fresh and presentable for a long time. Refactoring, rewriting, strangling off bad code, etc. are just washing the code from the dreck built up from (mis)use. That analogy has done more to get sign off from executives than any PowerPoint I ever made.
Washing is needed...it begans to stink otherwise
Welcome!
Truth be told everything does have a pattern it's finding those little nuances in the code that can later help you along the way.
I love diving into new Concepts and playing around with it and challenging my my self and it to be better Tehee.
🫠
Welcome to DEV, Art! Really interesting to hear your perspective after 30+ years in development.
Hey Art! 30 years and still building your own languages - respect, ser. Welcome 👋
Tbh, SML is based on QML. I just got rid of expressions. And SMS is Kotlin...just interpreted with some enhancements in event processing .
Nothing really new.
Hey folks, I'm Yves.
I spent many years as part of the first dozen employees at Berlin startups like SoundCloud and ToolTime. Good ol' times :D
I've now co-founded a small AI startup and I spend most of my days deep in technicalities, specifically agentic AI systems, and I pick up marketing, design, and business wherever I can. When I'm not traveling cyberspace, I'm usually on a cycling adventure or minimalistic camping somewhere with my family.
I write on my own blogs and plan to cross-post here. Happy to connect, and looking forward to engaging with the community :)
Also, who should I follow and why? =)
Here are a few writers that immediately come to mind: @ujja, @grahamthedev, @pascal_cescato_692b7a8a20, @ingosteinke, @rawveg, @bekahhw!
Thanks, Jess!
Thanks for the mention, Jess ❤️
Thanks for the shoutout! <3
Welcome to the community! 🥳
Whom articles you like and you want to read more of their articles. Follow them to be updated about their articles.
There are so many amazing writers here.
Thank you :) So far it feels like a great crowd :D
Welcome Yves! SoundCloud is quite a reference — curious to see what you'll write about agentic systems.
Being an early employee at SoundCloud must have been pretty neat!
Oh yea, most chaotic and creative time. And most passionate people I've ever had the chance to work with :)
Hey everyone! I'm Enis, software developer from Bosnia and Herzegovina.
Over the years I've co-founded a few things: Outecho, a software development agency, and Orren, an AI platform that helps professionals build their personal brand on LinkedIn. I also work as an AI & automation consultant, helping teams replace manual processes with systems that actually scale.
Our latest project is Lama - an AI QA agent that generates native test code from plain English descriptions. We just launched as research preview. No proprietary format, no lock-in, just real test code that lives in your repo and runs in your CI.
I'm here to write about QA, automation, and building products, and to connect with people who've felt the same pain points firsthand.
Happy to be here 👋
Hi, Enis. Welcome to the community!🥳
Outecho, Orren and Lama amazing projects and we all would love to try these out. Looking forward for your articles on QA, automation.
What were the lessons from Outecho that helped you a lot in Orren and what lessons from Outecho, Orren helped you a lot in Lama.
Thank you, really appreciate the warm welcome!
Great question, and honestly one I haven't stopped thinking about.
From Outecho to Orren: Running an agency teaches you one thing fast, most of the pain your clients feel is not unique to them. You see the same problems across dozens of companies and industries. With Orren, we weren't guessing at the problem. We'd watched professionals struggle with LinkedIn content consistency for years across our client work. The product came from real, repeated observation, not a hypothesis.
From Outecho + Orren to Lama: Two big lessons carried over. The first is distribution. Building a great product is only half the game, maybe less. We learned that the hard way with Orren and we're being much more intentional about it with Lama from day one. The second is talking to users before you think you're ready. With Lama we started getting feedback from QA engineers very early, even when the product felt incomplete. That shaped almost everything about how it works today.
The meta lesson across all three: the problems worth solving are usually hiding in plain sight. You just have to work closely enough with people to see them.
Looking forward to sharing more here! 🙏
Wow, such great learnings. You have grown quite a lot from Outecho to Lama. Hope you get even more success.
That is such a great line 'the problems worth solving are usually hiding in plain sight'. I have got to learn a lot from you. Thank you sharing such awesome learnings.
Looking forward for your articles.😊
Thank you Konark!
Hi everyone! 👋
My name is Alex (Odhiambo Alex). I'm excited to join the DEV community. I'm interested in learning more about programming, technology, and improving my coding skills. I'm looking forward to connecting with other developers and learning from your experiences.
Happy to be here! 🚀
Welcome to DEV.to, Alex! It’s great to have you here. Wishing you the best on your coding journey—this community is a great place to learn and connect with other developers.
Thank you So much Rubasri.
Hi I'm Kiyo, founder of Introlo. Will be using this platform to share what I build, what I break, and most importantly - what I learn.
Welcome!
Happy to be here!
Awesome, following!
Just posted a couple articles on this!
Welcome to DEV.to Kiyo!
Appreciate - happy to be here!
Hello, I'm Hekima (Wisdom).
As a seasoned full-stack developer proficient in JavaScript, TypeScript, and Go Lang, I specialize in crafting cutting-edge solutions for mobile, web, and tool development. With a meticulous approach to coding and a passion for creating seamless user experiences, I bring a wealth of expertise to every project. Let's collaborate to turn your ideas into exceptional, high-performance software solutions
Welcome welcome!
Welcome to DEV.to, Hekima! Your experience across JavaScript, TypeScript, and Go sounds impressive. Looking forward to seeing the projects and ideas you share with the community here!
Thank you so much.
Welcome, everyone!
Hey!
I'm Andrea, a web developer from Italy.
Mostly self-taught, I work mainly with Vue on the frontend. Recently I started learning React — vibe coding is making it much less intimidating than I expected.
I like building products and tools that solve real problems.
Happy to be here and learn from everyone.
Hi, Andrea. Welcome to the community!🥳
Well great on being a self-taught programmer. So, what are the similarity and differences you found about Vue and React?
Thanks Konark!
From my experience, the biggest difference is the learning curve and where each one shines.
Vue feels very natural if you come from HTML/CSS and basic JavaScript. The template syntax is close to regular markup, the reactivity system is intuitive, and you can be productive quickly without deep JS knowledge. I've used it mostly for headless ecommerce frontends and platforms where the UI is interactive but not extremely complex — product catalogs, dashboards, multi-step forms. Vue handles that sweet spot really well.
React feels more powerful for highly interactive interfaces — complex state management, lots of components talking to each other, real-time updates. But the mental model (hooks, JSX, the "everything is JavaScript" approach) is harder to pick up if you're not already comfortable thinking in JS.
The interesting thing is that vibe coding is kind of erasing this gap. When you can describe what you want and the AI writes the component, the framework's complexity matters much less. I'm building things in React now that would have taken me weeks to figure out on my own — not because React is hard, but because the boilerplate and patterns are handled by the AI. It's making every framework accessible to everyone, which I think changes the whole "Vue vs React" debate.
Wow, Andrea. You have precisely explained everything pretty well. I mostly work with React so wanted to know the difference. Thanks for making it clear.
Yeah, You are right. Vibe coding bridges this gap and handles the boilerplate and patterns pretty well. What were the challenges you faced while vibe coding?
Thanks Konark! Good question.
The biggest challenge for me is context loss. When a project grows beyond a certain size, the AI starts forgetting decisions it made earlier — naming conventions, state management patterns, even the architecture it chose 20 prompts ago. You end up with inconsistencies that you only notice when something breaks.
My workaround: I keep a RULES.md file in every project with the key decisions ("we use composables for shared logic", "all API calls go through /services", "state is managed with Pinia"). I paste it at the start of every session. It's manual, but it keeps the AI aligned.
The second challenge is debugging. When the AI writes code you don't fully understand, debugging becomes harder. You can ask the AI to fix it, but sometimes it fixes the symptom and introduces a new bug somewhere else. I've learned to always read the code the AI generates before accepting it — even if it takes longer, it saves time in the long run.
The third one is over-reliance. It's tempting to let the AI handle everything, but then you stop learning. I try to use vibe coding for the parts I already understand conceptually (so I can verify the output) and do the new stuff manually first, then refactor with AI help. That way I actually learn React instead of just generating React.
Honestly though, the benefits massively outweigh the challenges. I shipped things in days that would have taken weeks before.
Yea, Ofcourse that was my go to challenge as well. The more complex your projects gets the more AI forgets decisions and try something new. I have tasked my AI to break the task into small task and don't move forward till I tell it to. This makes the code for me to handle without breaking loose. Your workaround sounds good to would love to try it in my next session.
Debugging is another issue. When I used the code to generate my portfolio it was a big match with AI. There were so many small details that I asked AI to modify but it started hallucinating and even after multiple attempts the problems remained the same. But I have to debug it myself and modify the AI generated code to my likings.
Yeah, over-reliance. I heard this news of a company recently who used AI to combine two products and the AI deleted the database and saved checkpoints of database and made a fresh start for both products.
Yeah keep breaking and building projects on your learning journey.
Ha, the "break into small tasks" approach is solid — that's essentially what keeps the AI focused. And yeah, the portfolio debugging story is painfully relatable. At some point the AI is just confidently rearranging the same bug.
That database story is terrifying. Good reminder to never let AI touch anything destructive without human confirmation.
Great chat, Konark.
Hello. Long-time builder in healthcare, machine learning, natural language processing and AI. I'm a big scifi and music nerd and love to build stuff that will make people's lives a bit better and safer. Here to share, help and encourage.
A lot of people know me for my work in digital health innovation, which I did for about 20 years. What drove my curiosity in that area was an ongoing interest in how technology changes the relationship between humans and systems.
Now I spend my time building tools to help us thrive in the autonomous AI era.
What's different now: the systems we build don't just serve humans anymore. They serve agents too. And agents interact with software completely differently than humans do—no visual interfaces, just structured data, schemas, and programmatic discovery.
This creates design and engineering challenges nobody taught us about. We've spent 40 years building for humans with eyes and hands. Now half our users are machines. My last post on dev.to went into this a bit more.
Looking forward to learning from the community!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.