2

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?

gnat
  • 21,442
  • 29
  • 112
  • 288
Carlos G.
  • 129
  • 4
  • 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… – Pierre Arlaud Feb 26 '14 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 '14 at 18:23
  • what about setting them to organising it and creating the unit tests you are lacking now. – jwenting Feb 28 '14 at 09:09

2 Answers2

4

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.

dotancohen
  • 1,001
  • 1
  • 8
  • 19
  • 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. – Pierre Arlaud Feb 26 '14 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 '14 at 14:44
  • Granted. Do you then recommend black box or white box testing? – Pierre Arlaud Feb 26 '14 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 '14 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 ;-) – Pierre Arlaud Feb 26 '14 at 15:09
  • @Arlaud:Your concern about tests being based on "wrong" code should only be valid for a very small percentage of your code. If you've written much code that another developer can't tell what it is INTENDED to do and through testing can't discover errors and discover edge cases then you have much bigger issues than figuring out how to integrate a 2nd developer. – Dunk Feb 26 '14 at 16:16
  • I also wouldn't recommend having the new guy blindly write unit tests. If they can refactor to a cleaner and easier to understand design then I would encourage that also. – Dunk Feb 26 '14 at 16:18
  • @Dunk Though very true, the possibility of having real issues in the code is also a risk that code born by `willing to go […] for the sake of speed` may bring. A start-up code (let's quote the strategy of "breaking and rebuilding" things at Facebook) is usually not known to be clean. – Pierre Arlaud Feb 26 '14 at 16:19
1

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124