DEV Community

πŸŒ™ Navigating the codebase | The ultimate junior web developer survival guide

Pauline on November 15, 2019

The junior developer survival guide is a series of multiple posts where I document and share some of my most valuable experiences, advice, learnin...
Collapse
 
jackharner profile image
Jack Harner πŸš€

focus on getting your code to work first

Perfection prevents progress. Can't improve your code if you don't get it working in the first place. Programming itself is an iterative process and it's fine to "fix it in post". Definitely don't want to get buried in technical debt though.

Collapse
 
eddyvinck profile image
Eddy Vinck

If I had to write perfectly clean code while getting it to work, I would never get anything done.

Also, if the requirements change while you're working on a feature, all the "perfect" code you wrote might not be useful anymore.

Collapse
 
withpyaar profile image
with Pyaar

Wow that’s something I’m working on I want everything to be perfect and that’s not realistic all the time.

Collapse
 
rockykev profile image
Rocky Kev • Edited

Even teams forget this at times. My team was trying to duplicate a chunk of functions that worked on another project, using the overly optimized code we wrote for it.

After a few days of failed attempts, someone said. "Screw this. Let's just hardcode it." Just to get something to work.

Once we got something to just "work", then we slowly moved to making it as tight as the code we were trying to duplicate.

It's a excellent reminder... No matter how many years of experience.

Collapse
 
attkinsonjakob profile image
Jakob Attkinson • Edited
I sort of got the hang of both deleting code, refactoring code and also adding a lot of code.

At work, we all agreed that before we change or remove code from another dev that is still with the company we should ask for a confirmation.

This works really well both because we are a small team and there is a lot of undocumented code and decision made without leaving a trail. Some snippets look like "magic" and therefore changing something might have an unintended effect. This unwritten rule assumes somehow that solid logic had some reasoning behind it, but lack of documentation makes it hard to follow or understand.

Worth to mention that I am talking only about changes that touch on logic and algorithms, not about small fixes and refactoring.

Collapse
 
downey profile image
Tim Downey

One other technique, if your colleagues are up for it, is to pair program! Especially Driver/Navigator style. A skilled and patient Navigator can make a new codebase less intimidating and provide for a really fast feedback loop.

Collapse
 
sarajoha23 profile image
Sara Carvajal

This series is awesome 😊 thanks for the great tips! I'll definitely keep them on my reading list so I can come back to the articles later.