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 (657)
Hey all. Welcome to DEV and thank you for choosing this platform!!
As mention on my last week thread message and the week before that, I am waiting on introducing myself to the welcome thread (properly) @javz 3 more weeks till Welcome Thread v400!
In other case, what brings you on DEV? Any good projects you are working on?
Hello! I'm here to learn, share what I discover, and connect with fellow developers! Currently exploring new ideas and building projects to sharpen my skills. Looking forward to learning from the community and sharing my journey along the way!
Hi! I have exactly the project you're looking for to learn from basic to advanced levels, along with a helpful roadmap for beginners. I'll be publishing it right nowโif you're interested, feel free to check out my profile.
hello
Hello
hello
Hii
hello
Welcome, Achmad! Same goal here: learning out loud. What kind of projects are you building right now? Always curious what people pick to sharpen their skills on.
Thanks for the welcome! I came here to share my first post โ how I got YouTube transcripts working on a cloud server. The project behind it is Linkee, an app that turns long articles and videos into short summaries you can read or listen to. Good luck with the countdown to v400!
Hey Francis, thanks for keeping the welcome thread going! ๐
I'm working across software engineering, AI systems, and developer tooling at Ghost Labs, and lately I've been exploring Rust. What kinds of Rust projects or topics have sparked interesting discussions here recently?
Hey Genadi! Welcome to DEV!
Haven't seen a lot of Rust projects on DEV lately. A lot of people have been initiating discussions about AI. Speaking of, reverse engineering using AI has been the hot topic in general right now. Many games are being fused together into one, and a person reverse engineered adobe to make their own and open sourced.
Hope your journey goes well!
Hey, thanks for the warm welcome! Yeah, AI-assisted reverse engineering is a really interesting space right now. AI can be incredibly useful for exploring ideas and speeding things up, but I think knowing when to verify its output is just as important, especially when things get technically complex.
Definitely an exciting time to be building in this space. Appreciate the kind words!
Hallo ๐ซ
Hello!
Hey Francis!
Hi Francis๏ผit's glad to be here to share my post and appreciation๐
I have been studying software engineering or a while now, I said its finally time to connect with others like me, and share Ideas and knowledge. So that's why I am here
Hello Francis!
Hello
Hello!!
Hi Francis! I'm here to start writing about what I build: AI chatbots, data tools and full-stack apps, mostly for customer support teams, since that's my day job. My first post was about the two-theme time machine on my portfolio. This week I'm trying the Hacktoberfest open-source AI challenge with Gemma. Are you doing any of the HF26 challenges?
hello all. Im quite new to this opensource space yet i really like to contribure more to it. And i really love the concept of opensource. I would really like to connect with lot of developers and do lots of great projects.
Hey!,Welcome to the community! It's great to see your enthusiasm for open source. I'm also learning and looking forward to exploring new things, contributing to projects, and connecting with fellow developers. All the best on your open-source journey!
Hello!
Hello ๐
Hello!
Hello :)
hey !!
hi!
Hola
Hello ๐ซ
Hey_y_y!
hi!
hello!
Hi! This feels like a really friendly place. Iโm building a remote job board and have run into a lot of gotchas along the way, so Iโm planning to share them here.๐
helllo
Welcome aboard! Hope you enjoy the community. Looking forward to reading your posts. ๐
Hello!!
Heyya!
Hi
hello
Hi everyone!
Welcome to the dev.to-community!
I'm Martin, and I worked as a Senior Front-End Architect and Engineering Manager at some of the world's largest digital agencies, where I led front-end teams on international projects. After 15 years, I left.
Now I travel the world as a professional scuba diver and work as a contracted Tech Lead, Solution Architect, and technical Recruiter for international clients. Additionally, I write about technology on dev.to and Golem (German).
That is my advice for everyone. Jump right in. Start writing! Today! That's how I became a published author for No Stach Press and Packt Publishing - who knows what's waiting for you?
My latest book Claude Code Beyond the Prompt will be available in November. Over the next few weeks, I'll run a series on dev. to revealing the chapters one-by-one. Take a look :)
If I have enough time, I write more in-depth articles and thought pieces here on dev.to, for example: Toward Agent Native Development.
My first book, The Complete Developer, is an easy, hands-on introduction to building web applications with Next.js, MongoDB, and Mongoose. It is part of multiple university syllabi in the USA and India - you can get it from No Starch Press
I recommend following the general tags webdev, ai , career and productivity and javascript, react, CSS. Head over to your Dashboard and adjust the tag weight to personalize your home feed.
Here's a list of articles to start your journey as a successful developer and a great writer:
If you are looking for your next job, I highly recommend buying the Book De-Coding the Technical Interview Process by Emma Bostian. It is hands down the best preparation for every technical interview.
If you're interested in my articles, have questions, or want to get in touch, don't hesitate to contact me on dev.to/martinkr
And remember to start posting today!
Cheers!
Hey Martin! ๐
Transitioning from 15 years in agency leadership to balancing freelance tech lead work with professional scuba diving is such a cool journey. Talk about mastering work-life balance!
I really appreciate how consistently you encourage newcomers to start writing and sharing their journey early. With your experience mentoring and authoring The Complete Developer, whatโs the single biggest barrier you see developers face when shifting from just consuming content to actually publishing their first post or open-source contribution?
Great having your perspective in the thread! ๐
Thank you for asking. The biggest single barrier "is not doing it". You will only improve a skill by using it. Write a ticket, raise a PR, publish a Library - don't hesitate; do it. Do it yourself, not ask an LLM, and you will learn something every time.
Couldn't agree more, Martin. The friction of wrestling with an issue and figuring it out yourself is where the actual muscle memory gets built. Shortcuts just don't teach you how to think through the messy edge cases.
Really appreciate the grounded perspective and the push to just build!
Ola Martin!
Loving the work-life balance piece, it's great to see more and more of this, hallelujah!
Iโm Cyrille ๐ซ๐ท a developer for 20 years, mostly RoR. Interested in our relationship to machines, the good and the bad ๐
Iโm here to read, swap stories, and hear how others are handling these wild changes!
Hi
hello
Hi
Hi Martin!
Such an impressive articles and books list - will explore with pleasure!
Komme auch aus Deutschland:)
Wow, a lot of recommendations, thanks for your help.
I hope to learn a lot from the people in this community, have a great day.
hi martin
Hi everyone! Iโm Yutaka Hirata, an independent app developer and technical author based in Japan. I currently develop Windows and Android apps and self-publish technical books on Kindle in Japanese and English. My introductory book on Linux device drivers has been selling quite well, which has been encouraging. My background is in low-level software, including device drivers and embedded systems.
These days, Iโm especially focused on YuHex, a Windows hex editor I originally built as a hobby. Iโve just published my first DEV post about how it became a business project.
Iโm looking forward to sharing what I learn and hearing about what youโre building. Nice to meet you all!
Hi Yutaka,
Welcome! Going from a hobby hex editor to a business project is a great story, and Iโll read your post. I work at the other end of the stack (web and AI backends), so low-level work like device drivers fascinates me. What was the hardest part of making that shift with YuHex?
Thank you for the warm welcome and your interest in YuHex!
My background is mainly in low-level software development, including device drivers, firmware, and BIOS. Developing a Windows desktop application has been a different kind of challenge, especially when it comes to UI design and usability.
But I think the hardest part was shifting my mindset from hobby development to running a business. As a hobbyist, I could work on whatever interested me, whenever I wanted. Now I have to think about users, ongoing maintenance, pricing, and how to keep the project sustainable.
It's a new experience for me, but I'm enjoying the challenge!
Welcome to DEV, Yutaka! ๐
It's fantastic to see experienced systems engineers bringing deep, low-level expertise to the platform. Writing technical books on Linux device drivers is no small feat, and turning a passion project like YuHex into a commercial product is a journey so many indie developers aspire to take.
When transitioning a hex editor from a personal hobby to a business tool, what turned out to be the biggest hurdle - handling large file memory mapping / binary rendering performance, or the shift toward packaging and licensing?
Thank you for the warm welcome and your kind words!
Both the technical and business sides have been challenging, but in different ways.
On the technical side, handling very large files has been an interesting challenge, especially working around the limitations of the Windows scrollbar.
YuHex follows a freemium model, offering both a free version and a paid version. However, I'm still not sure whether this was the right business model. Since YuHex is a Windows desktop application, I didn't want to include advertising.
On the business side, packaging and distributing YuHex through the Microsoft Store was a completely new experience for me. Pricing and finding a sustainable way to continue development have also been challenging.
But the biggest challenge has actually been multilingual support. If I'm going to develop software, I want to make it available globally, not just in Japan. Supporting different languages, including right-to-left languages, has turned out to be more complicated than I initially expected.
It's been a learning experience, both technically and as an independent developer!
The Windows scrollbar limitation is such a classic Win32 battle! Mapping multi-gigabyte 64-bit offsets to standard scrollbar ranges requires some seriously creative virtual scrolling math.
Also, hats off to you for tackling RTL support. Bidirectional text mixed with fixed-width hexadecimal offsets and raw ASCII/Unicode inspection buffers is notoriously tricky to render cleanly without breaking column alignments.
Avoiding ads was definitely the right call for an engineering utility like YuHex. Developers value lightweight, distraction-free tools, and freemium aligns much better with long-term trust.
Have you found the Microsoft Store helpful for organic discovery outside Japan, or are most users coming directly from your technical articles and book readership?
Thank you for another thoughtful comment!
To be honest, the Microsoft Store hasn't been very effective for organic discovery so far. YuHex gets very few page views, and the reality is that most potential users probably don't even know it exists.
I've made a few sales, but nowhere near enough to call it a commercial success. In fact, I haven't even received a payout yet!
I also use X (Twitter), but my audience there is almost entirely Japanese, so it hasn't been very effective for reaching users overseas.
I've put a lot of time and effort into multilingual support, including RTL languages, because I want YuHex to be used around the world, not just in Japan.
That's actually one of the main reasons I started writing on DEV and Medium: to reach developers outside Japan and hopefully introduce them to YuHex.
At this point, I'm more interested in getting people to try the software than in making money from it. Even if they only use the free version, I'd be happy.
More than anything, I just want as many people as possible to use something I've built!
The Microsoft Store is notoriously brutal for organic discovery. Without existing search intent or external marketing, desktop utilities get completely buried.
Writing on DEV and Medium is honestly the exact right pivot. Developer tools rarely gain traction through app store browsing; they grow through engineering storytelling. If you publish posts breaking down the specific, tough engineering hurdles you solved, like working around Win32 scrollbar limits for 64-bit offsets, or how you solved RTL rendering in a fixed-width binary grid - the right niche (embedded engineers, reverse engineers, systems hobbyists) will discover YuHex naturally through search and community feeds.
Also, have you considered submitting a manifest to
winget(Windows Package Manager) alongside the Store? Many developers prefer installing utilities viawinget installin terminal rather than browsing the Store app.Thank you for the detailed suggestions!
Writing about the technical challenges behind YuHex sounds like a great idea. I've spent a lot of time dealing with large-file scrolling and multilingual support, including RTL languages, so there's definitely material worth sharing.
I hadn't seriously considered winget as another distribution channel. I'll look into it.
I really appreciate your advice and encouragement!
Hi John, a quick update on your winget suggestion!
I've added instructions for installing and managing the paid Microsoft Store edition of YuHex using winget:
yutakasan.11ya.net/winapps/YuHex/s...
I'm also working on making the free edition available through winget. I've submitted a pull request to the official winget-pkgs repository, and it's currently awaiting review:
github.com/microsoft/winget-pkgs/p...
Thanks again for the suggestion! It encouraged me to take action.
That turnaround speed is seriously impressive, Yutaka!
The new documentation page with the
--source msstorecommands is super clean, and getting the free edition merged into the officialwinget-pkgsrepo will make a huge difference for CLI-first developers.Fingers crossed for a smooth PR review, and wishing you all the best with YuHex! ๐
Hello and welcome to dev.to Community ! ๐๐ผ๐
Hi everyone! I'm Hamza. I've been building small web tools with Next.js, and lately I've been working with MediaPipe FaceMesh to measure facial proportions directly in the browser, without uploading the photo anywhere. Looking forward to learning from this community and sharing what I've figured out along the way.
Welcome to DEV, Hamza! ๐
Running MediaPipe FaceMesh purely client-side is a huge win for user privacy. People definitely appreciate biometric data staying on their own device.
How has the landmark detection performance held up across mobile browsers - did you run into any thermal throttling or frame-rate drops?
Thanks, John! Good question. In my case it turned out to be easier than I expected, because the tool works on a single photo rather than a live camera feed. It runs FaceLandmarker in IMAGE mode, detects once and stops, so there is no frame loop running long enough for thermal throttling or frame drops to show up.
The costs I did hit were elsewhere:
If I ever add live camera tracking, throttling would become a real concern, and I'd probably cap the frame rate and run detection on every other frame. Have you seen good results with that approach?
That lazy-loading setup with dynamic imports and the CPU fallback is really smart. Keeping the initial bundle lean and handling inconsistent mobile WebGL/GPU delegates via try/catch saves so many headaches.
Regarding live tracking: yes, running detection on every 2nd or 3rd frame (or capping inference at 10โ15 FPS) is the standard and works extremely well. In practice, you can let the camera feed render smoothly at 60 FPS while decoupling the inference loop using
requestVideoFrameCallbackor anOffscreenCanvasinside a Web Worker. For facial proportion tracking, users won't notice the lower inference rate, but their phones will definitely thank you for avoiding thermal throttling.Really appreciate you sharing the breakdown of the real-world constraints. Great engineering decisions!
Thanks, John, that's really useful. Decoupling the camera render from the inference loop with requestVideoFrameCallback is exactly the piece I was missing, and moving detection into a Web Worker with OffscreenCanvas would keep the main thread free for the UI too.
For proportion measurements specifically, a lower inference rate might even help: averaging the landmarks over a few frames should smooth out the small jitter that a single frame has, which matters when you're measuring differences of a fraction of a percent. Something to try if I build a live mode. Appreciate you sharing this!
Hi everyone! ๐ I'm Vitalii, a Java developer from Ukraine.
I love new features and new trends. I learn something new, try it for real, and write about it here. Lately that means Java + AI (RAG, MCP, LangChain4j), PostgreSQL internals and modern JVM stuff โ
When I'm not writing backend code, I make games ๐ฎ
Happy to be here, and looking forward to reading your posts!
Welcome to DEV, Vitalii! ๐
Great to see more developers pushing the boundaries of the modern JVM and AI - the ecosystem around LangChain4j and MCP is evolving fast, and enterprise teams definitely need hands-on architectural patterns that go beyond quick Python prototypes.
How has your experience been integrating LangChain4j into production-grade pipelines, especially around connection pooling and memory overhead when managing RAG context?
Thanks! My RAG app is still a local project (Spring Boot, Ollama, pgvector), not production yet. So far, regular Postgres connection pooling works fine. To keep memory low, I limit chat history and the amount of retrieved text. Have you used LangChain4j in production?
Hi everyone! ๐
I'm Muzammil, founder of Tickin, which is HR, attendance, payroll, projects and productivity, all running inside Slack and Microsoft Teams. After years in dev and ops, I got tired of watching HR tools gather dust because nobody opened them, so I set out to build one that lives where teams already work, which is their chat.
Tickin covers the whole workday: clocking in, leave, payroll, project time tracking, productivity insights, and even built-in video meetings with Tickin Meet, all without leaving the chat your team already uses.
I'm here to share what I learn building a bootstrapped SaaS, like the two-platform Slack/Teams problem, zero-downtime deploys on a single server, multi-tenant headaches, and the occasional win. Just published my first post on why we put HR inside chat instead of building another app.
Fun fact: I went from writing backend code to writing cold-call scripts and SEO briefs this month. Founder life is a crash course in everything ๐
Looking forward to learning from this community!
Welcome to DEV, Muzammil! ๐
Solving the "HR tool graveyard" by embedding workflows directly where teams already spend their entire day is such a smart move - context switching is the real adoption killer.
Managing feature parity across both Slack and Microsoft Teams must be quite a technical challenge, especially juggling Block Kit vs. Adaptive Cards and differing platform rate limits. Are you abstracting the messaging UI into an internal schema, or maintaining separate rendering pipelines for each chat ecosystem?
Thanks! And you've pointed at exactly the call that shaped everything.
We went with one internal schema, not separate pipelines. The worry was that two pipelines drift the moment you ship to one platform first, and then Teams is always a few features behind Slack.
So the core logic (clock in, approve leave, overtime) doesn't know or care which platform it's on. Each one just has a thin adapter that turns our schema into Block Kit or Adaptive Cards, and handles its own inbound quirks.
Rate limits we solved with a per-platform queue, so a burst of posts to a big Slack workspace doesn't trip limits while Teams sits idle.
Honest downside: the two don't map 1:1 (modals, some inputs), so now and then a feature needs a platform-specific branch. Keeping that the exception has kept us sane.
What are you building?
Hey everyone!
I'm a .NET developer with over 10 years of experience, mostly working with enterprise applications and some pretty large legacy systems.
I've always enjoyed programming and trying to find better ways to solve problems. Recently I've been spending a lot of my time working on my own project called NSystem Intelligence, a tool I'm building to help developers analyze their .NET projects and find possible improvements.
I'm still working on it and learning a lot along the way.
I joined this community to share some of my work, learn from other developers and hopefully get some feedback on what I'm building.
Looking forward to chatting with you guys! ๐
Welcome to DEV, Sebastiรกn! ๐
With over a decade navigating enterprise .NET and large legacy systems, you definitely know where the real architectural landmines hide.
A tailored tool like NSystem Intelligence sounds incredibly useful. Are you leveraging the Roslyn compiler platform under the hood for static code analysis, or focusing more on dependency graphs and architectural debt?
Hey, thanks for the welcome!
I'm actually doing both. I'm using Roslyn for static code analysis, things like code complexity, maintainability and detecting potential issues in the code.
But I'm also focusing quite a bit on architecture and dependencies, trying to identify things like circular dependencies, architectural violations and how the architecture changes over time.
The idea is not just to show metrics but to help developers understand what could be improved and why.
I've also added optional AI assistance to explain some of the findings and suggest possible improvements.
It's still a work in progress though, and I'm trying to get some feedback from other .NET developers to see how useful the analysis actually is on real projects.
Focusing on explaining why an issue matters rather than just dumping raw metric dashboards is a game-changer. Most static analysis tools fall out of favor because teams get alert fatigue from abstract complexity numbers without actionable context.
Tracking architectural drift and circular dependencies over time is huge, especially in evolving enterprise solutions where domain boundaries blur gradually across sprints. Using optional AI specifically to explain structural violations and suggest refactoring steps makes total sense here.
Hey everyone! I'm Ojaswin, a software engineer who enjoys building things, solving engineering problems, and exploring how technology works under the hood.
I'm particularly interested in AI engineering, LLM-powered applications, backend development, and distributed systems. I enjoy experimenting with new technologies, building practical projects, and learning by getting my hands dirty with code.
On DEV, I plan to share my learning journey, technical discoveries, project breakdowns, debugging experiences, and lessons from building real-world applications. I believe the best way to learn is to build, question, experiment, and share what you discover along the way.
I'm also looking forward to connecting with fellow developers, learning from the community, and contributing wherever I can.
๐ GitHub: github.com/Ojaswin30
Looking forward to learning and building with you all. Let's connect!
Welcome to the DEV community, Ojaswin! ๐
The intersection of distributed systems and LLM engineering is such a fascinating space right now - especially when it comes to tackling latency, state management, and actual system reliability under load.
Your plan to share debugging stories and project breakdowns is spot on; some of the absolute best reads on DEV are candid post-mortems showing what broke, why it broke, and how you fixed it.
What kind of backend or AI architecture are you experimenting with at the moment?
Hi, I'm Alessio, software dev from Italy. Joined for the Hacktoberfest AI challenge and just wrote up a weekend projectโbuilt a small local receipt parser with Ollama to stop manually typing invoice data into spreadsheets: ledgerlocal
Welcome to DEV, Alessio! ๐
Always great to see folks building practical, offline-first tooling around local SLMs and Ollama rather than defaulting to cloud APIs.
Whatโs been your biggest takeaway so far regarding the latency vs. precision trade-off when running models directly on client hardware?
Looking forward to your posts around here! ๐
Thanks! Honestly, 3B models like phi4-mini are plenty fast (2-3s per doc), but they get tripped up by layout quirksโlike mistaking the customer for the vendor on Italian receipts.
Instead of moving to a heavier model that kills battery and takes 20s, I found it way better to stick with the small model and just patch the edge cases with regex and a quick edit UI. Fast SLM + deterministic code in front of it seems to be the sweet spot.
That hybrid approach is spot on and so underrated.
Pairing a lightweight SLM with deterministic post-processing and a quick UI beats throwing brute compute at the problem every time, especially on client hardware where thermal throttling and battery life actually dictate UX.
Getting 95% of the extraction done in 2 seconds with deterministic guardrails is the exact kind of pragmatic engineering more teams need to adopt. Would love to read a full case study or architectural breakdown on that if you end up writing one!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.