#CodeOverwhelm #ProgrammingStruggles #NewbieQuestions
Hey all! 👋 Do any of you guys feel overwhelmed when you look at a huge amount of code? I know I do! Sometimes diving into a project written in Ruby or JavaScript can feel like a daunting task, especially as a newbie in programming.
Here are some thoughts and possible solutions to help ease that feeling of overwhelm:
– Take it step by step: Break down the code into smaller chunks and try to understand each part individually.
– Practice makes perfect: The more you work with a language, the more familiar and comfortable you will become with the syntax.
– Reach out for help: Don’t be afraid to ask questions on forums or seek guidance from more experienced developers.
– Utilize resources: Online tutorials, documentation, and debugging tools are your friends in deciphering tricky code segments.
So, how do you handle the overwhelm of a mountain of code? Share your tips and experiences! 💡 #CodeNewbie #TechHelp #ProgrammingCommunity
Kinda. It’s often hard to read other people’s code, but if they have used proper naming conventions it’s usually much easier. It also depends on how familiar I am with the language as a syntax I don’t know can throw me off a bit, and then I’ll have to read up on that syntax; that’s a great learning opportunity. I don’t have a feeling though that I need to understand every single bit of someone’s code. I read the bit closely if I need to not only understand what it does but how it does it, or if I’m curious.
Hey man. Ruby and JS developer here. Yeah it is overwhelming but basically the structure of backend and front end will be always similar(not the same) components can start to look familiar after some time. So yeah it will get easier.
it does get easier the more you do it, but it never gets easy to read other peoples code. hell, i wrote a script yesterday that im struggling to follow along today
As someone who has been self taught over the last two years (on and off and would consider myself an absolutely beginner) I have a project that’s currently sitting around 16,000 lines of code.
I try to name stuff correctly and generally comment what a particular section of html, css, JS is doing. Both for myself and in case this ever ends up being looked at by others.
But I always feel like surely no one that knows what they’re are doing does that, because if they know what they are doing they won’t need a comment explaining that a function (regardless of complexity) is doing “xyz”
How is something like this perceived by a senior coder (or rather how should it be perceived)? Do they open it up and go “thank God there’s comments” or do they go “oh great some n00b did this im gonna be in for work”?
I usually follow the [Grug Developer](https://grugbrain.dev/) 8-Step Program.
Step 1: Ugh! Grug not understand. Who make this? No scribbles on cave wall?? Grug reach for club.
Step 2: Grug wander aimlessly. Grug get lost in code jungle.
Step 3: Where this mess begin? Grug look for start point.
Step 4: Grug go line by line. Grug brain hurt. Grug confused.
Step 5: Grug grunt and curse more. Grug want to reach for club again but Grug stay calm.
Step 6: Tiny fire spark in Grug head. Ignore, still much to go. Grug focus.
Step 7: Read last line. Grug still lost.
Step 8: Repeat steps until Grug understand. Grug no reach for club. Grug now see through code fog.
Definitely you will get better at it, at quickly looking over code and intuating the structure and what is happening. It takes practice.
And is the dependant on the code being not bad, and organised well 💀
Not really. I’ve worked on codebases from a few hundred to a few hundred of thousands of lines by now, and it’s all equally terrifying.
Yes, a larger codebase takes a lot longer to read through, but you don’t need to read everything. You need to go in knowing what you want to learn, focus on that and get out again. No use trying to read everything.
As a side note: I’m more afraid of bad code than huge codebases. When documentations / comments are missing or bad, and the code is written in obtuse ways of switching styles midway through the codebase, I’m in for a really, really bad time.
No. You gonna get better with time. It’s just a freezing fear you gonna learn how to win. Think about the code as info that is there, and you gonna get to it later. Kind of like reading a massive book, or running a marathon.
I do the opposite, I focus on the tasks I’ve been given and the code relevant to that (obviously the wider project comes into the picture). I won’t go looking at routing if it’s not part of what I’m doing, because it is overwhelming on larger project.
But this has caught me out sometimes, because midway through a meeting something will come up, and i don’t know the answer. But then again, I wouldn’t know the answer to everything anyway, and PMs need to stop assuming I am some kind of 6 man team.
>As in, you can look at the code and understand it super quick
Nobody will understand a large codebase immediately, it takes time and you shouldn’t put a time limit on it. The best thing to do is to split it by component/feature, learn each one by one and use a debugger whilst breaking the app locally. It’s also important to ask questions when stuck to those that understand it better.
Don’t put too much pressure on yourself and do take breaks when working with large codebase. It becomes very easy to become overwhelmed and stressed.
At first… But then I start blocking it or chunking it up. Often that lets me see the structure and I can generally figure out what’s going on. Sort of like reading music or getting used to a Dark Souls boss XD
If a codebase has been written well, it’s safe to ignore most of it at any given time, and only look at the bits that are relevant to what you’re trying to do right now. This is also a good thing to strive for in your own code.
Real code often isn’t amazing, but in mediocre code, it’s often enough to know the code between the front door and where you are now.
But some code is just a mess. I’ve joined projects where the developers have warned me that it’ll probably be 6 months before I understand how it all hangs together. If you work on a lot of those sorts of projects, you can kind of get the hang of navigating swamps.
If I don’t understand the code, I just use the debugger and step through it. If I don’t understand what a function is doing, I just step into it.
Never failed me.
I have worked on some of the largest projects per loc. To put in perspective how large, I managed to delete over 1m LOC on one project… We still had millions.
The answer is it depends. You certainly do not have to go over everything. You learn to pick apart just the relevant parts. As time goes on, syntax becomes less of a problem, as it becomes second nature. However, there will still be things that throw you off syntax-wise. People do strange things. Strange strange things. Especially if there is any sort of templates/generics etc.
Reading code is still a time-consuming process, even if you master a language, different styles, code being pushed under a deadline, people’s approaches being widely different to yours, the age of the code base, etc all add to the complexity. It is a valuable skill to learn though, you will read code far more than you right it.
Some tips:
Rely on any tests that exist to guide you to the relevant sections of behaviour to keep you focused on what you need to understand.
If you have unit tests, writing tests to confirm your assumptions about codes can help you as well as increase test coverage.
Keep notes as you move through the code base, they will help when you need to remember how you got to a particular function.
Debuggers are great for testing assumptions, break in functions and look at your inputs and outputs.
Consitancy is important learn the patterns that the code base uses.
Again it all just takes time. Every new code base has its quirks and no one really expects you to be productive with a new code base for a month or two.
I’ve worked on legacy code that has hundreds of thousands of lines of code. It’s not well-written. There’s no time to learn the behavior because the logic is so convoluted.
But we’re able to work on the software because we don’t have to understand every little bit. The software has regular patterns and you can go through the web application and find break points, and just work on the problem in front of you.
That’s often difficult for new programmers to adjust to. They feel they have to understand everything to do anything. When you get to the point that you just have to fix a bug and it involves a few hundreds line of code strewn all over, then that’s what you focus on. You try your best to understand that that code path does.
If you’re trying to understand it because you want to build something just like it, well, that is a challenge. It would be nice to read documentation about the architecture of the code, but it may not exist.
Been doing this for 15 years. Still would get overwhelmed by large code bases if I just tried to read line by line.
I usually just try to get a good high level understanding and drill down on the parts that I actually need to work on. There is no need to read any sizable codebase cover to cover.
Ummm. No? I think?
I get overwhelmed when it’s small code I don’t understand and have little time to understand it.
I don’t need to know how getTargetUsers(a, b, c, d, e) works when I’m dealing with getRecommendedProducts(a, b, c, d, e). So I don’t care about the rest of the codebase until I’m working with it. Could be 1m lines.
But when getRecommendedProducts is 700 lines long and references 8 modules that aren’t semantic, and I need a solution this week for why it’s taking this function longer than 60ms to complete sometimes… that’s overwhelming.
You begin to think more abstractly. It’s not like senior devs can just read 1000 lines of code faster. They can skim through to find the important stuff and think more in terms of methods, classes, services, APIs, etc. I find reading logs and running the code with breakpoints can often reveal more than just reading a lot of code will. Hell reading a functional spec will tell you way more about the code than reading the code itself imo.
There’s also a major shortage of documentation a lot of the time from what I’ve seen. It is 100x easier to understand how a system works by looking at a simple diagram than trying to decipher a massive codebase. Think of a system design document that you whip up in an hour vs the code required to actually build that system. If you’re asked to understand how this system works quickly would you prefer to be handed a simple diagram, or just start reading the 1 million lines of code? A diagram gives you a quick abstract understanding, a million lines of code cannot be properly understood by a human. You would have to focus on the structure of the code, method names, etc. If I’m skimming the code and assuming how it works based on method names, just give me a simple diagram to achieve the same thing in a visual way.
The entire field is about managing abstraction and complexity imo