2 added 93 characters in body
source | link

Yes. But only if you're talking about distributed source control. With centralized -- it depends.

If there are only few programmers, it takes little time. Certainly less than the fixes that will be needed to remove bugs and technical debt later.

If there are very many programmers, you can delegate the task of actual code-review to lieutenants and have the lead developer pull their changes (nearly) unquestionably. It works for Linux kernel, I don't think that there are any larger software projects...

Again, if the project is small, the lead will quickly see who gives good code and who produces bad code. He will quite quickly see that J.Random writes good code that needs only checking for architectural decisions while the intern writes bad code that needs to be reviewed line by line before merging. The feedback this way generated will reduce maintenance burden down the line and give first hand experience on whatever the intern actually learns and should be kept in company. Pulling and merging branch from other git repo takes literally a (couple) dozen seconds, usually reading the titles of commit messages will take more time, so after I know who can be trusted to write good code merging other people's code is a non-issue.

Yes.

If there are only few programmers, it takes little time. Certainly less than the fixes that will be needed to remove bugs and technical debt later.

If there are very many programmers, you can delegate the task of actual code-review to lieutenants and have the lead developer pull their changes (nearly) unquestionably. It works for Linux kernel, I don't think that there are any larger software projects...

Again, if the project is small, the lead will quickly see who gives good code and who produces bad code. He will quite quickly see that J.Random writes good code that needs only checking for architectural decisions while the intern writes bad code that needs to be reviewed line by line before merging. The feedback this way generated will reduce maintenance burden down the line and give first hand experience on whatever the intern actually learns and should be kept in company. Pulling and merging branch from other git repo takes literally a (couple) dozen seconds, usually reading the titles of commit messages will take more time, so after I know who can be trusted to write good code merging other people's code is a non-issue.

Yes. But only if you're talking about distributed source control. With centralized -- it depends.

If there are only few programmers, it takes little time. Certainly less than the fixes that will be needed to remove bugs and technical debt later.

If there are very many programmers, you can delegate the task of actual code-review to lieutenants and have the lead developer pull their changes (nearly) unquestionably. It works for Linux kernel, I don't think that there are any larger software projects...

Again, if the project is small, the lead will quickly see who gives good code and who produces bad code. He will quite quickly see that J.Random writes good code that needs only checking for architectural decisions while the intern writes bad code that needs to be reviewed line by line before merging. The feedback this way generated will reduce maintenance burden down the line and give first hand experience on whatever the intern actually learns and should be kept in company. Pulling and merging branch from other git repo takes literally a (couple) dozen seconds, usually reading the titles of commit messages will take more time, so after I know who can be trusted to write good code merging other people's code is a non-issue.

1
source | link

Yes.

If there are only few programmers, it takes little time. Certainly less than the fixes that will be needed to remove bugs and technical debt later.

If there are very many programmers, you can delegate the task of actual code-review to lieutenants and have the lead developer pull their changes (nearly) unquestionably. It works for Linux kernel, I don't think that there are any larger software projects...

Again, if the project is small, the lead will quickly see who gives good code and who produces bad code. He will quite quickly see that J.Random writes good code that needs only checking for architectural decisions while the intern writes bad code that needs to be reviewed line by line before merging. The feedback this way generated will reduce maintenance burden down the line and give first hand experience on whatever the intern actually learns and should be kept in company. Pulling and merging branch from other git repo takes literally a (couple) dozen seconds, usually reading the titles of commit messages will take more time, so after I know who can be trusted to write good code merging other people's code is a non-issue.