4

I am in a situation where my team has mostly junior developers and recent university graduates. Even with my few years of development experience I already see many things going wrong with the project we are working on. Certain developers with non software backgrounds are let into the project with full power of making decisions and submitting code. I have tried explaining importance of taking time to learn and produce quality code but it seems to be not taken seriously. Since we do not technically have a project lead, I cannot make much difference other than continue refactoring poor code. A common solution to this problem would probably be code reviewing but the pace at which we are going simply doesn't allow for it.

At this stage, I can either give up and let project flow on its own or suck it up and continue refactoring and working overtimes. I don't have much experience in managing teams so I am asking for some advice.

eYe
  • 700
  • 7
  • 15
  • http://workplace.stackexchange.com/questions/74388/how-do-i-encourage-coding-standards-with-a-new-co-worker/ –  Dec 08 '16 at 00:25
  • 3
    "it seems to be not taken seriously. Since we do not technically have a project lead" Eh what? You're the team lead aren't you? Because if not then your last sentence doesn't make sense and the only thing you can realistically do is to fall back on NMFP. If you are the team lead then the answer is simple: manage them. Of course that's not quite as simple in execution. So, do you have authority over these developers? – Lilienthal Dec 08 '16 at 10:54
  • @Lilienthal I do not have any authority over other developers. I am the only one that had exposure to real world software within my group. – eYe Dec 09 '16 at 05:38
  • @eYe Well then this is not really your problem to solve. Have you discussed it with your manager? Does she want you to refactor their code? Is that a good use of your time? – Lilienthal Dec 09 '16 at 08:33

4 Answers4

16

I don't have much experience in managing teams so I am asking for some advice.

If your company cannot be bothered to perform code reviews and would rather spend time and money on constant refactoring, there's not much else you can do. Pair programming is another obvious solution, but if code reviews are out, pairing is probably out as well.

I'm also assuming that you aren't in a position to get rid of juniors and newbies and hire more senior developers with real experience.

Sounds like you have to either get out, or continue on as you have as best you can.

Continue to lobby your boss for better practices, and more experienced developers. But don't expect much in the short term.

Joe Strazzere
  • 382,456
  • 185
  • 1,077
  • 1,492
  • Pair programming may be of little value if both members of the pair have the same limited amount of experience. – alroc Dec 08 '16 at 13:40
7

Explain the situation to your manager and ask them to delegate to you the authority to do code reviews and enforce coding standards.

Have the dev servers reconfigured so that all code produced by the developers cannot be put into repos without your sign-off.

Nobody is going to take producing code the way you want it if you are not serious about reviewing the code and enforcing coding standards. If all you want to do is have them produce their code the way you want it but you can't review the code because "the pace at which we are going simply doesn't allow for it" - that's nonsense. Either you mean what you say when you want the code produced the way you want or you are bullshitting. Choose. Standards simply don't automagically enforce themselves. Never did. Never will.

Note that if you are going to be the one doing the code reviewing, don't expect to write much code on your own. Especially if you have to explain to a whole bunch of junior devs where their code was non-compliant and what they have to do to fix their compliance issue. And your manager should understand that. The team is going to be productive but at the cost of you having the time to write code of your own.

Vietnhi Phuvan
  • 72,342
  • 8
  • 133
  • 268
2

A common solution to this problem would probably be code reviewing but the pace at which we are going simply doesn't allow for it.

This tells me you know the solution, but can't get management buy-in to implement it or, worse, you don't want to make the effort to review.

Reviews can be done many different ways, and be as strict or lenient as possible. I work at a research company where non-software-engineers write code and projects are short lived so the code review we had at my industry job are out. You have to hit the right balance of "check that the code is up to snuff" vs "get all the things done by the deadline." When you step into initiating code reviews, start light and make the rules for passing them clear.

When starting code reviews on teams that haven't had them before, I setup the lint/checkstyle/findbugs/StyleCop/whatever that checks for industry standard stuff in your language. That way the review is pretty much "You have N violations, fix them" which is quick for the reviewer and clear to the code writer. Then the eyeball review is making sure they haven't blanket ignored violations on a class, and a few big issues that the tools missed.

Don't go overboard with the code review. Outside what tools will catch pick only a handful of other things to mention. They aren't suddenly going to write Clean Code (tm) and I'm guessing you won't get by-in from management to go that far. Start small and quick -- hopefully with a build process that facilitates checking this stuff -- to slowly teach the juniors how to write better code. Over time good habits will form in the juniors and you can start to tackle other stuff.

My last bit of advice is to get people to review your code too. That way you aren't looking like an a-hole telling others their code sucks but somehow yours is amazing. If you are reviewing their code, they should be reviewing yours.

Lilienthal
  • 59,386
  • 42
  • 219
  • 254
adeady
  • 1,658
  • 13
  • 13
  • +1 for the last paragraph. If the OP's code is much better, the (less experienced) reviewer should learn something from it. – Peter K. Dec 08 '16 at 12:31
2

You're the team leader, they have to do what you ask. If they don't, bring it to your manager. If the manager won't help you, ask to not be a team leader any more because you'll have no control over what will be produced yet you will still be held responsible by your manager. Moreover if you refactor after what they did, that will be even worse, because your co-workers might say something like

It worked on my computer but he broke everything with his "refactoring".

So really :

  1. Stop refactoring their code. If there is a bug, send it to the one who developed that part.
  2. Use the advice given by the other answers here to try again to enforce better practices for the team, start codere views,...
  3. If nothing can be done, try to be moved on another project or look for another job.

As a side note:

I have tried explaining importance of taking time to learn and produce quality code but it seems to be not taken seriously

I have known people like that, some of them just don't care at all and whatever you say, they won't listen.

Lilienthal
  • 59,386
  • 42
  • 219
  • 254
Walfrat
  • 1,964
  • 15
  • 19