-4

My company is about to onboard some junior devs for the first time, and we want to limit their access to just the presentation layer. As it stands, everything is in one Git repo. The current plan is to fork the main repo, and modify it such that only presentation layer and the compiled assembles will be left. The new devs can then branch from there. The lead dev can just do the merge himself.

Is there a better and optimal way to approach this?

Improve this question
5
  • 1
    Why limit them? Don't you trust them? Commented Dec 25, 2020 at 12:51
  • To be frank, yes. But also, we had an experience before where a dev messed up our core libraries so bad we had to do a huge rollback. As we are a small team, we cannot go through each and every commit every dev does. Commented Dec 25, 2020 at 13:04
  • 5
    You should. Code reviews will save you time. Commented Dec 25, 2020 at 13:21
  • At least before a merge back to master. GitHub does this nicely. Commented Dec 25, 2020 at 13:26
  • 1
    The better way is probably to tell the new devs which parts of the code they are allowed to change, and which not (or only under strict supervision). Technical measures like restricted access rights are often counterproductive in cases like yours. Commented Dec 25, 2020 at 22:57

1 Answer 1

Reset to default
2

Some options:

  1. Merge request reviews can be a great way to enforce the team's standards for quality, security, etc. across the board, and to ensure that only code of sufficient quality ends up in the repository. Seniors should review juniors' code, but juniors should also review seniors' code. Both can learn from each other, because being senior doesn't mean you know a superset of everything a junior knows.
  2. CI pipelines enforce those parts of the coding standard which it can be easy to automate: running tests, linting code, packaging deliverables, and deploying. Running the CI pipeline successfully must of course be a requirement for merging anything to the main branch, and any changes to the CI pipeline itself must be scrutinized extra carefully.
  3. Code review checklists can be a good way to onboard someone to what is expected in the project. In my experience each team and usually each project ends up with a different idea about what is considered the minimum quality. These checklists should be amended whenever the team agrees on some improvement they want to see in all new code, and should ideally be reviewed by at least a senior and junior developer, to make sure everybody is on the same page.

I would recommend using all of the above. Some caveats:

  1. Make sure that no single person has to review everything. They will probably end up doing very superficial code reviews, resulting in a bad code base over time, a terrible bus factor and people not learning as much as they could from the reviews. Alternatively they will be stuck doing nothing but code reviews, and will probably leave because that would be career suicide.
  2. Trust is essential to programming projects. Trust people to do the best possible job given the available knowledge, tools and other resources. Breaking software is so easy that otherwise you might as well do the job yourself.
Improve this answer
1
  • I'll bring this up with the team. Thanks l0b0! Commented Dec 28, 2020 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.