How do I contribute when I work with someone much more experienced who makes me afraid to speak up?

Why this feels so heavy

When you sit next to someone with many more years of experience, the difference feels like intelligence. It almost never is. It is context: they have seen this system break before, they know why that odd function exists, they have made the mistakes you are about to make. Context comes from time and exposure. Staying silent is the one thing that slows it down.

It helps to remember that experienced engineers were once exactly where you are, often with someone who intimidated them.

You bring something they cannot

A newer engineer sees things a veteran stopped seeing years ago. That is genuinely useful, and it is the easiest place to start contributing.

• The setup instructions that did not work on your machine.
• The function name that confused you.
• The part of the codebase with no explanation anywhere.
• The error message that told you nothing.

Fixing these, or even just pointing them out, is valuable work. Everyone benefits, and it builds your confidence because you are clearly right: it really was confusing to you.

Ask questions that show your thinking

Much of the fear of wasting a senior person's time goes away when your questions are well prepared. A good question costs them two minutes. A vague one costs twenty.

Compare:

Why is the build failing?

with:

The build fails on the migration step with a foreign key error. I checked that the users table exists and tried running migrations in order locally, which works. My guess is the CI database is seeded differently. Am I looking in the right place?

The second shows you tried, shows your reasoning, and lets them correct one specific thing. Experienced engineers generally enjoy questions like this, because they are easy to answer and show someone is learning.

A simple routine: try for a reasonable time on your own (half an hour to an hour for most problems), write down what you tried, then ask.

Blunt is not the same as hostile

Some very experienced engineers write short, direct review comments. "This will not scale." "Why not use the existing helper?" To a newer person, that can read as contempt. Usually it is just someone busy, writing quickly, who assumes you want the information.

If it is the left column, the most useful thing you can do is treat each comment as free teaching. Reply with something like "Good catch, I did not know about that helper. Changed." You will learn faster from this person than from anyone gentle.

If it is the right column, that is not something you should absorb quietly. Raise it with your manager factually, with examples. A healthy team does not accept it.

Build a relationship outside the review

Fear shrinks when you know someone a little. Ask them about something they built, or how they would approach a problem you are working on, over a short call rather than in written comments. Most experienced engineers like being asked for their view, and the conversation changes how their future comments read to you.

Start speaking up in small steps

Do not try to fix this in one leap. Over the next few weeks:

1. Fix one piece of confusing documentation you ran into.
2. Ask one well-prepared question a week.
3. In a review, leave one genuine comment on their code, even if it is just a question: "Is there a reason this is not cached?"
4. In one discussion, share your view first, phrased as a suggestion.

You will be wrong sometimes. That is fine. Being wrong out loud and corrected is how people with experience got it in the first place.

What to say when a review comment stings

When a short comment lands badly, the worst responses are silence or a defensive paragraph. A calm, curious reply almost always works better. A few you can adapt:

• "Thanks, I had not considered that. Could you say a bit more about why the existing helper is better here? I want to understand it for next time."
• "Good point. I went this way because of X. If that reasoning does not hold, I am happy to change it."
• "I am not sure I follow the concern about scale. Would five minutes on a call be easier than going back and forth here?"

The second one matters more than it looks. Explaining your reasoning, politely, is how you move from someone who receives corrections to someone who is part of the discussion. Sometimes you will turn out to be right, and a good senior engineer will say so.

A self-check for the next month

At the end of each week, jot down honest answers to these:

1. Did I ask at least one prepared question?
2. Did I share at least one opinion, even a small one?
3. When I was corrected, did I learn something specific I can name?
4. Did I avoid asking something only because of fear?

You are not aiming for four yeses straight away. You are aiming for the fourth answer to become "no" more often over time. Most people find that after a month of small, deliberate steps, the person who felt intimidating starts to feel like the most useful teacher on the team.

If you are still stuck

Read What Actually Changes in Your First Two Years as an Engineer, which covers this stage in more depth.

If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session. You can also browse the other career questions people have asked.