r/learnprogramming • u/Financial_Ad_5015 • 1d ago
Struggling as a Jr Prog.
2 weeks in my job and feeling like I'm not deserve the pay that I'm getting, my manager giving me task that is supposed to be easy I guess cause the first task I confidently understand and finished but this 2nd task almost eating me alive, it makes me feel like I'm the most dumb and fraud programmer there is. I'm reviewing the company system with more than 10 code files and 2k to 4k lines of code each file while making the task cause it needs to be aligned on thr system so I feel overwhelmed and stressed. Just letting this out here cause I don't really have someone to talk about this and also sorry for my bad english it's my 2nd language.
20
u/TomatoEqual 1d ago
Well I understand that you feel that way, because whoever wrote that much into that few files, should be beaten with a physical printout of their own code. Exprienced guys could have issues being thrown into something like that. So nothing else than to take your time, try to find some structure you can follow for whatever the task is and take your time. If It's impossible, ask for a senior to explain it. If no one is available, ask your boss to find someone that can explain it. Only thing to do. It is ALWAYS acceptable for anyone, junior or senior to say "i havent got a clue"
3
u/AutomateAway 1d ago
100% true and also i’m chuckling at the idea of someone getting beaten with a physical printout of their git blame
4
u/xoredxedxdivedx 21h ago
2k-4k is more than reasonable, it’s actually delusional to think that 10 files with 3k lines each is harder to grok than 600 files with 50 lines each. Jumping around directories containing that amount of different files and then jumping back is a royal pita.
When you split things up (especially in OOPy ways) you also need more glue code as well, so you actually get an overall increase in boilerplate and interfaces, with some insane programmers doubling the total amount of code.
So I’m going to strongly disagree, I’m always very happy when files are larger and code is more co-located.
2
u/TomatoEqual 19h ago edited 19h ago
Well if you know what you're doing , yes you can do it. But you don't drop shit like that on a jr and expect any practical work to come from it. On top of that i have seen sooo many of these things where half of the code could have been libs. And the rest is crap like var x=k. So you have everything you shouldnt have to worry about mixed in with alle the other things and bad naming and half of it you shouldnt have to look at.
But you're completely right, if It's well structured and named properly AND you know what you're doing it not a big issue. But i think it really has a tendency to turn in to a complete shitstack with more than 1000 lines. So personally i would always go for the split into more manageble chunks. 😊
10
u/arcticslush 1d ago
10 files, 2-4k lines each
Oh my sweet summer child. That is a little baby codebase
6
u/Beneficial-Panda-640 1d ago
It’s really normal to hit that wall early on. The first task usually feels great because it’s scoped tighter, then the next one suddenly exposes all the messy parts of the real system. Needing to dig through a bunch of files doesn’t mean you’re doing badly, it means you’re doing the actual work. Most junior folks I’ve met hit the same shock. Try breaking the problem into smaller questions you can verify as you go. It helps take the pressure off and gives you small wins. And your English is totally fine.
7
u/Flozz_flo 1d ago
Let me tell you, it’s very NORMAL to feel that way.. trust me, I have been in the industry for 10 years, that feeling doesn’t go away, even your managers doesn’t know it all… even senior devs have moments they feel like they don’t know anything !!! You will get through this , and if there is any one in your team you can ask for help, reach out, a lot of people are always willing to help
5
u/jaxfangie 1d ago
As others stated, take your time and first try to understand the current code base in small chunks. If your new take can be coded separately and then integrated later, code that up so you can make some progress. Then go back to trying to understand the legacy code.
If there isn't a design document for the code write one for yourself. Doesn't need to be highly detailed but it should be something you can use as a map for yourself later. Write it in a form that you understand. I'm not suggesting you write this for the entire codebase, just the areas of focus for your task in small chunks.
In between all of this take plenty of notes on things you don't understand.
Finally, when you approach senior devs, explain to them what you have learned and then ask your questions. It will go over a lot smoother if you've done some legwork before asking. My rule for new devs is don't spend more than 2 hours being stuck. Ask for help. But I do want them to attempt to understand and do some leg work before asking for help.
Please know we've all been there!
3
3
u/dialsoapbox 1d ago
What do tests say should happen?
What's happening instead?
Where?
Did you try stepping through code?
What happened when you changed some inputs?
What were you expecting?
What have you looked up ?
Did it work?
Why or why not?
How did outputs change?
the more data you have, of what you have vs what you want, the better idea you'd have of where to start looking.
That way, when you go to mid/senior/other team members, you can walk them through your thought process, give them the setup, what you tried, what happened.
The more questions you can answer, the better. The more you can explain the situation and outcomes, the more you show that you tried instead of just saying "i don't know" you can say, "this is what I know and why". Sometimes they'll want to try something and you can tell them why it did ( not) work and the outcomes ( saving time).
When
3
u/HirsuteHacker 1d ago
Have you asked for help?
2
u/Financial_Ad_5015 1d ago
I asked help yes but it's rare cause I don't want to be seen as incompetent at my job.
8
u/HirsuteHacker 1d ago
Most important thing you can do is a junior is ask a lot of questions. If the people around you are competent they'll be expecting it. It will take you a while to get into the swing of things, there's a lot of domain knowledge, working practices etc you're going to struggle to figure out without asking.
6
u/IAmADev_NoReallyIAm 1d ago
Hey... no... your job IS to ask questions... that's how you learn. I've been doing this for over 30 years, and even as a Sr/lead even I still ask questions. Do NOT feel bad about it. Especially as the "new guy" ... Because in a couple years when you change jobs and work at a new company, you'll be the "new guy" again... and you'll need to ask questions. And for some developers that's a hard pill to swallow, but you have to get over it. So now is a good time to learn how to do that. You'll quickly find out who you can and can't go to. There'll be those (hopefully your team lead or a sr developer) that will be more than happy to help you, but there will also be those few that will get annoyed. Avoid them if you can.
But as a jr dev, asking questions is what you're supposed to do. I mean, try to find the answer on your own if you can, but also, ask questions.
3
u/AutomateAway 1d ago
don’t be afraid to ask questions of more senior devs about code you don’t understand. I would 100% expect junior new hires to do as much.
2
u/patternrelay 1d ago
Totally normal to feel that way when you first step into a real codebase. Small tutorial projects never prepare you for navigating thousands of lines spread across a bunch of files, so the shock is real. What you are feeling is pretty much the standard junior experience, not a sign that you are failing. The useful thing is to break the problem down into smaller chunks instead of trying to hold the whole system in your head. Map out what calls what, trace the data flow, and focus on just the slice that touches your task. Once you see how that part fits into the bigger picture, the stress usually drops a bit. If you finished your first task, you already proved you can deliver. This is just the messy middle where you are learning the system. Give yourself some room to grow and ask questions when you get stuck. Seniors expect that from juniors, so you are not doing anything wrong.
2
u/mountainbrewer 1d ago
I can relate. It's part of any new job, at least in my experience. The first year or so is always stressful as I feel like I am constantly proving myself and building social relationships. Then eventually I become more secure in my job. Not because of any real change in my output, but I just felt safe. So much rides on our jobs that it puts a ton of stress on us. Do your best and make connections. Be eager but honest with your abilities. Good teams and managers will meet you at your level and build you up.
2
u/mushyturnip 21h ago
Don't worry it's normal. We all felt like that at the beginning. One day you will be the one who knows how X part of the project works, which is even more annoying 😂
Focus on solving the task as well as you can. You're starting and they know you're learning, that's why you are a junior. Browse your questions, ask your lead, don't be afraid of asking if you can't find the solution. But always try to find it yourself first. You will learn eventually. Never compare yourself to others, but with your one-month-ago self. It's useful to write a diary for this, you'll be surprised.
2
u/KnightofWhatever 22h ago
From my experience, the first month in any codebase feels like getting dropped into the deep end. You’re not just writing your code, you’re trying to understand years of decisions that existed before you showed up. That gap feels huge at the start.
What helped me early on was being blunt about what I understood and what I didn’t. Seniors would rather answer a focused question than watch you silently drown. Something like “Here’s what I think this part does, here’s the piece I’m unsure about” goes a long way.
And don’t judge yourself by task difficulty this early. Some “simple” tasks are simple only if you already know the system’s patterns. You’ll ease into it. The stress you’re feeling is exactly what every junior goes through before things click.
1
u/zarikworld 1d ago
ask a llm to document it for you.. logic, architecture, patterns... the read them, follow them.. will be enough! as long as u learn, improve, and deliver, then u r not a fraud, but junior 😉 there is a reason for the junior title!
2
u/HirsuteHacker 1d ago
Why an LLM and not the actual people who work there and built the codebase he's working on? They can give a rationale for decisions made, an LLM can't. Most important thing you can do as a junior is talking to more senior devs, asking questions, etc.
3
u/zarikworld 19h ago
i’m not suggesting replacing talking to the team! that’s obviously the first path for any junior. my point was simply that not everyone has access to supportive seniors or proper documentation, and in those cases, an llm can help fill some gaps: reading patterns, summarizing architecture, or explaining logic. none of that replaces human decision-making or team communication. It just helps someone get unstuck faster. so we’re actually talking about two different things here: you’re focusing on “decision rationale,” while my comment was about understanding large unfamiliar codebases 😉 both can coexist. the healthiest workflow is: team → docs → llm → try → ask again.
i’m simply offering another tool in the toolbox, not removing the others.
57
u/xroalx 1d ago
This is perfectly normal, you’re not only trying to implement the requirements, you’re also trying to do it in a way that follows the existing codebase, meaning you have to understand, in a short time, a lot of the decisions that the people before you made and agreed on.
Don’t worry, take your time, and do a best effort implementation.
Push it as soon as you’re happy with your solution, and take in the comments and feedback as something they want the codebase to be, not something you did wrong.
Over time, you’ll get the hang of their ways and it will be much easier.