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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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!
I can relate to so much of this. I was so nervous when I first started sharing here, and I still overthink things sometimes. But every time I post something and have a positive interaction, it makes the next one easier.
Also I love what you said about being able to disagree without it turning into an argument. I've learned so much just from hearing other people's perspectives, even when they're different from mine. I feel really lucky to have found this community too. It's made such a difference in my confidence and willingness to put myself out there. Thanks so much for sharing your experience!
You're welcome. Looking forward to your next article!
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.
"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.
Exactly. That's pretty much how it's been for me. The more I've put myself out there and had good experiences, the less I've worried about what people might think. I still second-guess myself sometimes, but nowhere near as much as I used to. And that's a really interesting point about experienced developers possibly feeling the same way. I think sometimes we forget that being knowledgeable about something doesn't automatically make someone confident about sharing it.
That's the pattern exactly. Every good experience is new evidence, and your brain slowly stops treating putting yourself out there like a risk. The second guessing hanging around a little is normal too, it just gets quieter and shows up less. And yeah, knowing a ton about something and feeling safe sharing it are two totally different things. Some of the most knowledgeable people I've seen are the quietest in the room for that exact reason.
As female developer I really enjoyed reading the article:)
As a woman I did find some difficulty in my middle eastern culture to prove that I’m professional enough to get a job. It was a little bit hard when I started my career .After I gained experience I started a business of female IT professionals to support each other and get into market. We found that the market needed that kind of companies so I was happy and blessed yo be a woman in Tech.
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.
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 love hearing this perspective from someone who's been in IT for so long. And I think it's awesome that you've created something specifically to help people learn and experiment without feeling uncomfortable asking questions. That's exactly the kind of thing that makes tech more approachable. I can definitely relate to becoming more comfortable sharing my work here on DEV, too. It's made such a difference for me. And I love that after 40+ years you're still finding inspiration. I hope I never lose that excitement for learning and building things! Thanks so much for sharing your experience.
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.
I think there's a huge difference between just figuring out which command makes an error go away and actually understanding why it happened in the first place. I've definitely learned more from looking into things that went wrong than from the times everything just worked. And I agree, making that kind of investigation easier for newcomers would be so much more helpful than expecting them to understand the entire system before they can even start troubleshooting.
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.
There's another layer to this that I find interesting: sometimes making a project easier to understand means reducing how much of it a developer has to understand at once.
Grab Engineering published an interesting example involving an Android monorepo with roughly 2,000 modules. A full Gradle sync could take over 35 minutes because Android Studio had to configure modules that developers weren't even working on. They introduced a Focus plugin that used the dependency graph to load only the target module and its required dependencies.
What I found particularly interesting is the trade-off: focusing the project also limited some cross-module IDE operations, such as Find Usages and refactoring. So even improving the developer experience required thinking about what information developers actually need at each stage.
I think this is an important part of onboarding that often gets overlooked. We shouldn't expect someone joining a large codebase to understand the entire architecture before making their first useful contribution. Good tooling should help them discover the relevant parts gradually, without hiding the dependencies that matter when something breaks.
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.
I hadn't really thought about it that way. Even just having someone take an interest in what you've made can put you in a position where you're the one sharing your knowledge instead of always being the one asking questions. I think that can do a lot for someone's confidence, especially when they're still getting comfortable calling themselves a developer. I've really enjoyed this perspective. Thank you!
“Posting before I’ve had enough time to talk myself out of it” is honestly my whole strategy too. When I started, I’d write a comment, delete it, then write it again. What helped most was seeing people here reply with “here’s a better way” instead of “why would you do that.” Small tone difference, huge effect on whether you come back.
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.
You are so right, and that's something I hadn't really thought about. It's not just the person asking the question who's paying attention, but everyone else reading along too. And when someone steps in with a helpful response after a dismissive one, it shows that kind of attitude doesn't represent the whole community. I think that can make a big difference for someone who's already hesitant to participate.
If I ask a beginner question, the reply I’d find most useful would end with one small thing I can try next, plus permission to come back if it fails. A link to the exact docs section and a tiny example gets me much further than a whole manual. I’d also appreciate being asked whether the explanation made sense before the conversation moves on.
I agree. Often all you need is some guidance to get you moving in the right direction. Being handed pages and pages of documentation when you’re already confused can be overwhelming. And I completely agree with what you said about checking whether the explanation actually made sense. Just because someone explained something doesn't mean the other person understood 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 tech community, yes. Most communities are really welcoming. Most techies in general are very welcoming, because we all started off helping older people understand their problems.
But Tech itself... Very unforgiving. Which is why most things are designed to discourage or outright block bad behavior. Whether by throwing a 'are you sure' or outright not allowing a value.
In that aspect, Tech is a scary thing, that people who arent tech savvy shy away from, because while most techies are very welcoming, we're also fiercely competitive and safeguard our sanctums. I mean if your mother started calling herself a techy tomorrow, for discovering how to turn the tv's wifi on, would you say anything? In that way, we're welcoming to a point, we encourage people to learn, but we discourage people to know (if that makes sense). You can learn from us, but dont presume to know as much as we do? I mean if your mother told you 'no, you do it this way...' wouldnt that annoy you, when you know she's doing it wrong? Have you ever waited long enough to see that she gets to the same point, just through a longer route?
That's where we're quite bad imo. So often, when people try show us what they found, we're unwilling to listen, because we operate like deterministic systems, unwavering from our optimal paths. If you know the fastest way to get wifi password entered, is to swipe down on notification bar, long press wifi, select network and enter password, would you interrupt when someone tries to go to settings, network, wifi, selected network and do the same? It's kind of sad really, because that's exactly how we learned in the first place, by following the logical route to it. It's only later that we learn the shortcuts, but we get so fixated on shortcuts, that we forget not everyone knows them and not knowing them isnt a crime.
I'm speaking from experience here, both in what I identified in myself and through the people I helped. In my free time, I often help the elderly in my town with their IT (I refuse payment, pensioners need the money more than I do). So many of them say that they asked their kids for help, but their kids got frustrated and refuse to help. Others say that they asked a techy, but they just ghosted them (ok, they dont say ghosted, they say 'they just stopped answering my calls').
That's kind of when I realized, we're like extremists, we encourage others to see things our way, but we discourage half-hearted attempts. Even though that's the journey we walked ourselves. My sister for instance, has gotten into learning more about PC maintenance, asking about windows updates and whether things are necessary. I keep telling her, they're not necessary, but recommended, .net redist is necessary, but your installed software runs fine without updating it, windows security update, definitely necessary to stay secure, HID driver updates, but her trackpad works fine? Questions that quite frankly surprise me half the time, because I'm too caught in the habit of keep your drivers and antivirus up to date, that when she asks about each specifically, it kind of puts me on defense, to where I actually need to justify my recommendation out of more than just habit and it's actually refreshing to be honest. I think we can all learn alot by being more welcoming to non-techies and their questions, even when they're frustrating (I swear, if I get called again, because 'Person A' closed an email in outlook and cant find it... (it's in drafts)...) they're just trying to learn and we're the people who are meant to teach them. They look up to us, because we're the light at the end of the tunnel, the holy grail, that makes all the things that dont make sense, just work.
If any of that kinda feels familiar to you, I'd recommend, helping out the seniors in your area. When you bump into them, ask them if they're having any issues with their computers. You'll never know it until you go help, but they're honestly the nicest people you'll ever meet and they'll appreciate every second you spend with them.
Case in point. At our old apartment, there were neighbors downstairs, that needed help 1 day, I went to go help, turns out they knew my old neighbor (from when I was growing up) when they were young. Had an amazing chat with them (4 hours long), they even made a fruit bowl to thank me for helping and they also recommended me to other people they knew, I walked with them 3 blocks away to go help an old lady that had a stroke that needed help with her microsoft office, because at 74 years old, she still had to work, because pension didnt cover their expenses... I didnt know it at the time, but 3 weeks later, her husband died and if I hadnt helped her that day, she'd not have had enough money to pay for her rent and would have ended up on the street. A 74 year old lady, whose kids are overseas and all she had was her husband. A small act of kindness goes a long way and while it might be frustrating for you, it's lifesaving for them. Person A for instance, is 78 years old, still working, constantly having issues with outlook... But I help, because if I dont, he cant earn an income and would be homeless by end of the month. For me it's 10 minutes of my time, at irregular hours (sometimes 10pm at night...), but then I think to myself, if he's having issues at 10pm at night, it means he's still working... People who are well off dont work at 10pm, he's struggling to survive and without my help, he'd likely lose his home.
That's just 2 of the many I help and I encourage you to do the same if you have the time to spare (I didnt think I had the time, but 10 minutes here and there, is all they need). Be the welcoming techy, who helps your community. You never know, good karma has a way of coming back to you and the old people you meet and help, likely will help you in the future too.
Wow, thank you for taking the time to share all of this! You brought up some really good points. I especially like what you said about how we get so used to doing things a certain way that we forget what it was like to figure them out in the first place. Just because someone takes a longer route to get somewhere doesn't mean they're doing it wrong, and sometimes we could probably learn something ourselves by letting them explain their thinking.
It's so awesome that you spend your time helping older people in your community. Those stories really show how something that seems like such a small thing to us can make a huge difference in someone else's life. And you're right, sometimes a little patience and a few minutes of our time is all someone really needs.
I think that's a great reminder that being knowledgeable about technology is one thing, but being willing to share that knowledge with a little kindness and patience is just as important. Thank you for such a thoughtful response.
Those survey numbers echo what I see in OSS maintainership: lurkers massively outnumber askers, and the deciding factor is rarely technical ability — it's the perceived cost of being wrong. What actually helps is when answers model the reasoning out loud ('here's why I'd check X first') rather than delivering just the correction, so a wrong question becomes a shared learning step instead of a judgment event. Docs that explicitly label beginner-friendly entry points go a long way too.
The 21.1% number stayed with me, because it suggests the silent readers are not a small edge case — for every person who posts a question, there may be others reading along who never will. That makes the tone of a correction do double work: it answers one person, and it tells everyone watching whether it is safe to ask next time. Your example about pointing to the docs without the "did you even bother" part captures that exactly. I also liked the reminder not to shrink someone's first working app or first self-found bug just because it looks small from further along — that excitement is often what keeps them coming back for the harder parts.
I love how you put that. We tend to think about how our responses affect the person we're talking to, but there could be dozens of other people reading along and deciding whether they feel comfortable asking something themselves. And I completely agree about celebrating those small wins. I still get excited when I figure something out I've been struggling with. That excitement is a big part of what keeps us learning, and I think it's important not to lose that.
Pointing someone toward the docs with kindness deserves a whole post of its own. "Here's the page, and the part on auth hides a bit further down" welcomes people back, and "did you read the docs?" sends them home for good. One small habit helps a lot in communities: we thank the person for the question before we answer it, and everyone reading along learns that asking is safe.
The 21.1% figure is a good gut check. Plenty of people are reading along without ever posting.
🚩
in my experience a lot of platforms treat begginers like a burden
That's unfortunate, and I can definitely see how that kind of attitude would discourage someone from asking questions or participating at all. I hope you have found at least some communities that have been more welcoming.