How to train new programmer without giving full source code access?

Question

Hi

I am just started to employ some new programmers for a trial period. They are students so nobody know if they're good or not. I would like to give them some typical tasks at the beginning to see how skilled they are.

The problem I have is that I want them to write some bits for my asp.net mvc web application, but I don't want them to get full source code access.

I would like them to upload new code into repository to be automatically picked up by continous integration system and tested.

At the moment I have no idea how to give them partial access to the source code. Typically, I want them to develop controllers and views, not code of models or services (at last, not modifying the existing ones).

Can you suggest an approach to solve this? How is it done in your organization?

Thanks for sharing.

EDIT: We use SVN for source versioning. I know the most productive would be giving full source access, but is it wise to show everything to people you don't know more than a few days?

Of course, they must sign the secrecy commitment, but this is a wish only.

Answer 1

I've never been restricted in terms of the source code I can see when I work for new clients. Unless your encapsulations are good, and well-documented, at some point people are going to have to determine what's under the covers.

Tell them what they can/cannot modify. You'll have logs of code changes, so you can identify who's made changes where (do you get mails relating to checkins ? These will give you an immediate heads up). But I think restricting what they can see is going to be counter productive. And I think there's a trust issue here as well. I would be a bit peeved if I was hired and then not trusted to not touch certain stuff!

Answer 2

Give them their own branch. Review their work before merging it. Tell them what bits you want them to work on.

Answer 3

One way would be to use your source control to limit their permissions to certain areas.

Another way would be to create a branch for each developer for them to work on. Then merge the branch back when their work is done and everything looks good.

Answer 4

If you do not want them to modify anything other than the Views and Controllers, it can be done. We do exactly that where I work. We use Team Foundation Server, and directly remove the "check-in" permissions. For us, they are not developers, but front-end designers.

To see how it might work for you, though, we need to know if you are using a version control system, and what it is - since that is a fairly straightforward approach. Alternatively, if the rest of your code is in a different assembly, you could always just supply them with the DLL files and their references could be set up to only use the DLL references instead.

Answer 5

Put the source for the model/services in a separate area of your scm/version control. Have your automated builds create libraries (dll's) for the model/services. This way they are able to use the services, but will not be able to modify or look at the source code.

Answer 6

Depends a bit what you actually want to do.

Do you want to stop them reading the code or just stop them from checking in code.

• You could give them read only access to the area's that you do not want them to change.
• You should have coninuous integration so that you will know if someone checks in something that does not build.
• You could also have a setting in TFS that code should be signed as reviewed when it is checked in.

Answer 7

Export the repository as plain files and give them a CD, then let them setup a git repository and CI. Then you might know a little bit more about the people.

If you have dll:s you can send them a copy and a connection string to the db and import their code by our self.