I joined a startup....they gave me access to the codebase and basically said "yeah figure it out, you have 1 week"

[-]

_heartbreakdancer_@reddit

Claude Code and Code is exactly use case for this. No excuses with it anymore. You can literally ask it all the stupid questions you want

[-]

peterlinddk@reddit

Obv i am feeling shy to ask someone to explain the whole thing

Why?

What do you think would happen? Will they fire you, or laugh at you for not being psychic?

Ask your coworkers to give you a quick introduction to the codebase - ask for access to "confluence" - ask them to help you getting a complete dev-environment up and running.

And take notes, lots of notes! So that you don't have to ask the same things over and over.

Otherwise you are going to sit there for months, and someone will fire you for being unproductive!

[-]

Brave_Watercress_863@reddit (OP)

I did get a brief walkthrough of the overall flow

what I'm actually panicking about is the detail layer. like the high level makes sense but then you go one level deeper and there are functions and components that are either genuinely complex or just new to me and both feel the same when you're staring at them at 11pm trying to figure out which is which.

it's less "I have no idea what's going on" and more "there's so much going on that I can't figure out what to prioritise learning first."

[-]

beingsubmitted@reddit

I've been at my company for awhile, and the repo I spend most of my time in, I'm probably the dev who understands it the best right now. I've also never seen at least half the code. You may just be overestimating what's expected of you right now. When I get a task or something to change, the first several hours are often finding the code responsible for that one specific behavior and reading it to understand it. Most detail level reading is in service of specific tasks. You're not expected to know what every little function in the codebase does.

I think there's two big things to focus on: patterns and tools. There's some general architecture and pattern they're using, and you want to do that, too. Understand not just the outcome, but the intent. Not entirely - you won't understand entirely for some time, but a familiarity.

The tools are important, too. Here, I'm generally talking about things like value objects and extensions and infrastructure, etc. There's probably already a generalized way to send emails. There's probably a way to handle validation. In my codebase, I have a way to make any endpoint async and create a job, or to make any endpoint schedulable with a general scheduler in very proud of. Probably the most common thing you'll hear in code reviews for awhile is "you don't need this, you can use ___".

[-]

DoomGoober@reddit

My general rule is: Learn the top layers first. Only dig 1 layer deeper when you have to.

When you learn how to drive a car, you are taught to start the ignition and then press the gas to go. Great! You can drive the car. Does the driving instructor tell you how spark plugs work when they are teaching you to drive? Nope. You only need to know about spark plugs if you are a mechanic or if your car isn't starting when you turn the key.

"Here's the code base, learn the whole thing in a week" is an idiotic instruction. "Learn the top level of the code base, drill down into one particular area to get used to the coding style, then fix a bug in that area, with John Doe being the contact in case you get stuck" is a much better instruction.

I would ask what the first areas you are going to be working on will be and focus more on that.

[-]

farfaraway@reddit

This is the #1 use-case for LLMs. Being able to ask Claude what a codebase does is the first thing I'm doing in a new one.

And: explore the files like a mf. Look at everything. Open it all up and poke around. See what is connected to what. Ask Claude why. Try to understand why the devs made the decisions that they did.

Instead of burning another dev's week, do it all on your own. You can do this.

[-]

Philderbeast@reddit

a readme.md that says "see confluence" which I do not have access to yet.

start by asking about the confluence, do you have access to the documents, they probably haven't realised you can't access it if you have not asked.

Obv i am feeling shy to ask someone to explain the whole thing
So I cloned it...opened it....stared at it.

Today is day 3, I still got no idea where to start

I would be far more nervous wasting three days then asking for help.

[-]

Sleepy_panther77@reddit

I think the first week to first month is the time where you should be asking questions basically every 5 minutes.

I usually give my juniors advice telling them to not get stuck on something for longer than 45 mins without asking, but the exception is onboarding where I don’t want them (or any other level engineer) to be stuck on something for longer than 5-10 mins

Maybe schedule a meeting with someone with a batch of questions?

And I’m not sure how we feel about AI here but I do think it’s decent at looking at code bases and explaining a few things well

[-]

Chunky_cold_mandala@reddit

Sounds stressful

Use a repo scanner. They are tools designed for this specific scenario. This one I wrote specifically describes information flow from beginning to end. And highlights bottlenecks, important files and functions. Pip install gitgalaxy or GitHub action. https://github.com/squid-protocol/gitgalaxy

Examples of reports: https://www.reddit.com/r/coolgithubprojects/comments/1tq9ath/i_took_a_stab_at_making_my_own_code_base_analyzer/

[-]

Elegant_AIDS@reddit

Ask your coding agent of choice to explain it to you

[-]

miguescout@reddit

The way i was once introduced to a codebase was by making me create tests to increase that codebase's coverage (there was a sudden corporate order to increase coverage to, i think, 95% at minimum). I was given a high-level view of how it all worked, some tips on how to create the tests, a couple pointers... And from there, i was on my own pretty much. I had access to the codebase, to the dev server, and its coverage analysis, so i could see what code was covered by a test and what wasn't.

And so, i started fiddling with mocks. Mock users, mock functions... And eventually, i got tests to pass (i was going under the assumption that the code was working properly at that time, because that code was the same that was on prod, and i didn't dare question the integrity of prod). And from there, it was just a matter of changing some of the values so it could cover another branch of the code. Anything that relied on an external service to this codebase i had to mock away, and everything else had to stay untouched unless it was truly impossible for me to leave it untouched.

Obviously, this didn't give me a deep understanding of the code. I mostly had to look at wherever the test got stuck and see what i had to do to allow it to continue, with every other part pretty much overlooked, but it allowed me to reach a few layers deeper than the initial overview... And from there, it's just a matter of filling the blanks of what i didn't look closely enough because the tests just breezed through.

Now, was this mostly just the seniors being too busy having to do other tasks and adding features and using the junior to offload the task no one wanted to do? Sure, but it was still very helpful to get a better sense of the inner workings... Now i wonder what they did for whoever came after me, as i already got the coverage to compliance...

[-]

loophole64@reddit

Bro, this is like the best possible use case for LLMs. If it's a startup, I would bet money they don't disallow LLMs. Create a dev container in vscode, install claude or codex, tell it to explain the code base to you. I have saved approximately 8,000,000,000,000,000,000,000,001 hours of time in the last 2 years doing this. It's literally a super power.

[-]

carrognia@reddit

Yes, this, but only if okay to put in the codebase into ai explicitly. Might have policies to do only parts at a time.

[-]

Ezazhel@reddit

Find the entry point. Navigate from there.

[-]

Brave_Watercress_863@reddit (OP)

I did but after 3-4 files it is getting way too much complicated

[-]

projexion_reflexion@reddit

Look at the recent merges and see what they're actually working on.

[-]

carrognia@reddit

You’re in the business of breaking things. Fork, run locally, and start messing with things until something breaks, changes, or you don’r understand it. Do it enough so you have questions to ask. You’re not saving lives, so mistakes are part of the process. Dig in, find interesting stuff, get something working.

[-]

OldSample1530@reddit

day 3 and still staring at 47 folders with no map. that is rough.

i ran into the same mess at a startup a while back. no docs, no walkthrough, just a pile of code someone left behind.

i ended up getting help from Ibrahim Taofeek: Full to untangle it. they went through the whole repo, mapped out what each piece did, and pointed me to where i should start.

saved me from guessing and hoping i did not break something important. worth reaching out if you are stuck.

[-]

hajimenogio92@reddit

Is there a senior or someone else you're paired up with to go over this? While there may be good platforms out there to help with that, speaking with someone who's familiar with the code and how the business operates is key imo. I work on the DevSecOps side and I've had multiple jobs where I was the first DevSecOps hire. My first goal was to orientate myself with the product, business, and how teams worked together.

[-]

Confirm4Crit@reddit

If you have access to an LLM, use it to get a review of the situation.

Besides that, start from the bottom. Can we run it locally? Is there a small bug ticket I can try to find that helps me take a dive into the system? The post doesn’t confirm if we’ve done that yet. Start small and iterate.

[-]

apocalypsebuddy@reddit

Use AI to explain granular details and review the codebase.

I know I might get downvoted for saying this, but you’re at a point where you need to use any leverage you have to get a hold of this.

Obviously don’t be pasting api keys and such, but take advantage of a copilot or Claude plugin in your IDE to just read the code and explain any gaps in your knowledge.

Even the most seasoned devs will glaze their eyes after trying to read and parse code

And set up regular talks with your staff engineer

[-]

Zalenka@reddit

Follow their documentation to get it running. Asl questions to seniors devs if you get stuck (look for who committed to the repo).

Are there outstanding bugs? Fix them.

[-]

Liutprand@reddit

Start asking access to Confluence?

[-]

alexey-masyukov@reddit

This is the perfect case for Claude Code. Use it for understand code base.

[-]

Good_Skirt2459@reddit

Well I got hired \~6 mo ago. I'd say #1 thing that will help is getting access to the docs on confluence. Seems like a huge waste for you and your employer if you have docs but are having to spend time discovering what's already documented.

My experience with it was that I didn't really know WTF was going on in the code.

However, if you have a good team, they should give you tasks which are of a reasonable scope, they shouldn't give you tasks that require deeply rearchitecting the entire codebase.

So, just learn only what u need to know for each task. Ask for help if you have to (but don't always use it as an intellectual crutch, the process of problem solving helps you learn). Once u do 5, 10, 20, 30 small tasks across the code base, your understanding will grow.

[-]

Dziadzios@reddit

Ask them for a task and learn by trying to finish it.

[-]

White-VisionX@reddit

ngl this sounds like every startup onboarding ever

don't be afraid to ask questions. a 10 min walkthrough from someone on the team is worth more than hours of staring at random folders.

first thing i'd do is get it running locally and trace one feature from frontend to backend.

[-]

Good_Skirt2459@reddit

I'm also a JR in a similar boat 6 months ago. Sounds like getting access to the confluence would be a great start. I mean if you have docs it seems like a waste for you and your employer for you not to have access to them.

Also start with one thing... do you have a specific feature you've been tasked at fixing or building? Start there, figure out just enough of what you need to know. Do that 10, 20 times across different parts of the code and I think you'll start to build an understanding. That's how it worked for me.

But it was just a grind. I tried making a few fixes, and a few of my first PRs were kicked back because I didn't get something, but I always tried.

I kept an obsidian notebook where I wrote down work tasks, solutions, notes about the code, things people told me that might be relevant one day, etc.. Good for my understanding and knowledge, and a good thing to have when it's time for performance review and you wanna say what u've done.

[-]

plyswthsqurles@reddit

You need to just take a bug...find where XYZ button is in the UI. Then correlate that to the code. Search the code base for a string you see in the Ui that might be hard coded in html/jsx/whatever the framework.

That or just literally pick any button -> look at the network tab to see what server side call it is making. Then find the click event for that button by some sort of id or identifier (same thing as above, if no id or identifier, look for a unique string on the page (ex: don't use the word "and" for example). Once you find the unique string, go into the component/partial view/whatever to find the button. Once you find the button, look for the event that gets triggered, once you find the event...if theres an API it calls that you have the source for, switch over to the API.

Basically, you pick literally any point and just work backwards. It may seem like a lot of code but if you just stick to solely that button/event/drop downs responsibility/code it triggers...you'll be able to figure it out.

You've got to focus on the single tree and your worried about the entire forest.

[-]

dmazzoni@reddit

As an intern one of the hardest things is finding the balance between learning to figure things out, and asking questions.

Interns who ask too many questions without even trying can be super annoying. I've had interns who constantly post on Slack asking how to do the most basic things that they could have figured out just by Googling it or spending just 30 seconds trying it.

On the flip side, I've had interns who wait until the end of the week to tell me that they got nothing done because they were stuck the whole week on something they couldn't figure out.

You don't want to be either extreme. Continuing with either extreme will guarantee you will fail your internship.

The happy medium is to try to be resourceful, but if you're still stuck, keep asking persistently.

To be resourceful, try to figure out how to run the code. Figure out what language or framework it uses and Google how to normally run code written in that language or framework. Look for any documentation. Try stuff.

But if you're still stuck, keep asking. Don't just sit there not bothering anybody, you're stuck! Start with your manager or mentor. If they don't answer after a while, ask other people on your team. If someone doesn't know, ask them who to ask! Be specific: don't ask them to walk you through the whole thing, ask them to point you in the right direction, or to copy and paste the Confluence docs, or something specific.

If you're really having a hard time getting time from your manager, put a meeting on their calendar. Busy people are basically slaves to their calendar. If they have an open slot from 1:30 - 2:00 and you fill it with a 1:1 and come prepared with a question, you'll be surprised how easily that works and gets someone to help you.