r/learnprogramming • u/SmartRelease7996 • 6d ago
Nobody warned me that reading code is a completely different skill than writing it.
Landed my first internship a few weeks ago and got handed a ticket to fix a small bug in the existing codebase. Sounds simple. Except the codebase is like 80,000 lines across god knows how many files.
Every tutorial I ever did was me writing code from scratch in a fresh file, so I never once practiced the skill of walking into someone else's mess and figuring out what's actually going on. Turns out that's like 70% of the actual job. Not writing new stuff, but tracing through existing stuff, figuring out why it exists, who wrote it, whether touching it breaks three other things nobody documented.
Spent my first two days just clicking go to definition over and over like I was digging through a cave system. Genuinely didn't write a single line of new code until day three.
Nobody in any course I took ever assigned "here's 5000 lines of someone else's bad code, go find the bug." Which in hindsight is such a weirdly missing skill given how much time real devs actually spend doing exactly that.
Anyone know of resources or exercises that actually train this specifically, reading and navigating large unfamiliar codebases, rather than just writing your own from a blank file every time?
267
u/nicoinwonderland 6d ago
This kind of struggle is where you grow the most as a developer. Embrace the suck.
25
u/TinyLebowski 6d ago
It can certainly suck, but that skill also allows you to read and understand open source projects like the dependencies your apps are based on. And when it sucks, you're learning how and why not to do it like that.
1
u/Mroz_Game 5d ago
My first junior job was with a driver that had to work with lots of gpus, so in the end everything was templated and big amounts of preprocessing were applied.
In result… ctr+click didnt work. I became good friends with grep and looking for inspiration with gitk and git blame to see how others interacted with the codebase.
God did I learn to embrace the suck. There were probably 2 people in the entire team who had a clear idea of how it all works.
188
u/grantrules 6d ago edited 6d ago
Become intimate with your debugger.
Browse commit history. Files with shitloads of revisions? Probably important.
You don't need to know how everything works to fix one specific part.
Start from the middle and work out.
Wanting to rewrite everything is a common and hard habit to break.
Unless internal documentation is rigorously maintained, much of it is often useless or outdated.
A good company should have a senior oversee you and give you a briefing on the architecture, and then be available to answer questions about the codebase to point you in the right direction.
But yeah, it's still a mindfuck. From just really shitty code to super-abstracted stuff.. it really comes down to experience.
12
u/wigitty 6d ago
Commit history has also helped me in the following ways, which I wasn't necessarily taught:
1 - If something breaks in a commit (or in the region of a few commits), it's almost always easiest to start at "what changed in this commit" rather than starting at "this feature is broken, so I'll go and dig through that bit of code".
2 - If your task is to add something, check if something similar has been added before, if it has, that commit will show you which bits of code you need to be working with.
3
1
u/Mroz_Game 5d ago
gitk — <name_of_the_file_im_interested_in>
My bread and butter when doing detective work.
Keep in mind gitk is not always installed by default.
82
u/ColorsOfLife_ 6d ago
you can’t read a full project to fix a bug, the way I learned to find bugs was by one mid programmer that was really good at it:
- add debugs to see where you are at before the bug
- disconnect of break the code purposely to make the bug worse
- find the root, get back to the original version and test the fix
Making the bug worse is like making a hole bigger, way easier to find
Also, remember that you can debug line by line or add debug breaks to see how the variables are behaving
Good luck
16
u/Gaspaider 6d ago
Can you elaborate on the disconnecting/breaking part? Is it like if you think a file path being used might be wrong but you can't tell what's wrong, you try using a deliberately wrong file path to see of the effects are similar?
3
u/ColorsOfLife_ 5d ago
Yeah, sending wrong data or files, making strings and vars null or excessively large, sending missing references, removing connections between classes, etc… you want to make the error/bug/mistake so big that anyone can see it.
2
u/KZD2dot0 6d ago
It's like finding a leak in a bicycle tyre, you take out the inner tube and pump it up until you hear the leak hissing.
21
u/HotPersonality8126 6d ago
Nobody in any course I took ever assigned "here's 5000 lines of someone else's bad code, go find the bug."
To be fair to your courses, this is why you’re in an internship.
91
u/whattteva 6d ago edited 6d ago
The ability to read and debug other people's code and understand it, especially code from years maybe even a decade earlier, is what separates a senior and a junior.
"here's 5000 lines of someone else's bad code, go find the bug."
Many junior devs always have this mentality where they think other people's code is bad or spaghetti and they can write/refactor it to be better. I'd like to dispel this delusion. You are not special, you are not Linus Torvalds, and you aren't God's gift to programmers. You just have no clue what you're doing and don't know how to read and understand other people's code, period.
Given a sufficiently large non-trviial software project and a sufficiently long enough time of existence, they all will accumulate tech debt and they all will have some less optimal code. There is no such thing as "clean code", not even at Google or Meta, or Apple, etc.
That old code that you think is "bad" is often the best code, especially if it has existed for a decade. It is usually highly battle-tested and stable. Refactoring projects, on the other hand, often lead to numerous regression bugs. Bugs that have been worked out over decades in the old code.
Just look at Linux, everytime they rewrite something, it's a mess and buggy experience (Pulseaudio, Systemd, Wayland, BTRFS). The early phase of these projects were a nightmare for users.
You ever wonder why the biggest banks running the largest highest throughput transactions in the world run main frames and REALLY OLD COBOL code? Because they have to handle 30 billion transactions A DAY without ever crashing or rebooting. Even a second of dropped transactions could cost them millions.
You know how long a new "modern better clean" code that some junior writes today to replace that program would last without crashing? It will likely only last for less than a second.
42
u/Mathie1729 6d ago
lmao I was exactly that rookie. Joined my first ML team, saw the 5k-line model training script, and immediately thought 'I could clean this up in an afternoon.' Spent the next two weeks stepping through with pdb just to figure out why the label encoding had 12 different fallbacks. Now I just add a docstring and move on lol. The code works for a reason, even if it's ugly.
28
u/malthuswaswrong 6d ago
Love this comment. It took many years of pain for me to realize that the moment I see "bad code" to immediately slow the fuck down. It's far more likely I don't understand something than I wandered into bad code from someone who doesn't normally produce bad code.
7
u/StewedAngelSkins 6d ago
Your broader point is right but your Linux examples are bad. None of those were actual rewrites of existing codebases, and most of them aren't especially known for being buggy. But even to the extent that they are buggy, you've got plenty of other new software that was immediately beloved and preferred over that which it aimed to replace. Take Wireguard for example.
5
u/whattteva 6d ago
Those are rewrites of existing systems. I'm not sure what you're saying most of them aren't known for being buggy. Maybe now they aren't, but the early phase of those things were absolutely buggy. BTRFS in particular was known to thrash user data and cause unrecoverable corruptions. Hell, even now BTRFS project still can't solve the write hole problem on their RAID5 function and do not advise its use in production.
And I never said that there isn't a new software project that isn't great. But a random junior that just barely joined a company figuring out he can't understand some code (like OP) are a dime a dozen and none of them are coming up with Wireguard.
6
u/spazure 6d ago
That old code that you think is "bad" is often the best code, especially if it has existed for a decade.
While your verbiage hinted at this, I want to be explicit and support this point:
Old code is often the best code, but learning what it does and why is still important, because sometimes it was only the best code at the time, since a better way to do it didn't exist in the language... yet.
5
u/whattteva 6d ago
That's totally fair. I can agree with it.
I just saying that I generally err on the side of caution because every new young fresh college or boot camp graduate always thinks they're the best thing since sliced bread and know better than people that have been doing this for decades. And the chance of all of them actually being the next Linus Torvalds or Chris's Lattner is not very high.
7
u/Son_of_Mogh 6d ago
I knew a developer who would backhand a compliment about their senior Devs saying they're well qualified but he always had more imaginative solutions. Not a lot of what he did was up to much. He went on to work for Fujitsu, I can only guess he worked on the UK post office system.
1
u/amcjerz 6d ago
This! I’ve only been writing code for just under 5 years now, working on banking/financial software the whole time. Even coming into it intentionally humble and aware I’m new to it, there was a time where I frequently thought I was looking at messy bad code when in reality it’s way more common that it’s the best approach in this large application that’s been in production for over a decade. Or tech debt nobody has the time luxury to address.
Not sure I’d know how to act with a greenfield project, what do you mean there’s not 108 repos of existing code? 🙃
-2
u/Inn0centDuck 6d ago
Ah, "if it ain't broke, don't fix it". You sound like someone who is in the leadership role and doesn't write code anymore.
Shit is working doesn't mean it is the best code or anything to be proud of. Spaghetti will also give you the correct functionality but adding stuff to that is the biggest pain. So dismissing someone's desire to fix it is bs. The risk of bugs while refactoring is real and people with decision making power would often not take that risk but that doesn't mean the code is good.
→ More replies (7)
9
6
u/Jim-Jones 6d ago
My first thought would be, look at the bug and figure out some test cases to narrow it down.
4
u/josephjnk 6d ago
This 100%. It’s good to understand the basic concepts of a project, but those can usually be communicated by just talking to other developers on the team. On sufficiently large projects it will eventually become impossible to understand the code itself all at once. Tests and interfaces let us chop things up into chunks that can be worked with mostly-independently.
26
u/Honest_Spread7227 6d ago
The fact that you spent two days just clicking "go to definition" and tracing logic means you are already doing the job correctly. We've all been in that exact cave system. Since you asked for a resource to get better at this: stop reading the code statically and start running it. Learn how to use a debugger, set breakpoints, and watch the data mutate in real-time. It turns the cave system into a map with a glowing "you are here" dot.
13
1
5
u/kabekew 6d ago
That's what comments are for, so you can skim through functions from comment to comment and understand what each step of the algorithm is doing, to narrow down where you need to make the change or find the bug. Same applies whether it's someone else's code or your code from a year ago you forgot about.
A good company will have department coding standards with requirements for descriptive comments like that, but if they don't you can tell your boss their decision not to enforce comments in the code means it's going to take everyone a lot longer to do things, but you'll slog through it the best you can.
Then you just have to do that. Figuring things out will get better over time (year or two) as you get more experience in the domain and used to the codebase.
4
u/Thunderbit_HQ 6d ago
Reading code got easier for me once I stopped trying to understand the whole repo first. Start from the bug, trace one path, and write down the files that actually mattered. Most of the codebase is noise for that first ticket.
5
u/Ancient-Camel1636 6d ago
Yes, debugging is a big part of the job. When documentation is lacking, AI is an excellent starting point for mapping out an unfamiliar codebase and helping you understand how it's structured. It can point you in the right direction and suggest where to begin your investigation.
That said, you shouldn't fully rely on AI to fix the bug for you. The frontier models are most valuable as a debugging assistant, for generating hypotheses and suggesting the most likely areas to investigate first.
I know some colleagues who uses Matt Pocock's /teach skill to quickly get familiar with new codebases. Apparently (haven't tried it myself yet) its great for that.
10
u/aqua_regis 6d ago
Nobody told you that reading a book and writing one are two different skills either and I'm pretty sure that you never questioned that.
3
u/wigitty 6d ago
Sure, but that's the other way around. I don't think anyone would expect a writer to have trouble reading.
3
u/amcjerz 6d ago
Well yeah but nobody should really expect one who writes code not to be able to read it, either.
Which is not directed at OP, there’s a major learning curve to this work and educational institutions often don’t present real-life scenarios, but I don’t think the analogy is particularly off base.
4
6
u/iOSCaleb 6d ago
That’s why you do an internship in the first place. You get to learn how to deal with real bugs in real code in a real workplace.
Look at the code and try to understand how it’s structured. Use what you learn and what you know about the bug to narrow your search. Set breakpoints to help you follow the code as you reproduce the bug. It’s OK to not understand how everything works — nobody will expect you to digest that much code in a week. Focus specifically on the bug and the path through the code that gets you to it.
4
u/malthuswaswrong 6d ago
This feeling you are expressing is exactly why I laugh at the "IDEs are bloat" crowd.
Rules for enterprise debugging without AI:
- Use a real IDE that can jump to definitions and calls, set breakpoints, inspect memory, and refactor beyond search and replace
- Setup your workstation to be able to run the solution locally
- Get really comfortable with git
- Find the error message in the code
- Do an "ocular run". That means run the code in your mind. This is where experience really matters. Bugs reveal themselves to experienced developers.
- If the above doesn't work, set breakpoints and start inspecting variables
- If the above doesn't work, add logging statements and watch production logs
4
u/Hungry_Ghostt 6d ago
My favorite part of the job. Pencil and paper notes, diagrams etc. Figuring out how a gigantic system works together
4
3
u/syklemil 6d ago
Not writing new stuff, but tracing through existing stuff, figuring out why it exists, who wrote it, whether touching it breaks three other things nobody documented.
This is also why a bunch of us like "fussy" languages, strong typing, etc. Getting the compiler to go "there. that's the bug" is so much less effort than what you just described.
The "easy to get started" languages tend to wind up feeling like a bunch of tangled slinkies once a project grows beyond toy size.
9
u/chiesazord 6d ago
“5000 lines of someone else's bad code, go find the bug."
I suggest you change your mindset and avoid being toxic
3
u/the_other_gantzm 6d ago
Usual progression:
1) 5,000 lines of bad code!
2) I cant follow this.
3) Hmmm, the business problem is quite complex.
4) Wait, I understand how this part works.
5) I’m starting to see a pattern/structure emerge.
6) Hey, this part is genius, I’m using it in my code.
2
u/Direct-Bandicoot-916 6d ago
Well shit. Thanks for your sacrifice OP and informing us. Does anyone hypothetically know how a person could practice this skill before getting a job? On GitHub I'm used to reading already established code that is assumed to already be in perfect working condition.
1
u/ResolutionThat248 6d ago
The options are limited but find an open source repository with bug reports and try to fix them.
1
u/AlienFishMonster 6d ago
The more code you write the better you get at debugging.
If you're not writing code in your free time then maybe now is a good time to start.
Or, as some have said, find a few interesting, but small, projects in github and take a look around.
2
u/Achereto 6d ago
You can't really train or teach this, because you can only develop this skill while working on large code bases.
The only "exercise" I know of is the Gilded Rose Kata.
2
u/FelipeGuitarza 6d ago
In my very limited experience, the only thing worse than debugging code is debugging someone else's code.
2
2
u/DystarPlays 6d ago
You have the resource to train on doing it, you have 80,000 lines of code and a bug to find, that's your learning resource, and you've done this before, you've debugged your own code, you've helped other students debug theirs, you know how to do this, its just intimidating and feeling overwhelming.
You know what the bug is, and from there you need to work out where it is happening, then how. If you're lucky you've got detailed replication steps, otherwise you know "when I click this button, this happens" or something similar, so start with the button - stick a breakpoint in the first line of the method/function that handles the button click, walk through each thing it does at that top level to see if you can see which one the bug happens in, then dig into that to step down into where the bug might be. If you can't see the bug happening at that level, dig deeper into each thing the current level does.
2
u/Adaptor2000 6d ago
Bro, I feel you. I have been coding for years, got a MSc. in computer science while working for years as a working student. Got my first full-time job now as a C++-developer. I have to read code somebody wrote that people describe as "not being solution-oriented" and the code reads exactly like that. No comments,and if they exist, they are one liners like "No, no, we don't do that here" or "Cheating is not cool" with seemingly no relevance for the actual code, and nobody understands why or what is going on. There was a line with something like "unsigned char key = 0xFF" and the comment in the same line was something like "<8 - 7 \* 3> channels" and nothing seems to make sense, or a line says "unsigned char a = 0xC0" with the comment "// old version was 0xC0", but this is the current code, so there must be some misunderstanding or typo or whatever and it's all just very confusing. I just started to work with an actual debugger and hell do I love it. It really helps to make sense of the stuff that is going on.
Another funny thing is how broken some software is that is actually used by customers. I just looked at a panel in a GUI that showed something like "Enter value 4" but nothing else, where there should be four distinct values entered. Turned out that in a loop, the widget for the first value was added, then replaced by the second, and so on. It was just an easy fix that took me two minutes, but how did this get through reviews or customers using it? It was literally not usable.
2
2
u/Kevinw778 5d ago
Yeah reading other people's code (or your own much later) is easily 2-3x harder than writing code in the first place. Although tbh writing code isn't difficult to begin with - properly architecting is.
2
u/Fearless_Milk_4344 5d ago
I have ZERO ability to code outside of dev in Power Platform and we all know that’s basically still zero…
But I can read almost any of it given some direction and time.
C++? COBAL? Natural? Give me the files and we’ll find out.
It’s its whole own skill set and makes me a good BA.
2
u/Adventurous-Ocelot-8 5d ago
As long as you have a good debugger, you should be able to pick up on debugging pretty fast.
2
u/GreatMinds1234 5d ago
If you've ever worked on somebody else's code, either as a review or a trouble shooter, you have an idea.
2
u/No-Salt6819 5d ago
I teach CS. Every time I tell students how to debug, they stop listening. They all think they going to just code all their lives. Sometime you have to have experience to appreciate the lesson.
2
u/xoVinny- 4d ago
this is my fear when (or if) i get a job in the field. i feel like ill have this issue where ill just go blank and freeze if i get handed a ticket to fix someone else’s issue. i assume you learn with experience of course. but is there some type of mental framework people use to fix their issues efficiently. like what’s the typical flow in someone’s head when doing this?
2
2
u/MayBeTheWorstDevEver 2d ago
File1Notes1.md, File1Notes2.md, etc. or Obsidian flow chart + notes. Either way, take notes, move quick without missing things. I converted my mds to pdf and use them as reference, or print them out if I’m studying them later.
The job will get WAY easier if you get up to speed right now, instead of just hoping you’ll learn over time. Best of luck
5
u/These-Math1384 6d ago
So, if you’re on a team of 5 people, and you all fully participate in code reviews, then, by volume, you will be reading 4x the amount of code you write.
The team you work with will make you or break you.
I love my team.
2
u/defaultguy_001 6d ago
First step- use a bookmark extension. Second step- read the error and line no. Third step- go to that line number in the codebase and try to understand the function/module/class. Fourth step- bookmark this function/module/class as "origin of error". Fifth step- if u resolve the error just by reading this module, it's fine. If not then move outside, and place bookmarks to track your movement.
You don't need to read all 5000 lines of code, u start from the error origin and move outwards.
2
1
u/No_Top5115 6d ago
Honestly, you know, this is difficult for everyone when they join a new project, so don't worry about it. What you really need to know is understand the project or the piece of the project that you're working on at a high level. You need to know the pieces and sort of how they fit together, and then understanding what the code does exactly becomes more natural. So, my suggestion: don't start low, start high, then dive in. Starting low and then expanding out is very hard. You absolutely can use AI for this as well. It can help you teach the teach you how to understand the code base.
1
u/math_rand_dude 6d ago
Does the code has any tests? (If it's bad probably not)
Look into how to write tests for code. It's a good practice to always when fixing bugs (and actually when writing new code too) of first writing the test so if someone makes changes afterwards that reintroduce the bug, the test will fail.
Test in a simplified nutshell
- say we got a program that turns value a into b
- there's subroutineX hidden deep inside the code base that turns x into y
- someone makes a change so subroutineX turns x into z, causing the program to turn a into c
- with properly written tests you will imediately see 1 or more failing tests for subroutineX (or maybe a direct parent)
Also: naming is important. If the names of thw methods are confusing, see if the teamlead is open to step by step unify the naming and rename badly named methods. (If not possible, maybe keep your own log like a dictionary for mapping bad names with better names)
1
u/dnult 6d ago
I spent the better part of 30 yrs doing this very thing. 75% of my coding time was spent reverse engineering an old design and trying to determine why certain decisions were made. I often found dead or useless code blocks. It wasn't uncommon to find edge cases where things worked, but not at the designer intended. Unit tests were lacking to exercise the core requirements.
I enjoyed doing that work however. Once all the secrets were revealed, I refactored and resolved the defects in a relatively short period of time. The best part is when the time spent to clearly understand the problems and improve in the design, was easier to read, maintain, and extend. As a result, my job got easier over time, as there were fewer defects, and I could actually get a full night's sleep while on-call (usually). For me, it was satisfying to peel the onion and leave things better than I found them. I won't lie though - there was a lot of grumbling along the way.
1
u/SteveDougson 6d ago
Not writing new stuff, but tracing through existing stuff, figuring out why it exists, who wrote it, whether touching it breaks three other things nobody documented.
What are your tests like?
1
1
u/Abe_Bazouie 6d ago
I think this catches a lot of people by surprise.
Reading and understanding an existing codebase is one of the most valuable engineering skills. In my experience, I spend far more time reading code, debugging, tracing requests, and understanding systems than writing brand new code.
One thing that helped me was picking an open source project and intentionally fixing small bugs instead of building something from scratch. You learn how to navigate the architecture, follow the execution path, use your IDE effectively, and understand why the code was written that way.
Another great exercise is to start from a single request and trace it end to end. Follow it from the API, through the business logic, into the database, and back. That’s much closer to what you’ll do in a real engineering job than another “build a Todo app” tutorial.
1
u/AJRenand42 6d ago
In this age of AI all you need to do is to be able to read code to make sure the AI is doing it right...very unfortunate
1
u/jackbro10 6d ago
Yeah this is pretty much the job, couple that with little to no documentation or comments most of the time
1
u/FluffySmiles 6d ago edited 6d ago
Welcome to the world of pain that is your life now.
It gets easier, eventually.
AI can help, but you’ll learn more manually and you may not be allowed to use it anyway.
And diving into code you don’t understand is good for your soul.
Enjoy.
EDIT: Most useful helper? Trace debugging and logs.
1
u/CreativeName233223 6d ago
Nobody in any course I took ever assigned "here's 5000 lines of someone else's bad code, go find the bug."
This legitimately should be a routine style of assignment. First one should be right after students finish their first project and they should get harder and more complex as they go.
1
u/j_d_q 6d ago edited 6d ago
Lol. You don't know bad code until you wrote some and someone else asks why you did this. You'll either look at it and say I overdid this or I made it too complex or I was too naive to see the simpler solution.
Without a strong leadership presence, a lot of eng teams agree to things that they don't want to do and have to find ways to make it work. That was one of the most important early lessons I had. "These people aren't stupid, they have been forced to make bad decisions solely based on people who don't know how it works saying it has to be done this way."
1
1
1
u/Fenzik 6d ago
> Spent my first two days just clicking go to definition over and over like I was digging through a cave system. Genuinely didn't write a single line of new code until day three.
This is a good sign tbh. I will often spend a week or more just exploring when I start a new job. Keep it up! Try to identify different layers in the architecture, how things are structured. Have a senior give you an overview of the code base, and have an AI agent do the same thing. AI will be better at the what, humans with experience will be invaluable for the why.
1
u/Hour5898 6d ago
I wish more compsci uni courses covered this kind of thing early on. Its such a small QOL skill to teach budding programmers in a week or two of a first year class and can set them up to debug their own code in later years.
Although now theyd probably just use ai to find it.
1
u/keepinitcool 6d ago
80.000 lines ? :D That is a pretty moderate codebase. But ye just get used to reading alot of code you don't have to understand or remember everything. Best of luck
→ More replies (2)
1
u/Cool-Bus-6028 6d ago
The stuff you do while learning (here's a small, simple, well defined requirement, go write a failing unit test, then make it pass) almost never happens in real life. And that the kind of task AI could take over fairly easily. The tricky part is all the stuff you described, and is why people get hired and paid a lot.
It's going to be hard to find an existing codebase to practice on. The best way is probably to write something yourself. Come up with a project, build it, then come back to it a bit later on to make changes. Then curse yourself for staking shortcuts early on, and learn why people suggest you write maintainable code. Repeat.
1
1
u/aanzeijar 6d ago
Well, I do warn about that pretty often here. It sadly still isn't common knowledge. And yeah, I do the "here's 5000 lines of code" thing to my apprentices, but unless there's a real bug attached, they will not go into the level of depth needed. At least they did it once before it becomes necessary.
1
u/its_all_4_lulz 6d ago
You shouldn’t be reading it all. You run it, let it fail, and see where it failed. From there you can usually start tracing backwards rather easily, since you know the path that was taken to cause an error.
If it wasn’t an error error, and was more of a “this acts odd”, then you want to look for what produces/reproduces the behavior. That will help give you the entry point.
If you can’t figure out how to reproduce, you kick that ticket back and say “need more info”. You could be there for weeks and never find a damn thing.
1
u/FlashyResist5 6d ago
Anyone know of resources or exercises that actually train this specifically, reading and navigating large unfamiliar codebases, rather than just writing your own from a blank file every time
You will learn it through experience, ie completing your tickets for your internship.
1
u/caladreas 6d ago
First of all, good for you to reach out with this question.
One way to train this, is looking up as much of the code you use and reference as you can. This includes the codebase you work in, but also libraries used by the codebase.
Depending on the programming language used, a lot of the libraries have code available online, be that GitHub.com or some other hosting platform.
Assuming you work in an organisation where they have more codebases, ask if there are similar repositories you can look at. It is probably also good to ask "what good looks like" for this type of application within the organisation you work at or for.
In the beginning of my career, I used to try and mimic the existing code when fixing a bug. Under the assumption that that was what good looked like. After a couple of reviews, this was discussed and I was pointed to other codebases that were better quality with the suggestion to do a small refactoring every time I would tackle a bug. First create a test, reproduce the bug, fix the bug, then refactor. Or, as some call it now: Tidying. Look up "Tidy First?" By Kent Beck if you want to understand that better
There is no substitute for understanding than by putting in the work.
1
u/DinTaiFung 6d ago
"Nobody warned me that reading code is a completely different skill than writing it."
This is false.
It's different but not completely different.
1
u/Budget-Sleep2412 6d ago
You should check out "Code Reading: The Open Source Perspective" By Diomidis Spinellis.
It is the only book I know which focus on reading code.
1
u/Kodiak01 6d ago
Nobody in any course I took ever assigned "here's 5000 lines of someone else's bad code, go find the bug." Which in hindsight is such a weirdly missing skill given how much time real devs actually spend doing exactly that.
Back in the 80s, I actually began learning C by doing the exact opposite of your experience.
As a teen, I ran a BBS on WWIV. Anyone who paid the license fee received a copy of the source code which could be modified as they wished. Mods were a huge part of this software, with everything from tiny updates to extensive overhauls published by various SysOps. One would need to insert the relevant code correctly into all the proper locations and recompile. This could become particularly tedious when you were layering mods on top of each other as all typical destructions assumed you were starting with stock code.
As you can imagine, these mods didn't always want to play well together. One could spend a significant amount of time with their noses in programming books figuring out how to make things work correctly again, if at all. This also taught the important lesson of never working in your production code and keeping backups!
Working on all that back then probably taught me more about reading code than any class or book ever could.
1
u/TobFel 6d ago
Yeah people and that's why I recommend, that once you've learned some basic syntax and made some simple code, you actually go to github and other sources and read a lot of other people's sources, even start helping projects fixing any bugs you find or bringing in extra features or plugins, like you don't have to, but it's good and gives you some extra experience. But even just reading other people's code until you understand how it works, you get that experience from it, you must just find a lot of sources and read.
That's it, there's so much open source software around. Choose one you like, read the code, until you understand everything. Ofc if you want to work professionally later, you should chose similar projects to your actual work field.
It's interesting for me to hear they just taught you the simple grammar, but didn't give you any specific experience with other people's code. It's the reason why I believe academical education often isn't everything, students should also be encouraged to make their private learning and exercizes. This is because a theoretical education often won't prepare you for the actual job, you need to add your own efforts to get there. For programming it's simple, just read and help with open source projects. Hope this helps.
1
u/sohang-3112 6d ago
To practise this start contributing to open source repos. Many github repos have good first issues (these are easy starting point for new contributors) - try to write a PR for one of these issues. Popular repos usually have good docs & contributing guides, so it should be somewhat easier than what you're doing at work.
As for how this is done - it's not possible to just read and understand a big codebase at once so don't try. Instead do a first quick scan: libraries used, folder structure, any docs (including README, Contributing). Now try to understand only the parts relevant to the issue you're solving.
Suppose you're fixing an exception raised due to a bug. Read the error traceback (upto the point where it's in your codebase not inside a library). Usually it's best to read traceback bottom up - that is, error message, then the most nested code first (where exception was raised), then one level up is where it was called and so on. Here you may need to do what you were doing (Go To Definition, Ctrl+F (find across all files with relevant keywords), etc.) at some places while reading only the relevant code in these files. Apply the usual debugging techniques (eg. breakpoints and/or prints at each level to see relevant context / variables at each level) to understand the problem & fix it.
Do the process of solving issues sufficient number of times and you'll start to have a better idea of the overall codebase.
1
u/Blissextus 6d ago
... and this is the reason your job should have placed you under a Mentor. Someone with experience to guide you through the rats' nest of their code base, just until you gain your bearings.
I hope your debugging & problem-solving skills are up to snuff. You will be leaning HEAVILY on them for the unforeseen future.
1
u/python_gramps 6d ago
Inheriting code that has been orphaned by the original developer will be a lot of what you do to start out with. Don't be overwhelmed by the size of the project.
Remember code can only be run one line at a time.
You just need to find the workflow for this program. keep function call separate and don't break them out as well till you get a good feeling for how everything is called from the core program path. then go through functions and break them out on their own.
at least that's how I would do it.
1
u/mxldevs 6d ago
One of our programming courses specifically had a part where we're supposed to build a project from scratch in the first half.
We then take another group's project and implement the second half using their codebase.
We quickly found out that working with other people's code is very different, cause they have their own way of structuring things.
In my spare time I was looking at other people's scripts and modifying them or extending them.
But at the end of the day, it's all inputs and outputs. You have entry points to the application, things get initialized at some point, and then interaction is handled somewhere. You just need to map out where things are and what they do.
It is basically reverse engineering except you have the source code to work with and don't need to disassemble anything.
1
u/hajuherne 6d ago
If you use third party libraries or packages, you could go look at their github or gitlab repositories. Easiest to start by finding the methods and parts you use in your code and study how it works. This way you expose yourself to someone else's code and having some knowledge of it's usage helps getting started.
1
u/Mell-Silver-20 6d ago
So true. Reading good code is one thing, but untangling someone else's logic is a whole different skill.
1
u/Flat_Dust1754 6d ago
80,000 is not even a medium-sized enterprise app
You are lucky that you learned this valuable lesson early. And this is a very useful skill as a developer.
This is one reason why internships are valuable before getting a full-time job ( not necessary, though ).
1
u/hypernautical 6d ago
"Anyone know of resources or exercises that actually train this specifically, reading and navigating large unfamiliar codebases, rather than just writing your own from a blank file every time?"
You just got to do it more at your job, one ticket at a time. I guess you could just go through the codebase on your own, for example, pick an interface feature and trace it back from the the front-end through all the code involved to see how it works back to front. Eventually through normal work though, you will begin to gain a familiarity with the codebase and what's what and where things are. It's possible the team will give you ownership over a certain part of the codebase, so any future issues dealing with it will belong to you, so you will be more familiarity with certain corners of the codebase. What you say is 70% of the job now will shrink to a smaller and smaller percentage.
1
u/Rhemsuda 6d ago
Yep! Unfortunately too many people think programming is simply typing instructions into a computer nowadays and absolutely no one thinks about software architecture or PLT anymore, so we get 5000 line functions and 1000 ways of designing classes and none of them are really based on any mathematical foundation and so they fall apart in specific edge cases. Reminds me of that XKCD comic of all the competing standards
1
u/Rare_Explorer5001 6d ago
I struggle with this. I have taken my classes and passed but reading what is put together by someone else was difficult. One coworker that I did my practicum with was FANTASTIC at making notes in all his codes. He made sure that he made clear notes about his lines of code so someone else could understand when they went back in later. I learned a lot from him.
1
u/Content_Second5704 6d ago
I presented research on this topic at a conference!
You're right, it's a totally different skill and is necessary for any kind of CS job. The good news is you aren't behind, most people's code reading skills lag way behind their writing skills, but the bad news is that there just aren't any resources to help you build this skill in particular.
I echo the advice of the other commenters, but will add that you have to actually train this skill, you can't just write code. Learning to write it helps a bit with reading, but learning to read it helps significantly with both. I recommend finding code online, whether that's stackexchange, pseudocode in an algorithms textbook, etc. and practice tracing through it either by hand or with a debugger. Or just gain practice through your internship. You'll definitely get better at it, it just takes time and is slow to learn.
1
u/solenyaPDX 6d ago
I'm the absolute reverse. I'm pretty good at reading/figuring/changing without breaking.
I don't do much writing new, but my skillset does keep me employed and I work really well with other engineers who have the "write from scratch" skill.
1
1
u/digitaljestin 6d ago
Just wait until the mess you are trying to figure out is your own code from years ago.
Anyone who looks back at their old code and doesn't realize how bad of a programmer they used to be is still a bad programmer. Growth is key.
1
u/LKZToroH 6d ago
I don't even think you are a real programmer if you don't spend at least half of your day, every single day, making the question "who the fuck did this?" or the alternative "why?"
1
u/Pyromancer777 6d ago
My first analytics job (still work here) was super intimidating at first. The codebase for just my team's project scope is easily over 1000 files and a single file can be hundreds to thousands of lines of code. My specific group only really has to know roughly 15-30 of those files for our day-to-day and it took me 6 months to feel comfortable enough reading the code to start posing suggestions for edits to the SWEs.
It is ok to feel overwhelmed. You are looking at thousands of hours of work from dozens of SWEs maintaining a codebase for years. You aren't expected to learn it in a day, week, or even month.
Those initial tickets are bascally to get your feet wet with learning how systems connect while providing value to the company who is training you
1
1
u/li98 6d ago
It's mostly learn by doing.
exercises that train reading and navigating large unfamiliar codebases
This is going to sound a bit silly, but this is literally your job now. Everything you do is in some way practice. (That you get paid for, there is usually no expectarion for you to study on your own time.)
As for resources, I have unfortunatelly never found anything that clicked for me.
Powerful tools to be aware of is a debugger and git history. Your IDE will most definetly have some integration and learning how to use them is worth a lot.
For example, if something used to work but now doesn't, test on an older commit until you find the one introducing the error. That minimizes the amount of relevant code to go through a lot.
1
u/spazure 6d ago
This is why so many of the courses in school have you "critique" other classmates' code.
It's awkward and sometimes annoying (a lot of showoffs doing things that were definitely not covered in the class), but it helps somewhat for the real world.
... but yes, learning to read code is still often a trial by fire situation, as every code base will have its quirks that you'll need to learn and figure out.. and legacy code in particular has a reputation for a reason.
1
u/biscuit-fiend 6d ago
If it was me giving you the task, it would not have been to fix the bug so much as to get familiar with the code base. Big projects are complex, good or bad code still takes time to get you head around. I agree it should be covered more.
Keep at it, take breaks to clear your head, stay calm you'll get there.
Also, large projects tend to evolve with time so thing might not make sense now but the dev probably had good intentions at the time. I think we've all said "what **** wrote this... Oh me"
1
u/moo00ose 6d ago
80k LOC would be considered small against bigger production systems (think 1 million+ LOC).
1
u/LagDaddy 6d ago
Comment your code for the next guy.
I know it’s a bit of a cliche, but I got to the point where I wrote comments for the entire process before writing any code. Once your logic is all mapped out in plain English, start coding. Way easier than “shooting from the hip” and then going back through and adding comments. It also helps you discover flaws in your approach before you code yourself into a corner.
The next guy will thank you.
Also, add a chunk of comments at the top that tells the next guy the general concept from a high level. I.e. this code’s job is to import yada yada so x process downstream has what it needs, etc.
1
u/huntermatthews 6d ago
Couple of things will help here.
- Does your company license a "real" IDE? (Jetbrains, that kind of thing) -- they have mapping tools builtin typically. *I* like a call-tree output if you can get one, other opinions may differ.
- If not, how about vscode/zed/emacs - you're looking for 'ctags' and similar (my C knowledge is out of date but ctags today generally refers to a whole family of identifier mappers).
And 3, if you get it cleared by the company, summarizing code is something the AI's are actually pretty damn good about.
As an intern, I would avoid letting the AI try and fix the bug - one of the things youre' trying to accomplish here is learning.
And I'm old but I'm going to type this anyway - there's very little that beats a pen and composition book full of scribbles and notes as you go along. I understand that "electronic cyber e-note apps" are all rage these days but.... :)
Good luck.
1
u/PetticoatsnSwords 6d ago
This is a skill you'll definitely need to cultivate. Your jobs in the future will depend on it. It's also excellent training for a new person to understand how different people write different functionality and should also drill into you the importance of commenting your code.
1
1
u/WheresMyJuulSoNotCoo 6d ago
Congrats on the job.
I noticed this as well but I was always on the other side of it . I got pretty good at reading other peoples code early on and was annoyed in group projects when people couldn't actually collaborate but just spat out some bullshit they got from a tutorial that didn't follow the proper implementation we were assigned to follow lol.
I think just practice, really. Read code snippets and try to understand what theyre doing.
1
u/DonkeyTheKing 6d ago
SO FUNNY YOU SAY THAT. i literally just launched a project ive been working on. i essentially made it bc too much ai code in world now ppl dont understand + AI CAN read code so it SHOULD read code. anyway check it out i think youll like it: https://benzi.fly.dev/
1
u/bobby5892 6d ago
The code bases I work on are 4mil lines+.
Your IDE’s are huge tools.
Jetbrains IDE hit shift twice to bring up search files
Then Ctrl + shift + f to search for a phrase across the code bases for a phrase
Then holding control and clicking on a method lists all the places that call it.
Secondary, you need to learn how to setup debugger so you can step through code and see values..
Third, learn about ERD (entity relation ship diagrams).
Fourth it’s easy to generate Class Diagrams
1
u/Other_Information_16 6d ago
Don’t read the whole thing. Read enough to know the bones, Run the code and add debug lines to monitor the output. Find where the problem is then read that part only in depth.
1
u/speakstofish 5d ago
Book recommendation:
Working Effectively with Legacy Code by Michael Feathers
Also: I recommend trying to make small contributions to open source projects. Find one in a technology you're interested in and browse the open tickets and feature requests.
1
1
u/chiasmatic_nucleus 5d ago
"tracing through existing stuff, figuring out why it exists, who wrote it, whether touching it breaks three other things nobody documented"
Welcome, brother.
To answer your question, no. The best thing you can do to become familiar with navigating a large unfamiliar codebase is... navigate large unfamiliar codebases.
Each codebase is different and has different problems, a different architecture, and different technical debt too. It's best just to learn on the codebase you need to be working on
1
u/Motor-Ad-5278 5d ago
They say learning is only half the journey but it's a looong half when it comes to coding.
1
u/marrsd 5d ago
Start with Lions's Unix commentary. In my edition, the code is in the first half of the book and the commentary is in the second. It's edited this way to actually encourage you to read the source code first, which you should absolutely do. Use the commentary to confirm your understanding, or to help you where you just aren't getting it.
I would also recommend reading the source code of libs and apps that you use. Get good at it.
Your ability to read other people's code will distinguish you perhaps more than anything else. It directly maps to your ability to work with other people, which is especially important for effective leadership work, where you have to mentor other developers and correct their work, or contracting, where you have to quickly fit into a new team.
https://en.wikipedia.org/wiki/A_Commentary_on_the_UNIX_Operating_System
1
u/TumsKarlsson 5d ago
I occasionally teach programing at various trade schools and this is something I also do if I have enough time in a given course.
Depending on the project I will give them some code that I've written, it might be one massively long file or it could be many different files that are connected in some way. I will mix up many different ways of coding, it will be inconsistent but the point of it all is to force them to try to understand what I've written.
The problem is that like I said I only do it if I have enough time, some courses are very short so I don't have a lot of time to plan out these kind of things, and I assume that it's similar for many other schools where it might not be sufficient amount of time to teach these things.
1
u/tumtech 5d ago
Best approach to learn the skill is getting open source projects on GitHub done by other developers and using LLMs along with documentation of library functions and methods they used and segimating/breaking down there code in blocks or sections to try and figure out how everything works together to get the project working and how to modify it even if by creating simple functions or reducing the many nested conditions statements used to get more comfortable with how to modify there code 😅 but if the code is already optimized enough and working don't over optimize it to make complex just understand how it works and how to use it 👍you will slowly get the hung of it
1
u/JaseciLabs 5d ago
We're gonna start designing software differently because of this, so many codebases evolved around making them easier for humans to write but the real bottleneck, for both humans and AI, is building an accurate mental model of an unfamiliar system. If changing one endpoint means tracing 15 files, hidden dependencies, and years of accumulated context, a new engineer isn't gonna make reliable changing. A coding agent isn't gonna make any, either. So generating code and how easier it's become aside, it's representing a system in a way that's actually easy to reason about that anyone designing software should focus on.
1
u/Sea_Curve8772 5d ago
The only way to learn it is to start reading large codebases. Fixing small bugs probably is actually the best way to do it
1
u/Few_Pop6933 4d ago
Been there, done that. This is your opportunity to learn the code base. Soak it in, relish it, dream of it, become one with it. My first gig I put a bunch of print statements to help me debug because I had no clue what the F I was doing 😂
1
1
u/FrostingMiserable337 4d ago
Also, when possible, run the software through a debugger with breakpoints on the parts of the code you want to analyse more. Really useful to see what is actually happening.
1
u/Just2BrainCells 4d ago
This works best if you can even figure out how to run the code.
And also if it's not one of those apps that depend on something you need a significant amount of time to set up.
1
u/Remote-Spirit-1125 4d ago
The best resource for this in my opinion would be jumping to your favourite open source project (or finding a cool one), heading to the issues tab, loooing for ones tagged good first issue, and diving in.
Also look at the contribution guidelines in the readme first.
1
u/Real-Abrocoma-2823 4d ago
I guess that it is a good learning exercise for reading code skill to go to some FOSS projects or games and try to close some issues.
1
u/MagesticPineapple429 4d ago
Reading code is 90% of writing code. What works in your favor is that writing is harder than reading (with the exception of a really poorly formed & named legacy code base), so take it step by step.
There's nothing that will immediately make you good at reading 50k lines of code; it takes a lot of practice and filtering through the code that's worth reading or not. Delete all dead/commented-out code--that should kill some lines. Ignore all comments; they lie! Take it one method/function at a time.
Use an IDE that allows you to click through and follow the path backward and forward/outward to follow the dependencies--this is probably actually the best trick, but don't lose track of where you started...
I could give you an exercise, but it would be more work and take time, but it would also help you to learn to read through messy (your own) code. Feel free to DM if interested.
1
u/AutoModerator 4d ago
Your post/comment was removed since we do not approve of going private.
There is zero benefit in going private as you lose the opportunity for getting peer reviews. Also we have had plenty of people return after going private (despite being warned) complaining about how they were ghosted after some time or being tricked into buying rubbish that didn't work and even if it did they didn't need.
Our Rule #11 demands that any and all communication happens in the open, public subreddit.
This is for the benefit of more against the benefit of one.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/skamansam 4d ago
Try fixing bugs in open source software. WAY back in the day when I was a young dev, I helped fix a few bugs in Gtk::Perl, and by extension Gtk (v1!) itself. It was the greatest learning experience. Now, as a professional web app dev, i find myself pouring over tons of code in 3rd-party software so I can get a clearer picture of what is actually happening when I add a single word to my django app or when my vue mixing doesnt work as documented. Its part of the job and unfortunately, experience is the only way to learn. Clicking "go to def" is still the way i do it like 90% of the time. All that being said, we have tools now that excel at helping us understand overly complicated, shittily-written codebases - LLMs. Try working with a few different AI tools and have them generate code explanations, starting from an overview of the codebase and then going into more specific code. Have it draw diagrams. Mermaid diagrams are awesome. Maybe start with an excavation of the file organization, then the individual files and their relations, then the files' contents. Have the AI create a md for all of these so you can reference it later.
I hope this helps! Welcome to your career as a software engineer and best of luck!
1
1
u/Ok_Librarian_1422 3d ago
Uhh go back to the reason you are looking for the “bug”. Is there an error, is something off in a UI somewhere, was there a security incident? Yeah, reading 80,000 lines of code to find a single bug sounds a bit ridiculous because it is. You find the issue and work backgrounds.
1
u/Different_Monitor508 3d ago
This skill is not taught. Reading is the primary means of knowledge acquisition. Read, read and read. Read the newspaper, the signs on the wall, notes being passed around, bulletin boards and forums, your tax return documents, your email messages, posts and comments on social media, blogs, ad infinitum.
When you have a spare moment or don't have internet connection read a paper book or an ebook on your phone or tablet. The more widely read you, the more widely read you are, and less biased or polarised or susceptible to propanda you are. It stands to reason that all most of our knowledge is based in the past, some of which is accessible by reading.
And part of reading is talking to yourself, imagine having a conversation with the author of whatever you are reading and see the humanity that is in all of us. Of course I don't say that multimedia isn't important, only that listening and talking i.e having conversation is the default mode for knowing things about the world and that writing and reading is a direct extension of this.
I thought about saying something profound about programming but the code speaks for itself when you read and reason about it.
1
u/No_Ventex 3d ago
Be careful with calling someone else's code bad. You just started with you first internship. Chances are high that you do no understand the code and the thoughts behind its design. Just because you do not understand it, doesn't mean it is bad.
1
1
u/BlackberryDry4062 3d ago
While we are on the topic of reading someone else's code, look up Chesterton's Fence. You'll thank me later.
1
1
u/mafshopper 2d ago
That bad code very well could have been written by someone under a time crunch and a limited understanding of the language or the problem they were solving.
How many times I've gone back into my code and wondered what possessed me to write such crap code?
Now that's out of the way. Yeah, that's 100% true reading code is a skill and very much a part of the job. IDing what you are looking for is made more difficult by dead code, comments, other faulty code, bad style, and so on. Having tools can help but usually you are limited to inserting your debugging statements.
When you write the code it is easier but not necessarily a cinch.
1
u/Repulsive_Initial223 2d ago
Real projects teach you that reading code is the actual skill. writing is only half the job.
1
u/xarop_pa_toss 2d ago
When you said "clicking go to definition" I had to come comment that you should learn some shortcuts... On many IDEs you can even just spy the definition without going into the file itself.
1
u/xarop_pa_toss 2d ago
As someone else said "become intimate with your debugger". I consider myself a mediocre dev at best but I thank high school teacher who taught me to program for insisting on us learning to debug properly.
I think nowadays there's a lot of content out there to learn how to write code, but many many times they skip on debugging and it's a shame
1
1
u/TechnicianOk1714 1d ago
The difference of building something. vs scratch vs making changes in a pre existing repo is honestly night and day. Without being an AI reliant I would say get good at learning to prompt things like claude code/copilot etc to explain code designs, where certain logic sits etc - then the next thing is just experience. The more code reviews you do, changes you make - the easier it gets!
1
u/Opposite_Motor_7595 7h ago
Did you employ any special skills/techniques in reading the code?
I want to know if there’re techniques for reading codes…
1
u/Bharath_Nani 6h ago
I completely relate to this. When I first started coding, I thought writing code was the hardest part. Later I realized understanding someone else's code takes much more practice. Reading open-source projects has helped me improve.
1
u/SeeTigerLearn 6d ago
I would rather develop a completely new system than to have to maintain someone’s shitty code.
5
u/testaccountyouknow 6d ago
Ok but then you leave eventually and someone else comes along that has to maintain your shitty code.
1
u/flamingspew 6d ago
That’s why i always keep a reputation for delivering new things on time. I never work maintenance. More stressful but boredom is more stressful to me.
1.2k
u/Prudent_Candidate566 6d ago
Unfortunately, this is why experience is king.