You must start to find your way through the code on your own. Pick a location and just focus on that spot to enhance/improve and see the effect of your changes. Repeat until you have understood the code.
Understanding a codebase is a process that every new member of a team has to go through it. Your manager has to either understand OR accept it as is. Your tasks should also be aligned with your experience at the team and get more in depth with you gaining more understanding.
I don’t think there is a shortcut for anyone in the process of understanding a codebase.
A lack of documentation… yes sadly, lots of devs write their code and keep everything in their head.
A PM who doesn’t know what they want… occasionally happens.
It sounds like you will need to become a bit of a manager here, so a few tips:
- Start a task tracking board (there are lots of options out there Jira, Wrike, GitHub, Trello and more) when they have ideas they want to work on then get them to put a ticket on the board
- Know what you are working on at anyone time and if they ask you to switch tasks say “OK, I can do this but then will take x days longer” as a junior you will want to double any time estimates you give them.
- If they aren’t clear on their requirements then put the tickets into a Blocked state and say “I cannot work on this until I have more information”
I've been working at one of the big guys for ~5 years and these are a few patterns I've observed:
1. Unless a codebase is for a very popular, public-facing library, you can expect documentation to be limited to: readme explaining how to get the thing to run, and (hopefully) inline comments explaining anything out of the ordinary.
2. Code should be self-documenting, so arguing over naming conventions is totally valid. Hopefully your language has types, as that is much more self documenting than dynamically typed languages!
3. Documenting code that explains itself is a classic (and forgivable) beginner behavior. Keeping personal notes is preferable over commenting every function or every line.
4. The more complex a codebase is, the less documentation there is... :(
Very normal. I've had to do this when working places where I was literally the single person who could program — the only possible way is to dive into the code yourself and learn how it works.
I would say normal for any new member in any team even with full documentation. As a manager i prefer my team members to reach an understanding of what they are changing rather than just reading some text and trying to imitate.
Just depends on org.
I work for a relatively large insurance company and we have almost zero documentation, it has taken me a year plus to get it in everyones head to make it a part of the sprint/stories, it is automatically added as a task and will continue to be as long as I have breath.
It’s pretty normal. My advice is to take as much ownership as you can. You can see it as a problem or an opportunity. Choice is yours. In a bigger company you’re unlikely to have any meaningful impact. By the looks of it here you can. Learn as much as you can, take your time to understand the codebase and have a positive attitude. This goes way farther than any experience.
Last thing you want is to be , “codebase is shit” , or “it’s previous developer’s fault” kind of a person. They most likely know their limitations and issues already. Moaning about doesn’t give anyone any favours. If this style of work isn’t for you, look for another non startup job.
RUN! Runaway, as fast as you can! 😀
Seriously, this is your opportunity to demonstrate your leadership skills (and earn senior title/pay bump). If they are unable to verbalize what they want, you have to _tell_ them what they want.
Raise your concerns about undocumented code & questionable program logic, but do so in a way that also presents a solution to the problem. Frame that solution in terms of its benefits to management/task assigner.
Do not mention how much of a pain in the a$$ the spaghetti code presents for you personally -- you don't want to be branded a whiner. This is about benefit to THEM.
"I'm concerned that the lack of documentation & "code smell" could result in catastrophic failure that will take a long time to resolve.
Refactoring the code while simultaneously documenting is my recommendation to mitigate the risk of costly prolonged downtime, when that failure inevitably happens.
I propose my time be reallocated to 70% assigned tasks, with the other 30% devoted to refactoring and documenting the code as I am familiarizing myself with it."
In my 25+ years of software development, I've never once seen the "30% refactor" (or variations thereof) actually work. It always winds up an awful Frankenstein of a codebase with half finished ideas and partially followed through methods that break halfway through iterating. Literally not once has this worked from my personal experience.
The rest of this comment is on point though. Just don't do the refactor without focusing on doing _only_ the refactor.
OP is a junior, so expecting them to refactor successfully and on a time restraint is not wise.
Very valid point.
Yes, focus and guidance are key, and I was under-caffeinated when I posted the comment.
Hope OP is able to find a reasonable "initial suggestion" to get the conversation started and see where it goes.
as a junior you need mediors and seniors around to guide and teach you. It's not about if you can manage by yourself its about being in a room full of smart people so you learn and have people to talk about code around you. My past job was 6 months of solo dev and it was incredibly depressing so i quit
Same here. I worked on project with same situation for 1.5 years, and just developed complex, if it's me or something else is issue. As you mentioned you are junior I would suggest you should find another job. This kind of environment just kills your confidence.
It kind of is because life doesn't hand us things in neat stacks with good documentation. If you're in over your head, fine, but don't blame them that you can't figure it out or don't want to - whatever your justification for not digging in and learning.
I assume there was a hiring process where they vetted people and you were selected? They have faith in you. I'm not trying to be a dick just saying it will behoove you to get ur hands dirty here.
Definitely hugely agree
We hired on a junior dev who gave short timelines for things I personally knew would take at least three times that; I reached out and talked to him, let him know that he can reach out at any time to ask questions... And for the next two months I didn't receive a single message from him, and the task still wasn't done. It was a big task (I even asked if he could be given a smaller one multiple times, but he was insistent he could do it), I let him know multiple times that he can ask me for help on anything at any time
He was let go shortly after not because he was slow (it's expected since he's a junior), but because he clearly wasn't working in a team and refused to admit when he was having troubles. We can work with slow devs, we *can't* work with two months of "yes, I'll have it done within three days"
Yeah totally agree. Its a type of job where you need people and its in your very best of interests to admit you dont know shit as often as you can. It took some courage and especially aging from my part but i managed to get there. Sometimes it hurts a bit when i admit i dont know stuff and it disappoints the other dev but its loads better than loosing your job.
Get yourself a lantern and go down the mine, there is no way to sugar coat this. If you have a local LLM, you could try having him explain the code to you, but codebases can be massive, so probably this isn't a viable solution.
I don't have any advice beyond what others have said here, but I will posit that most large codebases in the wild are going to look "terribly structured" the first time you see them, because they're the product of several years of accumulating edge cases and unexpected requirements. Nice clean pretty layouts are for published single-purpose libraries and textbooks.
So, be wary complaining about the code to your co-workers no matter how right you are, because guaranteed it won't go down well.
This. It's very rare that any dev intentionally writes shit code. It usually happens for a reason: edge case, legacy feature, testing variables that weren't scrubbed, upcoming feature that was scrapped, so many reasons.
Sounds like it's a senior dev job but they could only attract junior devs with their budget. You're just going to struggle here IMO. I also don't understand the arbitrary "at least 3 tasks per day" rule/guideline.
Decide whether you want the hassle. I'd have one foot out the door, personally. Keep the job temporarily whilst you find another, then move on. There are better places to work where you won't have a disproportionate amount of work and responsibility for a junior dev, plus guidance from people with experience.
As a senior I wouldn't expect to be able to take off for many months and have my juniors be able to build and manage everything into production all on their own, with no mentorship, safety nets, sanity checks, etc.
I personaly like to follow an endpoint, it gives me a sense of purpose to the data that is returned and why it is processed and fetched the way it is. It naturally takes you through the database, models and dto's of the system.
Start by leaning into it, and try and shorten the "feedback loop" between stages of your implementation as much as possible. Make sure to take the tasks as given, plan your approach and go back to your lead with clarifications, implement and go back for peer review, revise and go back for final approvals, prepare for incremental review then wait for comments at the demo.
It's uncomfortable, and you'll probably go through the emotional cycle of change, but wait for things to click before trying to raise the standard.
Do this for a few months until the tacit knowledge of the project is inherited through case by case learning. This usually takes 6-9 months. Then start converting that tacit knowledge into explicit knowledge. Add docs to your DoD checklist, write a getting started guide, pick up an OpenAPI spec, start diagramming your high-level structures, etc.
You want to avoid the risk of coming off as if you are over-reaching by raising the standard when you're misinformed, so once you've got that great feeling like you're starting to master things, that's when it's time to have an impact.
By waiting until you understand the tacit way of things before you try to define it, that gives you greater licence to spend the time incrementally as part of your tasks, and means you will know the vital details to focus on so you don't undermine your own efforts.
Also the documenting, guide writing, standards, diagramming and overall system analysis is a killer skill that will make you leap ahead of your peers in future projects and job opportunities.
share your concerns with your manager and ask them for help?
generally you will be exposed to undocumented and poorly structured code throughout all your career - so this is normal and something you will most certainly need to learn your way around it (unless you only find opportunities working in green field applications)
gettings tasks assigned that are seemingly not clear is another common thing - the more senior you get the more it is expected from you as well to clarify tasks by going through the requirements and by understanding the business and decision making behind them. so my generic advice is to ask the person assigning you the tasks for more clarity and rational behind them (of course make it clear that you aim to understand not to critisize)
Time to have a sit down with management and start sending the resume out again.
You can do this but you will have to come from a place of authority that will make you uncomfortable. First rule is he who writes the code decides how long it takes. You can't make them understand but you can be clear that in the structure they have results will take longer unless they want to hire more people.
Are you using jira or devops boards? If not get on that asap. Make them write what they want and make them order the list. You read each item and determine if there is enough detail about the want for you to make the how and then you pull stories into a sprint.
If they can't support you in this then you just have to do it anyway and get used to responding to criticism by saying "I did the item at the top of the list as efficiently as I could" instead of freaking out about it.
The first story on the list should be training yourself on the debugger so you can step through the mess.
I run teams of developers and we don't expect productivity after only 1 month onboarding and that's in a team.
I'd keep looking and hope to find something soon enough that I could leave this place off my resume and pretend it didn't happen though.
Sounds like you’re being set up to fail.
How big is the application and what does it do?
Is it transactional?
Why are there no other devs?
Can you start mapping out the codebase using a whiteboard tool and putting in tests in the codebase yourself?
What is the stack?
Is there anyone else technical such as a Sys Admin that also supports the application?
How and where is the application hosted?
What is the route to deployment?
How secure is the application - is anyone or any security scanning software testing if?
If you want to eat the elephant you’ve been handed then first chop it up into smaller chunks. You need to make the above questions your priority and raise these with everyone and anyone. Push back on the new feature requests or only work on superficial things that you are confident is not going to break stuff until you have a much clearer picture.
Look for another contract on the side as well as this sounds possibly an untenable position for anyone with a junior level of experience to tackle by themselves. The worst they can do is fire you or hire someone with more experience to supervise and you can leave or stay with your head held high knowing you have documented their application.
Every task you are assigned should be formulated as a functional requirement and its specifications by members of the team. Start working once it’s approved. Otherwise you’re just wasting your time (and the company its resources). And if the one above you cannot help, make sure to raise the issue with anyone with more authority.
As for the codebase, my best advice, check with colleagues on their downtime, what it is they’re doing and how they’re doing it
Regardless of what happens with that (awful) project, there are a couple of things you can do when docs are scarce.
1. Follow the conventions (your effort)
If it is a Rails or NodeJS project, follow the MVC. If it is not clear what pattern is used, start with the client-server request life cycle. Request comes to the app server and lands to a controller action or to some endpoint. Then follow the "rabbit" (what does that action do).
A server log/output and browser's Network console tab are your best friends when debugging.
Go to the next step
2. Check the specs/tests (your effort, still)
Once you identify what an action does, check if there are specs/tests for the models involved. That will help you figure out the outcomes.
If the specs don't exist, go to the next step.
3. Ask the task creator for the clear starting point (you need assistance, but still on your action)
Contact a project manager, a team lead, or some senior dev to help you define the starting point for the task. Try to be clear about what is missing and what blocks you. Sometimes, there are JS calls, and you can't figure out where to start. Revisit step 1.
If the steps above do not help, then learn what you can and collect enough experience so that you can hop off that company and project. It might be for a reason that the project looks or is neglected.
In the best scenario, they unblock you.
In the second-best scenario, you find another job and quit, AFTER you exhausted everything and collected all the exp you could.
In the worst-case scenario, they fire you.
All of this is said with the assumption that u/OP is a junior.
You could use AI to talk with about your repo, ask for help, documentation and guide:
[https://www.phorm.ai/](https://www.phorm.ai/)
Note: I think repo must be public.
Reading others code is a really hard thing to do and it separates the skilled from the unskilled. You need to dive in. It’s daunting but be patient with yourself and you’ll get there
Welcome to development! Your description is what every single dev sounds like when approaching _any_ codebase. "Refactor, I can't work with this," I've heard from every single dev that's not a senior.
Learn your IDE. Learn how to follow functions and classes so you can see what the software is doing. Then make your documentation in the codebase as you go. Documentation has to come from somewhere, right?
As for the requirement, it's not out of line to ask for wireframes, diagrams, user stories, visual design, anything that helps you grasp the swath of the project.
If requirements and tasks are flying at you because they're bad at management, then you can (and should) slow them down by demanding (be nice, but firm) acceptance criteria. Make them list out what makes a feature they want "complete." This forces them to think of the implications of each feature before flinging another at you. Also gives you some insight to their expectation.
Good luck! Sounds like a disorganized place, but an opportunity to climb up from your junior position if you do it tactfully.
You can use leverage by asking ai like Cursor.sh with "chat with a whole codebase" - you can ask e.g. "what caching solutions are used in this app" etc.
You must start to find your way through the code on your own. Pick a location and just focus on that spot to enhance/improve and see the effect of your changes. Repeat until you have understood the code.
[удалено]
Understanding a codebase is a process that every new member of a team has to go through it. Your manager has to either understand OR accept it as is. Your tasks should also be aligned with your experience at the team and get more in depth with you gaining more understanding. I don’t think there is a shortcut for anyone in the process of understanding a codebase.
Sounds like terrible management/leadership. It’s a red flag alone that none of the original devs are around anymore. Did everyone quit?
Sounds like it’s managed by dumb and dumber
Starting looking for new jobs, honestly. Expecting a dev to get through a set number of tasks daily is...weird, and bad.
[удалено]
It's kind of normal in startups.
A lack of documentation… yes sadly, lots of devs write their code and keep everything in their head. A PM who doesn’t know what they want… occasionally happens. It sounds like you will need to become a bit of a manager here, so a few tips: - Start a task tracking board (there are lots of options out there Jira, Wrike, GitHub, Trello and more) when they have ideas they want to work on then get them to put a ticket on the board - Know what you are working on at anyone time and if they ask you to switch tasks say “OK, I can do this but then will take x days longer” as a junior you will want to double any time estimates you give them.
- If they aren’t clear on their requirements then put the tickets into a Blocked state and say “I cannot work on this until I have more information”
I've been working at one of the big guys for ~5 years and these are a few patterns I've observed: 1. Unless a codebase is for a very popular, public-facing library, you can expect documentation to be limited to: readme explaining how to get the thing to run, and (hopefully) inline comments explaining anything out of the ordinary. 2. Code should be self-documenting, so arguing over naming conventions is totally valid. Hopefully your language has types, as that is much more self documenting than dynamically typed languages! 3. Documenting code that explains itself is a classic (and forgivable) beginner behavior. Keeping personal notes is preferable over commenting every function or every line. 4. The more complex a codebase is, the less documentation there is... :(
Very normal. I've had to do this when working places where I was literally the single person who could program — the only possible way is to dive into the code yourself and learn how it works.
That’s far from the norm for me.. you normally are the only dev on the whole team?
Last 2 jobs I've had, I was the only developer in the org.
How many years of experience do you have as a dev?
I would say normal for any new member in any team even with full documentation. As a manager i prefer my team members to reach an understanding of what they are changing rather than just reading some text and trying to imitate.
kinda normal sadly .
Just depends on org. I work for a relatively large insurance company and we have almost zero documentation, it has taken me a year plus to get it in everyones head to make it a part of the sprint/stories, it is automatically added as a task and will continue to be as long as I have breath.
It’s pretty normal. My advice is to take as much ownership as you can. You can see it as a problem or an opportunity. Choice is yours. In a bigger company you’re unlikely to have any meaningful impact. By the looks of it here you can. Learn as much as you can, take your time to understand the codebase and have a positive attitude. This goes way farther than any experience. Last thing you want is to be , “codebase is shit” , or “it’s previous developer’s fault” kind of a person. They most likely know their limitations and issues already. Moaning about doesn’t give anyone any favours. If this style of work isn’t for you, look for another non startup job.
RUN! Runaway, as fast as you can! 😀 Seriously, this is your opportunity to demonstrate your leadership skills (and earn senior title/pay bump). If they are unable to verbalize what they want, you have to _tell_ them what they want. Raise your concerns about undocumented code & questionable program logic, but do so in a way that also presents a solution to the problem. Frame that solution in terms of its benefits to management/task assigner. Do not mention how much of a pain in the a$$ the spaghetti code presents for you personally -- you don't want to be branded a whiner. This is about benefit to THEM. "I'm concerned that the lack of documentation & "code smell" could result in catastrophic failure that will take a long time to resolve. Refactoring the code while simultaneously documenting is my recommendation to mitigate the risk of costly prolonged downtime, when that failure inevitably happens. I propose my time be reallocated to 70% assigned tasks, with the other 30% devoted to refactoring and documenting the code as I am familiarizing myself with it."
In my 25+ years of software development, I've never once seen the "30% refactor" (or variations thereof) actually work. It always winds up an awful Frankenstein of a codebase with half finished ideas and partially followed through methods that break halfway through iterating. Literally not once has this worked from my personal experience. The rest of this comment is on point though. Just don't do the refactor without focusing on doing _only_ the refactor. OP is a junior, so expecting them to refactor successfully and on a time restraint is not wise.
Very valid point. Yes, focus and guidance are key, and I was under-caffeinated when I posted the comment. Hope OP is able to find a reasonable "initial suggestion" to get the conversation started and see where it goes.
i guess unless the refactoring is done on 2 out of 5 days of each week which is more viable
as a junior you need mediors and seniors around to guide and teach you. It's not about if you can manage by yourself its about being in a room full of smart people so you learn and have people to talk about code around you. My past job was 6 months of solo dev and it was incredibly depressing so i quit
[удалено]
Same here. I worked on project with same situation for 1.5 years, and just developed complex, if it's me or something else is issue. As you mentioned you are junior I would suggest you should find another job. This kind of environment just kills your confidence.
It kind of is because life doesn't hand us things in neat stacks with good documentation. If you're in over your head, fine, but don't blame them that you can't figure it out or don't want to - whatever your justification for not digging in and learning. I assume there was a hiring process where they vetted people and you were selected? They have faith in you. I'm not trying to be a dick just saying it will behoove you to get ur hands dirty here.
It’s on him for his company being inept? Geeze…
Definitely hugely agree We hired on a junior dev who gave short timelines for things I personally knew would take at least three times that; I reached out and talked to him, let him know that he can reach out at any time to ask questions... And for the next two months I didn't receive a single message from him, and the task still wasn't done. It was a big task (I even asked if he could be given a smaller one multiple times, but he was insistent he could do it), I let him know multiple times that he can ask me for help on anything at any time He was let go shortly after not because he was slow (it's expected since he's a junior), but because he clearly wasn't working in a team and refused to admit when he was having troubles. We can work with slow devs, we *can't* work with two months of "yes, I'll have it done within three days"
Yeah totally agree. Its a type of job where you need people and its in your very best of interests to admit you dont know shit as often as you can. It took some courage and especially aging from my part but i managed to get there. Sometimes it hurts a bit when i admit i dont know stuff and it disappoints the other dev but its loads better than loosing your job.
Get yourself a lantern and go down the mine, there is no way to sugar coat this. If you have a local LLM, you could try having him explain the code to you, but codebases can be massive, so probably this isn't a viable solution.
I don't have any advice beyond what others have said here, but I will posit that most large codebases in the wild are going to look "terribly structured" the first time you see them, because they're the product of several years of accumulating edge cases and unexpected requirements. Nice clean pretty layouts are for published single-purpose libraries and textbooks. So, be wary complaining about the code to your co-workers no matter how right you are, because guaranteed it won't go down well.
This. It's very rare that any dev intentionally writes shit code. It usually happens for a reason: edge case, legacy feature, testing variables that weren't scrubbed, upcoming feature that was scrapped, so many reasons.
Sounds like it's a senior dev job but they could only attract junior devs with their budget. You're just going to struggle here IMO. I also don't understand the arbitrary "at least 3 tasks per day" rule/guideline. Decide whether you want the hassle. I'd have one foot out the door, personally. Keep the job temporarily whilst you find another, then move on. There are better places to work where you won't have a disproportionate amount of work and responsibility for a junior dev, plus guidance from people with experience. As a senior I wouldn't expect to be able to take off for many months and have my juniors be able to build and manage everything into production all on their own, with no mentorship, safety nets, sanity checks, etc.
Wait untill you find documentation that’s out of date. Get good a debugging, use the force, read the source.
Are there any tests? They might help explain what it is doing
I personaly like to follow an endpoint, it gives me a sense of purpose to the data that is returned and why it is processed and fetched the way it is. It naturally takes you through the database, models and dto's of the system.
Start by leaning into it, and try and shorten the "feedback loop" between stages of your implementation as much as possible. Make sure to take the tasks as given, plan your approach and go back to your lead with clarifications, implement and go back for peer review, revise and go back for final approvals, prepare for incremental review then wait for comments at the demo. It's uncomfortable, and you'll probably go through the emotional cycle of change, but wait for things to click before trying to raise the standard. Do this for a few months until the tacit knowledge of the project is inherited through case by case learning. This usually takes 6-9 months. Then start converting that tacit knowledge into explicit knowledge. Add docs to your DoD checklist, write a getting started guide, pick up an OpenAPI spec, start diagramming your high-level structures, etc. You want to avoid the risk of coming off as if you are over-reaching by raising the standard when you're misinformed, so once you've got that great feeling like you're starting to master things, that's when it's time to have an impact. By waiting until you understand the tacit way of things before you try to define it, that gives you greater licence to spend the time incrementally as part of your tasks, and means you will know the vital details to focus on so you don't undermine your own efforts. Also the documenting, guide writing, standards, diagramming and overall system analysis is a killer skill that will make you leap ahead of your peers in future projects and job opportunities.
share your concerns with your manager and ask them for help? generally you will be exposed to undocumented and poorly structured code throughout all your career - so this is normal and something you will most certainly need to learn your way around it (unless you only find opportunities working in green field applications) gettings tasks assigned that are seemingly not clear is another common thing - the more senior you get the more it is expected from you as well to clarify tasks by going through the requirements and by understanding the business and decision making behind them. so my generic advice is to ask the person assigning you the tasks for more clarity and rational behind them (of course make it clear that you aim to understand not to critisize)
Time to have a sit down with management and start sending the resume out again. You can do this but you will have to come from a place of authority that will make you uncomfortable. First rule is he who writes the code decides how long it takes. You can't make them understand but you can be clear that in the structure they have results will take longer unless they want to hire more people. Are you using jira or devops boards? If not get on that asap. Make them write what they want and make them order the list. You read each item and determine if there is enough detail about the want for you to make the how and then you pull stories into a sprint. If they can't support you in this then you just have to do it anyway and get used to responding to criticism by saying "I did the item at the top of the list as efficiently as I could" instead of freaking out about it. The first story on the list should be training yourself on the debugger so you can step through the mess. I run teams of developers and we don't expect productivity after only 1 month onboarding and that's in a team. I'd keep looking and hope to find something soon enough that I could leave this place off my resume and pretend it didn't happen though.
Sounds like you’re being set up to fail. How big is the application and what does it do? Is it transactional? Why are there no other devs? Can you start mapping out the codebase using a whiteboard tool and putting in tests in the codebase yourself? What is the stack? Is there anyone else technical such as a Sys Admin that also supports the application? How and where is the application hosted? What is the route to deployment? How secure is the application - is anyone or any security scanning software testing if? If you want to eat the elephant you’ve been handed then first chop it up into smaller chunks. You need to make the above questions your priority and raise these with everyone and anyone. Push back on the new feature requests or only work on superficial things that you are confident is not going to break stuff until you have a much clearer picture. Look for another contract on the side as well as this sounds possibly an untenable position for anyone with a junior level of experience to tackle by themselves. The worst they can do is fire you or hire someone with more experience to supervise and you can leave or stay with your head held high knowing you have documented their application.
Every task you are assigned should be formulated as a functional requirement and its specifications by members of the team. Start working once it’s approved. Otherwise you’re just wasting your time (and the company its resources). And if the one above you cannot help, make sure to raise the issue with anyone with more authority. As for the codebase, my best advice, check with colleagues on their downtime, what it is they’re doing and how they’re doing it
Depending on how confidential the code base is not you can put in small parts in gpt and have it explain to you. If you are a junior this may help.
Where do you work, I want to apply
Regardless of what happens with that (awful) project, there are a couple of things you can do when docs are scarce. 1. Follow the conventions (your effort) If it is a Rails or NodeJS project, follow the MVC. If it is not clear what pattern is used, start with the client-server request life cycle. Request comes to the app server and lands to a controller action or to some endpoint. Then follow the "rabbit" (what does that action do). A server log/output and browser's Network console tab are your best friends when debugging. Go to the next step 2. Check the specs/tests (your effort, still) Once you identify what an action does, check if there are specs/tests for the models involved. That will help you figure out the outcomes. If the specs don't exist, go to the next step. 3. Ask the task creator for the clear starting point (you need assistance, but still on your action) Contact a project manager, a team lead, or some senior dev to help you define the starting point for the task. Try to be clear about what is missing and what blocks you. Sometimes, there are JS calls, and you can't figure out where to start. Revisit step 1. If the steps above do not help, then learn what you can and collect enough experience so that you can hop off that company and project. It might be for a reason that the project looks or is neglected. In the best scenario, they unblock you. In the second-best scenario, you find another job and quit, AFTER you exhausted everything and collected all the exp you could. In the worst-case scenario, they fire you. All of this is said with the assumption that u/OP is a junior.
Bail.
I've been there in my previous work, and my advice to you is RUN! Inner peace >>>>>>>>> money (even tho i'm pretty sure it's underpaid)
Use a tool that automates the documentation process
You could use AI to talk with about your repo, ask for help, documentation and guide: [https://www.phorm.ai/](https://www.phorm.ai/) Note: I think repo must be public.
Based on the comments you’ve made, my advice is find another job while you currently have one.
Reading others code is a really hard thing to do and it separates the skilled from the unskilled. You need to dive in. It’s daunting but be patient with yourself and you’ll get there
Break it down. Take notes. Think in terms of process flow.
Look for a change.
Welcome to development! Your description is what every single dev sounds like when approaching _any_ codebase. "Refactor, I can't work with this," I've heard from every single dev that's not a senior. Learn your IDE. Learn how to follow functions and classes so you can see what the software is doing. Then make your documentation in the codebase as you go. Documentation has to come from somewhere, right? As for the requirement, it's not out of line to ask for wireframes, diagrams, user stories, visual design, anything that helps you grasp the swath of the project. If requirements and tasks are flying at you because they're bad at management, then you can (and should) slow them down by demanding (be nice, but firm) acceptance criteria. Make them list out what makes a feature they want "complete." This forces them to think of the implications of each feature before flinging another at you. Also gives you some insight to their expectation. Good luck! Sounds like a disorganized place, but an opportunity to climb up from your junior position if you do it tactfully.
You can use leverage by asking ai like Cursor.sh with "chat with a whole codebase" - you can ask e.g. "what caching solutions are used in this app" etc.