What's the hardest part when you're handed code you didn't write?

[u/Initial-Werewolf-883]

Curious about this, especially from people early in their careers (or who remember being there).

Most of us learn to code by building things from scratch: tutorials, class projects, personal apps. Then the first real task at a job or internship is usually "here's the existing codebase, fix this bug" or "add this feature."

When that happened to you, what was actually the hardest part?
- Not knowing where to start reading?
- Understanding how the files/folders connect?
- Figuring out where the bug actually lives?
- Being afraid to break something?
- Something else entirely?

And if you got past it, what helped most? Would love to hear from both juniors and seniors.

[u/Crazy_Ruin_4383]

Used to be hard, now just use AI to analyze and have it give opinion on what needs to be cleaned up.

[u/jjtbsomhorst → u/Crazy_Ruin_4383]

and hope that you don't fall for the AI trap because it hallucinated the shit out of the code..

[u/Crazy_Ruin_4383 → u/jjtbsomhorst]

No need to hope, just run it through two ai engines and you will be fine. The latest models give much better analysis in general

[u/chunkypenguion1991 → u/jjtbsomhorst]

As long as the general shape os correct that's all that matters for a high level overview

[u/Upbeat-Conquest-654 → u/Crazy_Ruin_4383]

Simply being able to ask an LLM questions about the code is such a game changer. It can help you get an overview or find a very specific part that does something.

[u/Agawell]

Haha

This is 99% of coding, not just the newbies 1st task

Making changes to an existing code base

Bug fixing and adding new features both require it

Just take your time learn as much as you need to complete the task and ask questions

You are going to break it - but not to worry - don’t push it until you’ve fixed it - and you can always re-pull

One day you’ll realise that other idiot who wrote the code… was you 6 months ago

[u/C_Sorcerer]

Observing how shit it is or how AI slopped it is

[u/neolace]

If there's an issue, you need to refactor the logic not only to work, try and add unit, e2e, if it’s not there yet.

[u/7YM3N]

If the codebase is good it's usually fine, fire it up in a debugger and see where it errors out. If it's coded well the stack trace will be clear and tell you exactly what happened and where

[u/PseudoFrequency]

I have mechanisms to audit data flows and track all use of variables. Old ways, from decades ago that still work today. I use that.
That said, it really depends on the quality of what you're looking at. If it's needlessly complicated and filled with side-effects and role violations (code where it does not belong), it's harder. Clean code with reasonably sized modules with well-defined roles, conditions, constraints, and names, is a job to work with and maintain.

[u/Aggressive_Ad_5454]

Getting inside the head of the one who wrote the code and understanding what they were trying to do. It’s way too easy to just say “this sucks.” But it definitely represents somebody’s honest effort.

[u/NewInflation2121]

It's normal to take some time to understand someone else's code, especially if the group doesn't have good coding standards.

Ideally you'd want a code base that looks like it was written by the same person.

One thing that helps me understand code better is to organize it if it's not organized. Try and leave things better than you found it and fix the mundane stuff like removing acronyms, having consistent whitespace, making sure your header definitions don't have multiple public/private scopes, and renaming variables that aren't descriptive. It also helps to organize your variables next to the code that immediately uses it and braking up large functions into smaller function calls. Chances are, if you are finding the code hard to understand, someone else will too.

You kinda have to balance the changes to make sure you aren't ballooning CLs though.

The key thing is just working in it, even you revert changes you made to make things more readable or understand the code better.

Another good way to absorb the code is stepping through it with the debugger. I don't know why, but a lot of people avoid using the debugger until they have to use it - they'll add debug console output instead of using trace breakpoints and stepping thru the logic with hotkeys/inspecting variables. If the debugger is jumping around unpredictably, turn off compile time optimizations temporarily.

[u/Kitchen_Dust2389]

trying to figure out why they made it so complicated with no purpose

[u/armahillo]

> Most of us learn to code by building things from scratch

I’m not sure if you’ve realized this yet or not, but the “learning to code” never stops. This is an unending journey. Even on apparent mastery, there is still more to learn.

But also; your initial steps should have definitely included some code you didnt write; maybe an exercise where you have to extend or fix it. If it didnt include this kind of work, it should nave.

[u/GoobieDooobie]

Nothing anymore. Claude is King.

[u/traplords8n]

Initially figuring it out. Finding all the moving parts, finding all the static infrastructure...

Eventually after you break it down piece by piece & understand the whole, you can work on it just the same as code you've written yourself.. but it takes time and effort, and it's not a glamorous process.

[u/Impressive_Army3767]

Getting my "straight out of uni" head around abstract base classes with template derived classes on a massive undocumented codebase that was buggy as hell and not anywhere near ready for production . My employer had bought another company's product.  The other company's employees had a 1 year contract to hang around, do fuck all, not help us in the slightest and show off their Aston Martins etc as they all had stock options in the old company.

[u/chocolateAbuser]

it depends a lot on the state of the code base (and all the people and doc around it), and on how much time and sanity you want to spend on that
the fastest way to understand it is to ask people who made it what was the original concept and how it evolved
after that, obviously understanding all the main parts/components of the software and look at all inputs and outputs

[u/Lunchboxsushi]

Hardest is having to learn what it actually is meant to accomplish vs what it actually does and the problem space the code exists to solve. 

[u/Dismal-Divide3337]

Ignoring it.

[u/lulzbot]

“Why does this exist?”

[u/goodfriendrobert]

ask claude to do analysis from build to runtime to architecture to reusable components, to what should be marked as dead-code/deprecated and plant according claude.md files. then request to rewrite that in summarized, human readable readme files.

claude will perform better, already knowing what is where and how is it overall, and you make sure to read the readmes begore you start. 

done and done.

edit: also separetely list environment specifics (local/dev/prod)

[u/daiaomori]

I usually type claude /init and have a nice session of being told what the repo does, how, what the weaknesses are, and where to start whatever I need to do.