Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

We are developing a project with three members. I am the permanent member, we hired a contractor from a company to be a team lead and one very junior coder. Now the contractor is doing the server side coding with classes and modules while the junior member and I are doing front client.

The problem we face is that the junior member and I are finding it very hard to understand the contractor's code. Our skills are not at his level and he is using all sorts of advanced function and write very concise code with very little documentation.

When we ask for help, he gets angry and says that we don't know that. I have raised this issue, but it comes out every now and then. I can understand only 50% of his code and the junior understands only 10% of it.

What should be done int his scenario? We can't force him because we need him, but its difficult for us to proceed.

What should we do?

And also every time we do our part of coding he can always pick errors and tell how to do it better. It is good, but it also means that do we have to check every line of code with him.

I was confused that if we have genius coder in team of 5 then that genius will always write better code. So does it mean that

  1. he needs to check code for every junior member and change it
  2. he leave some loopholes and ignore them

because the senior member will always have better way to do the job?

share|improve this question

marked as duplicate by gnat, Kilian Foth, MichaelT, Dan Pichelman, Robert Harvey Nov 16 '13 at 3:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

"when we ask for help then he gets angry and says you dont know this." Fire him. Do not put up with this, no matter what his other qualities may be. –  user16764 Nov 15 '13 at 2:01
While I agree with this^, checking every line of code with a senior programmer is a great practice. Its called code review. Its there to not only improve the over all quality of your code, but it also helps the junior programmers learn from their mistakes and pick up some extra experience from the senior's mentoring –  Maru Nov 15 '13 at 4:15

5 Answers 5

First off, a senior developer should be able to write simple, clear, concise and understandable code. It doesn't matter how clever someone is, if no-one else can understand the code it's going to be very hard for anyone to add new features or fix bugs. As a contractor I don't want to be in this position! The last thing that you want is a call from the business a month after you've finished saying "argh we need help!".

If there's something that needs to be complicated due to complicated business rules, then the senior programmer should be doing it, but he should be commenting the code liberally so that it can be understood (or at least other programmers can get at what he is aiming at). He should also be walking you guys through the code so you have an idea what's going on.

Second off, I would advise that you change your structure so that you are all working on the front-end and the back end. Having one team for server-side and another team for front-end, also, IMHO, is a bad idea. You all need to get across the codebase and understand what's going on. You need to be able to work on the entire flow - from the front end to the server to the DB back up to the front end. If you think it's going to be "easy" to integrate your backend with your frontend once you're done, you're going to be mistaken.

If he's getting angry when you're asking him questions then something is wrong. He's either frustrated, annoyed, paranoid, egotistical, or just a nightmare (sounds like most of us). You need to escalate this to your boss - things will only get worse unless these issues are resolved.

share|improve this answer

I'm going to address the specifics of your situation instead of the broader question you posed. For the broader case with a team of 5, have a look at this Programmer's question which should provide some additional insight in that case. Hat tip to gnat!

Your case is a little different because you're the only permanent employee and it is a contractor's code that is creating issues for you. Presumably, it will be up to you to maintain this software after the development is complete. So you have an obligation to understand or be able to understand all of the code.

Your first step is to talk with your manager. Objectively explain the issue (your question above is a good starting place but provide more details) and also explain what you have done in order to try and resolve the issue. Then provide a few options for how you think your manager can help you with this case. Your manager controls the contract that pays those contractors. Therefore, your manager has leverage in this situation. You need that leverage on your side.

Next up, you need to schedule code walk-throughs of the senior developers code. Call it cross-training, call it knowledge-transfer, call it whatever. But you need to start learning what the other person is putting in place for the back-end code. And you need to start now before the project starts winding down. Otherwise the contracted senior developer will already be out the door and working on another project and you'll never be able to ask any questions.

From there, you need to work in some of the back-end code as well. This may slow down your overall productivity because you'll need to switch back and forth between areas. You need to make sure your Manager is aware of the possible slow-down and you need their backing (remember the first step I suggested?). The best way to learn a section of code is to start working on it and either adding new features or fixing problems.

Finally, you need to have a conversation with the contracted senior developer and your Manager. You need to lay out the long term prospects of how maintenance is going to work. You can provide the senior developer with a few options. They can start explaining more of their work to you, including teaching you the techniques if necessary. Or they can also start reducing the complexity of the technique they are using. The could also start putting in more comments, even if they feel commentary would be unnecessary. You can remind them that the comments aren't for the original coder, they are for the maintainer.

These are all items that should have been spelled out in the contract-for-labor that was signed to bring the other developers on board. Your team should also have a coding standards document that covers expected levels of documentation and commentary within the code. Some standards documents will forbid particular techniques for whatever reason, which may be appropriate in your case or it may not.

I am assuming the junior developer on the team is also a contractor and won't be retained at the end of the project. If that's correct, then I would talk with your Manager about what the expectations are for the areas that developer will maintain. You can then include the junior developer in the above areas as appropriate based upon your Managers expectations.

share|improve this answer
+1 "Your first step is to talk with your manager. Objectively explain the issue." Definitely. Also, understand the contractor's viewpoint. He probably thinks he was hired to generate lots of code quickly, and if he's too slow he could be fired without warning. That does happen to contractors sometimes - they have no job security. This could explain why he gets angry when (the way he sees it) he's interrupted from coding. So he may need reassurance from his manager that knowledge transfer is important, and that it's OK to develop a little slower. –  MarkJ Nov 15 '13 at 13:15

It's time to sit down as a team and discuss how your architecture can be developed for EVERYONE involved, not just this senior. As mentioned by LachlanB, a true senior's code should be easy to understand. They simplify wherever possible and add enough context to make it easy for others to understand their code.

Your software greatly reflects how well your team communicates. If you don't do something soon, you'll have a final software package that is difficult, if not impossible to maintain. Long term, no company wants that (we've all been there). So escalate this to your project managers (or whatever management you have available) and request the time you need to have ongoing meetings as a team.

You may need to act as Conflict Resolution Guy in the short term to help get everyone on the same page and understanding the same patterns of development. You will need to be across both the back and the front ends. Someone needs to take ownership of the whole system, and that sounds like it needs to be you, since you are the permanent. With that in mind, be careful how you approach this senior. Never say anything in an accusatory tone, or he'll likely walk. Instead, simply be honest and say that you (as a company) need his help to better understand how to integrate with his code. He should be prepared to give you examples; examples that you, in turn, can pass onto your junior devs. If he doesn't help, then escalate to management.

These conversations should have happened before a line of code was written, but since you've already started, it's time to put on the brakes and come together before you move forward.

Good luck :)

share|improve this answer

I'm not sure I believe in the senior coder "dumbing down" his code, unless he is intentionally obfuscating it in some way to secure his position (ie. the company need him as his code really is overly complicated)

But what I would certainly expect is for him not to get angry when asked about it.

Maybe he is frustrated as you and the junior are asking about everything and making no attempt to learn some of these advanced techniques.

share|improve this answer

One genius developer with two mid-level developers are normally less productive than three mid-level developers.

Say you start learning how to box, and you get put into a ring with an area champion on a first training. What will you learn? Probably nothing, apart from humiliation and pain. Put two boxers with similar level of skills into the ring and you might get one hell of a show.

share|improve this answer
I disagree. A genius developer should be able to get more work out of the two mid levels if s/he's such a genius. –  LachlanB Nov 16 '13 at 3:35
It doesn't work that way. Psychology plays a great part in this. Why bother learn something new or try hard when you know that the 'genius' will always do it better. I've worked in places where very clever (not necessarily good) software engineers would never praise juniors and they would changed quite a lot of code to something that is smart, but hard for most of developer to understand and maintain. This is counter productive. What happens when the 'genius' leaves the team? The rest of the team might get fed up with the 'genius' and leave too. I've seen this happen before. –  CodeART Nov 18 '13 at 8:23

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