3

We have a pretty complex project with 100 or so classes, multiple custom elements, etc. We have a new senior programmer who will work on this project.

How should we approach the task of introducing the senior programmer to the project? How can we make sure the programmer does not break some other feature while fixing the current one? I have seen too many similar situation.s Sometimes, new bugs are not noticed immediately -- but pop up months later.

Shall I direct the programmer by first giving them smaller tasks and waiting for them to finish them? Or there is a better solution?

I am asking this because I don't want to become micromanager but I also don't want to have nasty bugs created because of my bad approach to the new programmer.

Improve this question
5
  • 5
    Normal developers have suite of automated tests to ensure nothing gets broken. And code review/pair programming to ensure new guy writes new tests properly and doesn't break previous tests.
    – Euphoric
    Commented Jan 26, 2014 at 20:25
  • 2
    I just answered your other very similar question like so: programmers.stackexchange.com/a/225590/70298
    – miraculixx
    Commented Jan 26, 2014 at 22:59
  • Why downvote for this question? It's an everyday situation where we got burnt in the past. Don't understand.
    – deviDave
    Commented Jan 27, 2014 at 20:08
  • possible duplicate of Knowledge Transfer and software development
    – gnat
    Commented Jan 28, 2014 at 8:47
  • @deviDave any number of reasons. My guess, you rapidly asked several similar questions in a short time span. Such rapid fire questions can overwhelm the people answering them on smaller sites. While you were posting these, you filled up 1/4th of the front page (and it remained such for awhile), claiming quite a bit of attention (positive and negative) on just your questions.
    – user40980
    Commented Jan 29, 2014 at 1:16

3 Answers 3

Reset to default
14

We have a pretty complex project with 100 or so classes, multiple custom elements, etc. We got a new senior who will work on this project.

This actually a small project, unless the classes have been allowed to grow to thousands of lines of code. A project of 100 classes should be easily managed by one or two developers.

How can we make sure he does not break some other feature while fixing the current one?

After every change, you should run automated tests to largely ensure that no features were broken. However, I get the impression that you do not have such tests. In that case bugs are almost inevitable, and they will occur more and more frequently as the size of the code increases. You can mitigate this somewhat by carefully reviewing code before it goes into production.

I have seen too many similar situation and such bugs are not noticed immediately, but sometimes months later.

This is a result of inadequate testing. Errors in programming are inevitable. All we can do is reduce the frequency. The first line of defense is automated tests.

Shall I direct him by first giving him smaller tasks and wait him finish them?

You should have him work on tasks with another experienced developer. Perhaps they will both learn something.

... I also don't want to have nasty bugs created because of my bad approach to new guy.

Automated tests will largely prevent this. Whenever a bug is discovered, create a test that fails. Then fix the bug so that the test passes.

Improve this answer
2

I think you can take two approaches, one could be giving the new person a piece of work where something a bit isolated would be developed (e.g. a new page/screen) this way the developer can explore the current project and check how some things were already done in the past. While doing this piece of work he/she will also start taking some decisions related to the design of the new piece of work that he/she is working on. This can lead to questions and discussions that can be useful for the developer to get more understanding on the project and how things have been done. You can also make peer reviews on the work or do some pair programming at the beginning of the task.

Another approach can be to give small assignments related to support, like fixing small bugs. On this case I agree with kevin cline that automated can be extremely helpful to make sure that everything is still ok.

Improve this answer
0

Get him to run a regression test pack on parts of the system that he'll be working on. I would do that prior to allowing them make any changes in code.

Once they are comfortable with how the application works, get them bug fixing. Peer review bug fixes to get a good idea on their skill set.

He will break your application, but that's what regression and unit tests are for. If you don't have these, then be prepared to take a hit.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.