Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
example-user372325dJust do it
vintprox3136325dDebugging costs souls. Do what you were assigned and what you have estimated to do.
Crost3477325dSounds like bad system design to me. Shouldn't have to understand the whole thing to work on something specific.
I have experienced this before though. It might be normal for your part. And btw 2 days is nothing.
@craig939393 Oh no the system design is pretty good. I just have to configure a couple of things and im set. I guess ill just concentrate on the task for now and leave the debugging to some other day.
HiFiWiFiSciFi4064325dDon't debug the whole code base, just do your feature and get back out.
Even it means adding more spaghet.
People get payed to add new features. People unfortunately do not get payed to spend hours of their own time fixing other peoples shit.
Now, if you get brought in for "triage"... that's another story.
devjesus2329325d@etmac i cannot say this with much experience , but currently i am in the same situation as you and i feel comfortable due to presence of good colleagues and architecture in codebase.
I was given a whole week to get a hang of the codebase and even by the week end i was feeling like i don't know even 2 % of it. I would ask questions on slack , and someone would answer it.
When the week ended, they didn't bombarded me with some test or some core feature dev, but rather very specific tasks with exact instructions . Slowly the instructions started to get vague and i would be doing the task in my way. But thereafter the reviewers role would come. My tech lead would review my PR and tell me what the changes should be. Also, while discussing how to some stuff, i would ask questions like what is currently happening in so and so line and what i understand from it.
So yeah communication is the key. There codebase could have a bothering architecture but finishing a task is more important
Ignore what appear to be "bugs". This is going to waste a huge amount of time if you question everything, since it's your first time around. Your job is not to clean up but to work with the mess.
Look for pre existing examples of what you want to implement.
Most importantly, get very clear on the requirements, and be checking in with people, your teammates, they won't like to see hours pass with you not giving updates.