Do not assume that the current codebase is perfect, or even remotely close to an example of acceptable style/structure.

This. It can be a bit discouraging to see all the bad practices and spaghetti code written by previous devs though.

@IAmNotARobot

Definitely! I don't expect juniors to be solution architects, or great at refactoring. I do expect juniors to write code by looking at existing features and using those as an example — but it's dangerous to assume that all of it is great example material.

So the number one advice I give them is to ASK where to look for sample code... Or at the very least use git to check whether the feature they're peeking at isn't 6 years old.

@bittersweet how do you find the date of a specific commitment in git?

@ZeldaFan69-2 git show

@asgs thanks. Didn't know that

@ZeldaFan69-2 I personally use git blame (well, the built-in Jetbrains IDE version of it) to annotate the lines with author & commit date.

For VSCode there's "annotator" (https://marketplace.visualstudio.com/...) which also uses git blame in the background.

But most often I also just ask in Slack "hey peeps, what do we think is a great way to structure & organize this set of middlewares? Throw it in directory A or B? Should use handle as a method name?" — even when I already have an opinion on it, I tend to ask.

In the other hand, if a junior (or anyone for that matter) can understand the code they use as a reference, chances are that it is pretty readable.

@electrineer True, but sometimes it's not just about readability -- it's also about structure, consistency & deprecation.

For example, it often happens that a part of a website is still server-templated HTML (Twig, Blade, Jinja, etc), while the preferred "new" way of doing things might be to build an API endpoint which is used by some React/Vue/Angular component.

No matter how nicely readable it is, you don't want a junior to keep adding to the legacy pages, instead of helping the transition in the right direction.