We hear it all the time in tech.
Everyone starts somewhere. There are no stupid questions. Don't be afraid to ask for help. Keep learning.
And I agree with all of that.
But I've been wondering lately, are we actually as welcoming to beginners as we like to think we are?
Because telling someone they're welcome is one thing. Making them feel comfortable enough to actually participate is another.
The fear of asking a stupid question
When I first started learning to code, I was pretty nervous about asking questions.
I wasn't necessarily worried that someone would be outright mean to me. I was more worried about looking like I had absolutely no idea what I was doing.
Which, to be fair, half the time I didn't. That's kind of the point of learning something new, right?
But that didn't stop me from overthinking things.
What if this is something I should already know? What if the answer is ridiculously obvious? What if someone wonders why I'm even trying to build things when I don't understand something so basic?
I can't imagine I'm the only person who's ever felt that way.
And apparently, I'm not.
I was looking through the 2026 Stack Overflow Developer Survey, and a couple of numbers caught my attention.
21.1% of respondents said they worry about being judged or criticized when participating in technical or professional communities.
Another 20.1% said they don't feel confident asking questions publicly.
Now, these numbers aren't specifically about beginners. They're from respondents more broadly, and I don't want to misrepresent that.
But still, roughly one in five people answering that question are worried about what others might think of them.
That's a pretty significant number of people who might have something to ask, share, or contribute but hesitate to do it.
It makes me wonder how many people are reading discussions, learning from everyone else, and never saying a word because they're afraid they'll look stupid.
You can correct someone without making them feel stupid
I want to be clear about something. I'm not suggesting we should stop correcting people or pretend everything everyone does is amazing.
That wouldn't help anybody learn.
I've made plenty of mistakes, written some questionable code, and probably approached things in ways that would make a more experienced developer scratch their head.
And I'm sure I'll continue doing all three.
But there's a difference between someone explaining why your approach might not be the best and someone making you feel stupid for trying it in the first place.
You can point someone toward documentation without the whole "Did you even bother reading the docs?" attitude.
You can disagree with someone without turning it into a contest over who knows more.
And you can give someone honest feedback without making them regret asking for it.
I think sometimes people forget how intimidating tech can be when you're new.
Things that seem completely obvious to someone who's been programming for ten years might be something a beginner has spent the last three hours trying to figure out.
And sure, maybe the answer really was in the documentation the whole time.
We've all been there.
But nobody learns everything overnight, and making someone feel stupid isn't going to help them learn any faster.
What about women in tech?
This is another part of the conversation I'm interested in.
I'm a woman who builds things and is still learning all the time, and I can genuinely say that a lot of my experiences in the tech community have been really positive.
Especially here on DEV.
I've met some wonderful people, received helpful feedback, and had other developers encourage me to keep building and sharing my projects.
And I appreciate that more than I probably say.
But getting comfortable enough to put my work out there in the first place? That took some courage.
I'm naturally someone who second-guesses herself, and when I first started sharing my projects, I was constantly wondering what people would think.
Was my code good enough? Was what I built even worth sharing? Would more experienced developers look at it and wonder why I was so excited about something they could probably throw together in an afternoon?
Looking back, I probably worried about those things a lot more than I needed to.
But here's where I get curious.
How much of that hesitation comes from being a beginner? How much comes from personality? And for women, is there sometimes another layer to it?
I can't honestly say I've experienced some terrible amount of sexism in tech, because I haven't. At least not in the communities I've been participating in.
But I also know that my experience doesn't represent every woman's experience.
I'm curious whether other women have felt like they needed to prove they knew what they were talking about before anyone would take them seriously.
Or whether they've noticed people making assumptions about their abilities.
And I'm just as interested in hearing from women who've had really positive experiences.
I don't think this is a conversation where we should assume everyone has had the same experience, because obviously we haven't.
That's what makes it worth discussing.
Finding your people makes a difference
Something I've learned since I started sharing my work is just how much the right community can change things.
There are places on the internet where asking a basic question feels like you're volunteering to be publicly roasted.
And then there are places where people are genuinely excited to see what you're working on, even when it's something small.
I've been lucky enough to find more of the second kind.
When I first started posting on DEV, I was nervous.
Now I'm sharing projects, writing articles, participating in discussions, and occasionally posting something before I've had enough time to talk myself out of it.
Progress!
And it's not because I've suddenly become some expert who knows everything.
Trust me, I definitely haven't.
I look things up constantly. I make mistakes. I run into problems that leave me staring at my screen wondering what I did wrong.
But I've learned that I don't need to know everything to have something worth contributing.
Sometimes you share something you've built and someone teaches you a better way to do it.
Sometimes someone else is working through the exact same problem you just figured out.
And sometimes a little project you're proud of inspires another person to try building something of their own.
That's the kind of interaction that makes people want to participate.
We have to do more than say beginners are welcome
I don't think tech is some universally hostile place where everyone is waiting to tear beginners apart.
There are so many genuinely kind, helpful people out there, and I've met quite a few of them.
But I also think there's room for improvement.
We can tell beginners to ask questions all day long, but if the response they get makes them wish they'd kept quiet, what good does that do?
We can encourage people to share their projects, but if we immediately dismiss anything that isn't particularly advanced, we're not exactly giving them a reason to share the next one.
And I think it's worth remembering that something simple to you might be a huge accomplishment to someone else.
Maybe it's their first working app.
Maybe it's the first bug they managed to track down on their own.
Maybe they finally understand something that's been confusing them for weeks.
That excitement is real, even if the accomplishment seems small from where you're standing.
I still get excited when I figure something out that I probably should have understood ages ago. And I'm not planning to stop anytime soon.
I think most of us can remember what it felt like when we were first learning something completely unfamiliar.
We just need to remember that feeling when we're the ones with a little more experience.
Because a welcoming community isn't really defined by what it says about beginners.
It's defined by how it treats them when they actually show up.
I'm curious what everyone else thinks
I'd really love to hear about your experiences, especially if they've been different from mine.
- When you were first learning, did you feel comfortable asking questions or sharing your work?
- Have you ever avoided participating in a community because you were afraid of being judged?
- For women in tech, do you feel your experience has been any different, good or bad?
- Are there particular communities that made you feel genuinely welcome?
I know my experience is only one perspective, and I think hearing from people who've had both positive and negative experiences could make for a really interesting discussion.
After all, if we want tech communities to be welcoming, it probably helps to listen to the people we're trying to welcome.
Top comments (26)
I use to avoid going into communities because of the notion of being judged and criticism. I realized that at some in your life, it's going to happen anyway knowing how you feel about it.
What I learn is in order to overcome it, you have to be exposed to it. Obviously not in a reckless way, but in a healthy way.
People come and go, and I can guarantee you will find someone. If not, you will have to keep looking. You only fail if you decide to give up.
I think you're right that we can't completely avoid criticism or judgment, and sometimes the only way to get more comfortable is to put ourselves out there. That's definitely something I've had to learn myself. And I totally agree on finding the right people. Every community is not going to be the right one for everyone. Finding that community where you feel comfortable learning and interacting makes such a huge difference. I'm really grateful to have found that here on DEV. The support and encouragement I've received from this community have helped me become so much more confident about putting myself out there.
I was so apprehensive to start sharing and still am, though less so. I put my first article up to the void on Dev.to and waited to see what happened...and crickets. lol But it was out there and I did it and it gave me comfort to post the next one and then the next. And when I got my first interaction, it was about traditional computer science and IT paths to building which I didn't have and I was scared to disagree. Because I did! It ended up turning out alright and I learned that sharing perspectives and ideas that differ doesn't have to become an argument and can lead to learning. I just feel very lucky to have found this Dev.to community which has been so welcoming and has given me such a safe space to explore my writing and builds. Thank you for this article!
It's two different things when someone enters, or will enter, the profession and when they become involved in the community. Personally, I was born not long before we landed on the Moon. I've also spent 40+ years in IT, and fortunately — so it's not just the beginners who get to speak — I haven't lost my momentum yet. In fact, the dev.to community has been quite inspiring for my creativity. And that absolutely includes helping beginners. That's exactly why I created the Terminal is your Friend app for my TS+|> fork. Here, anyone can get help while learning to code — and actually try things out in practice — even when there's nobody around to ask, or they're simply too shy to ask. So here on dev.to, I've become comfortable enough that I'm no longer embarrassed to share my work. I also know it only reaches a small number of people, but that's part of the game.
Anyway, whenever someone asks me something, there's a good chance I can show them not only an answer but also an article I've written that's somehow related to their question. So online, there's no difference between boys and girls, at least from my point of view. It's also completely secondary which part of the planet someone happens to live on. Of course, in certain contexts these things matter too, but basically, here in IT, they don't. I can only encourage everyone to show their work and not be afraid.
And finally, my CV advice is the Single Line CV.
I like what you said about the difference between telling beginners they're welcome and actually making them feel comfortable enough to join in. I think how we respond to someone's question matters more than we sometimes realise. A kind response can encourage someone to keep learning, while a dismissive one might make them think twice about asking again. And your point about celebrating the small things really resonated with me. What seems like a small step to one person might have taken someone else hours to figure out. It's easy to forget that when we've been doing something for a while ourselves. Thanks for bringing this up, Jessica! 😊
Thank you, Shubhra. I really appreciate this comment. I agree that the way people respond can make a really big difference in whether someone feels encouraged to keep learning or starts holding back. And yes, that part about small wins really matters to me too. It’s so easy to forget that something that feels simple now may have taken someone else a lot of effort and persistence to figure out. I’m really glad the post resonated with you.
You named the exact fear that keeps a lot of good beginners quiet, and your own story shows the way through it. Nobody remembers the first question you asked. They remember whether you kept showing up, listened to the correction, and came back with a better attempt next time. Asking a clear question, what you tried, what happened, what you expected, is a skill in itself, and it is one hiring managers notice.
The part about having to prove you know something before anyone takes you seriously is real, and it is where a lot of beginners get stuck. A certificate alone does not settle that question, and honestly no IT certification is needed to start. What settles it is showing work someone else can judge: a problem you handled, the decision you made, and what happened as a result.
That is the same gap I see on the IT and security side. The simulated shifts at getonthejob.com are built around it: real tickets and incidents, graded the way a real team would grade them, building a verifiable work record behind you. So instead of hoping a community takes your word for it, you have a piece of graded work you can walk someone through. The free shifts are a good place to feel what that kind of judged work looks like, without having to be an expert first.
I really like your point about nobody remembering the first question you asked, but remembering whether you kept showing up and learning. That's a great way to look at it. I also agree that being able to demonstrate what you've learned matters more than just having a certificate. I think sometimes beginners put so much pressure on themselves to already know things that they forget they're supposed to be learning. Thanks for sharing your perspective.
There's another interesting case here: when a build works locally but behaves differently in CI, even though nobody changed the actual source code.
Take a Bazel monorepo where an OpenAPI client is generated as part of the build. If the generation action silently depends on a host environment variable, an undeclared tool version, or a file outside its declared inputs, two developers can get different outputs from what looks like the same build configuration.
This is where hermeticity becomes more than a build optimization. Bazel's execution logs let you compare action inputs and environment details across runs, while
aqueryexposes the actual actions, commands, and artifacts in the build graph.I'd argue that a good contributor experience should make this kind of investigation possible without requiring someone to understand the entire build system first. If a newcomer can trace a failed generated-code task back to the exact action and its inputs, they're learning how the project works instead of just memorizing commands to get past errors.
That pressure to already know things is the part that sticks with me too. It flips once the work itself is the evidence: one ticket you handled, explained start to finish, carries more weight than ten claims about what you know, and it takes the pressure off having to sound expert before you are one.
That is the shift your post is asking for, I think: evidence from work, not a performance of knowing.
I think there's another side to this that doesn't get discussed enough: sometimes the biggest barrier isn't the community, it's the project itself.
Take a monorepo with multiple services, different Node versions, PostgreSQL extensions, generated clients, and a bunch of environment variables. If a newcomer needs half a day just to get the test suite running, telling them "don't be afraid to ask questions" doesn't really solve the problem.
I came across a 2026 study that looked at 24 live tool-installation sessions and surveyed 144 students. Version incompatibility, broken instructions, complicated setup, and missing installation feedback kept coming up.
I think a genuinely beginner-friendly project should make the first successful local build almost boring: a reproducible dev environment, explicit prerequisites, a working seed dataset, and errors that actually tell you what went wrong.
We often measure how welcoming a community is by how maintainers respond to questions. Maybe we should also look at how much unnecessary friction the project makes people deal with before they can even ask a meaningful one.
That's a really great point, and honestly something I hadn't considered when writing this. We tend to focus on how people interact with beginners, but the experience of actually trying to get a project running matters just as much. I know I've run into projects where getting everything set up felt harder than the actual work I wanted to do. And for someone just starting out, that could easily make them question whether they're doing something wrong when the setup itself is the problem. I really like the idea of making that first successful build as straightforward as possible. Thanks for adding another perspective to this discussion.
I think there's another issue here: a project can have a reproducible setup and still be frustrating to contribute to if the build system is a black box.
Airbnb's JVM monorepo migration to Bazel is an interesting example. They had to deal with millions of lines of Java, Kotlin and Scala, dependency graphs, remote caching and build isolation. One detail I found interesting was that they initially kept Gradle and Bazel running side by side because switching the build system wasn't enough. Developers also needed the missing integrations and tooling to be sorted out before they were comfortable switching.
That's an important distinction for me: getting someone to their first successful build is only step one. They also need to understand what happens when that build fails, how to run tests for one affected module, and where to look when a dependency breaks. Otherwise, we've just moved the onboarding problem from installation to debugging.
That's a great distinction. Getting something to build successfully is definitely not the same as understanding what's happening behind the scenes. I think good documentation and onboarding need to go beyond just getting things running and help people understand how to troubleshoot when something breaks, too. Otherwise, like you said, they're just stuck at the next hurdle instead of the first one.
Agree with the correction point, but I'd put the test of a welcome somewhere else: not in how people talk to a beginner, but in whether anyone asks the beginner for something. Kindness is cheap to give and nobody has to change anything to give it. Being handed a real task before you feel ready is what turns a guest into someone who is in the room.
That matters because from the inside, "am I welcome" and "am I any good" get mixed into one question. A beginner cannot tell a warm community from a patient one, they sound the same at first. The difference only shows the first time someone needs your work and does not care that you are new.
I like this perspective. That idea of someone actually asking something of a beginner or trusting them with something small is such a good point, because that does make the welcome feel more real. It turns it from “you’re allowed to be here” into “you belong here.” I also really liked what you said about “am I welcome” and “am I any good” getting mixed together, because I think that’s very true when you’re new. Thanks for a thoughtful comment.
Thanks. Then a real question, about you and not about the post: what was the first small thing someone here trusted you with when you were new? I ask people that more and more, and the answers say more about a welcome than any statement of it.
That's a really good question. I think for me it was when people started showing genuine interest in the things I was building and asking me questions about them. I was still pretty unsure of myself, so having other developers actually want to discuss my work and hear my thoughts made a big difference. It helped me realize that I didn't have to know everything to have something worthwhile to contribute. I think that was probably when I started feeling like I actually belonged.
Your answer moves my claim a little. People asking about what you were building is not a task either, and yet it worked, because answering a question about your own work means standing behind it in front of someone. So the ask does not have to be a job. Interest counts when it puts you on the spot: someone wants to know what you made and you have to answer as the person who made it.
Welcoming is observable in the recovery path, not only in the greeting. A newcomer who gets a reproducible setup, an explanation of the first failure, and a safe place to ask a basic question has a path forward. Clear contribution guides and issue labels are small pieces of infrastructure that make that culture real.
Yeah, getting started is one thing, but knowing where to turn when something goes wrong is a whole different story. And let's face it, something always goes wrong eventually. I think even small things like decent documentation and people being willing to help can make a huge difference, especially when you're new to all of it.
The silent one in five also learns from what happens after a snarky first reply. If nobody steps in, readers take the rule from the silence. A community that wants beginners needs regulars who write the second response, not just the first.
"I don't need to know everything to have something worth contributing" is the whole thing right there. That fear of looking like you have no idea what you're doing is your brain trying to protect you, not a sign you don't belong. The annoying part is that the more you hold back, the more your brain keeps flagging asking as risky. Every time you ask anyway and nobody bites your head off, it gets a little quieter. And that 20% who don't feel confident asking publicly probably includes a ton of senior people too, which says a lot.