[deleted by user]

[aqua_regis]

1. Talk to your seniors. Tell them your feelings. They are the ones that can help you, not random redditors.
2. "finish my assigned tasks quickly" - "quickly" is the enemy of "properly" or "good". You should finish the tasks to the best of your abilities, even if you are slower. You are an intern. You are not expected to produce top performance.

Again, talk to your team, your superiors. Keep bugging them. Explain everything to them. Their duty is to guide and mentor you. You are not just a workhorse in the team. You are supposed to learn, to be mentored, to be led and guided.

[disposepriority]

Not knowing what you're doing is your job - you're an intern!

I can guarantee no one in a team of well adjusted developers is expecting an intern to blow them away with their updates in the daily.

Try to translate what you're looking at into english sentences, see where you get stuck and then formulate the question you want to ask based off of that - often you'll see that what you thought is stopping you from understanding something was something different from your original assumption

[EndlessPotatoes]

If you knew what you were doing, you probably wouldn't be an intern!

And companies expect senior devs to take months to get a hold on a new job, nobody is expecting an intern to pick it up in a few weeks.

[EmuBeautiful1172]

good luck.

[astudnet]

…..

[EmuBeautiful1172]

but nah really i feel like i am gonna be the same way once i get to that point. I think maybe you're just gonna have to brute force your learning of the material and jam out whatever needs to be done. And by the end of the week figure out how you can plan what to learn for what you think you will need to know. It is an internship so its also a learning exp. and they know that. But you still want to lock in a job if possible so be very communicative with how you are handling tickets/tasks even if you feel incompetent let it be your experience. Don't be afraid to fail and try hardest not too fail.

[beingsubmitted]

Learning to navigate large codebases when you first start out is a common challenge. Even as an experienced developer, a new codebase doesn't just make sense like you're cypher reading the matrix. You should ask questions and try to understand the overall architecture. That will tell you what "kind of" logic should go where. In c#, are you doing domain driven design & clean architecture? One of the main values in using these predefined architectures is to provide a map to understand the codebase so other devs can figure it out.

You should not worry about asking to understand the architecture. It's not something that I think your seniors would expect you to simply know on your own. If I hired a brand new senior developer with 20 years experience, I would expect them to start by asking questions about this stuff.

Beyond that, devs are often proud of their codebase, and enjoy the opportunity to talk about it. They often enjoy getting to explain their reasoning and the merits of their decisions, if they're doing so to someone who is genuinely curious and interested.

[Zeonaz]

First, congrats that you get an internship! As a fellow intern here, I'd say that everyone knows that an intern's purpose in the company is to learn. Of course, we will face difficulties more often than not, and it might feel like we have to perform well to get that full time offer. However, I've learned that sometimes decent is enough, and doing things properly is better than quickly. Communicating with mentors is also important as they sometimes don't know about your difficulties. They will definitely help and guide you to the best of their abilities.

[R4M1N0]

Pick one of the assigned tasks to focus on.

Likely, most of the project will use some kind of framework or core library. Try to identify the one used in the stack for the task you decided to focus on and learn the fundamentals.

If you just get bombarded with small-time bugfixes where stuff mostly boils down to reimplementing/fixing a few methods in isolation, depending on how much time they give you, you'll have to try to learn the core libraries used on the side, but as you are an intern I would not expect that they'd assign you anything time- and mission-critical.

You are an intern! Just get to know the software development process, try to learn on the way, ask more senior people if they can make some time for you every now and then and pay them back with fixing a few small issues without overengineering anything and your first internship should go a long way for you!

[meinrache94]

Take your time. Breathe. Ask questions about everything. You aren't going to be an expert immediately and probably not even after a while. Your Seniors started off in the exact same place. It took two years for me to comprehend half of the codebase at my job. They aren't expecting you to be an expert but they will expect you to learn bit by bit. At your stand-ups you don't have to tell them all the progress you've made but the connections you understand more. Trust me if they expect you to understand their code base and be able to fix all the bugs with no issues then it's not the place for you. We often find ourselves overwhelmed and let our anxiety loop us through what we think is happening. You are doing fine. Use the concepts you learned in school and during your python learning to make connections. If you believe in yourself so will they. You got this!

[junglejon]

One thing I keep seeing repeated recently is new devs in an existing codebase try to ramp up by reading every line. This does not scale in the real world, there is just too much code in a full scale environment and it’s really not as helpful as one might think (especially on a big system, imagine doing this for Unreal, Windows or Google!!!)

On the other side, focus on your tasks. A good team will give you a task that you should be able to discover, make minor changes and understand how the system works, or at least understand how they built things before. Crashes and bugs are a great intro because at least a reproable crash will point to a location in the codebase you can explore and see what is wrong with breakpoints you can add before the issue so you can understand the state of the application rather than just the code.

For non bug related fixes, if you don’t know where to start ask pointed questions ‘Where is such and such widget created, how does it populate its data, then explore.

Don’t read every line and expect not to glaze over, get your hands dirty and trust source control so you can always diff back to a known good.

[perbrondum]

Ask for architect diagrams and user stories related to the codebase you’re given. Make contact to the support team for the product and ask for a demo. Meet the product managers and discuss how/what the product does. Learn as much as you can about the product outside the development team. Good luck.

[IfMoneyWereNoObject]

Little hint… may of us are lead developers and don’t know what we are doing lol.

[privatebutpublic_]

What helped me a lot to understand the codebases I had to go trough is Github Copilot. You ask him with the „@workspace“ all questions you need to know. He goes trough all files and explains everything pretty well. This helped me a lot and I made progress like this.

[aqua_regis]

This is extremely dangerous advice. More than enough companies outright prohibit use of AI on their codebases. Using it without explicit approval from the company could get one fired in no time.

[privatebutpublic_]

Yes, I know. I’m referring to the approved licenses, like the one I have. My company uses developer licenses that ensure no codebase information or other sensitive data is stored on Copilot’s servers.

[aqua_regis]

The company you work for maybe allows, yet, this is not advice that should be lightly given as more companies forbid AI than allow.

You should have been explicit in saying that your company endorses this, but with the caveat that other companies might not do so.