I'm the technical founder of a startup and I'm currently looking to hire a second developer for our product.

Since I've been the sole developer, there is no formal organization for the project and I wanted to know what would be the minimum organization required to incorporate this second developer.

Right now the code only under source control (a kind of chaotic git repo) but it lacks unit tests and other things that are required for serious development.

I was willing to go without those for a while for the sake of speed, but now that the company is growing, we feel that delaying those might be problematic.

How to incorporate this second person to work with the code?

  • Might sound silly, but: what would you try? Do you intend to actually make these missing unit tests now, are you thinking of documenting your code or do you think about taking time to explain to him the whole architecture? etc… Feb 26, 2014 at 13:26
  • @ArlaudPierre your questions are exactly what I'm looking to find out. What would be the most appropiate way to introduce this person to the code
    – Carlos G.
    Feb 26, 2014 at 18:23
  • what about setting them to organising it and creating the unit tests you are lacking now.
    – jwenting
    Feb 28, 2014 at 9:09

2 Answers 2


I recommend that the new developer actually write the unit tests that the code currently lacks. This will help him get up to speed about what the extant parts of the code do, and it will keep you on development in the meantime.

  • 1
    Was gonna say that, but such tests may not cover edge cases (and thus be completely useless) if they're done at this point of the project with someone else, as this person risks adapting the tests to the existing code, and not to the need itself. Feb 26, 2014 at 14:39
  • 1
    With that in mind the OP should definetely review the tests. But I still assert that building unit tests is a terrific way to become familiar with a foreign code base.
    – dotancohen
    Feb 26, 2014 at 14:44
  • Granted. Do you then recommend black box or white box testing? Feb 26, 2014 at 14:48
  • The new dev should definetely see the code. That is the the real goal, the unit test produced is the side effect.
    – dotancohen
    Feb 26, 2014 at 14:59
  • Which leads to the problems I said earlier as the tests might be based on the code, hence the review. I guess we're in agreement then, you got my upvote ;-) Feb 26, 2014 at 15:09

First, congratulations on your expansion and thank you for hiring another developer.

Focus on hiring the best programmer you can find as soon as possible. There is an exhaustive list of things you could do to help incorporate this new developer, but I think you risk delaying the hire. This person will need to spend time getting familiar with things, so why not involve him or her in the process? When you're part of the cleanup process, you know where you put things.

When you finally hire someone, try to keep track, organize and document everything you do to get this new dev up and running. This is the perfect time to discover what the new person needs to know. Examples.

  1. Getting a development machine configured.
  2. Diagram basic structure of the app
  3. Coding Standards (There's got to be something you do consistently.).
  4. Source Control
  5. Tests
  6. Planning and Estimation

You'll come up with more as the new programmer gets close to writing production code.

This way you don't waste too much time on things that aren't needed. It's tough to predict at first and we all know something will be left out.

Getting your second dev up to speed, may not be as smooth as you like, but don't sacrifice the hiring of the 3rd, 4th and 5th. If you need more programmers, you know your business is getting to a critical success point, so you want to make sure your team is ready to grow.

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