JuniorDev ignores every advice, writes bad code and complains about other people not working because he does not see their result because he looks at the wrong places.

Okay, so I am really fed up right now.
We have this Junior Dev, who is now with us for circa 8 months, so ca. a year less than me. Our first job for both of us.
He is mostly doing stuff nobody in the team cares about because he is doing his own projects.

But now there's a project where we need to work with him. He got a small part and did implement that. Then parts of the main project got changed and he included stuff which was not there anymore. It was like this for weeks until someone needed to tell him to fix it.
His code is a huge mess (confirmed by senior dev and all the other people working at the project).

Another colleague and me mostly did (mostly) pair programming the past 1-2 weeks because we were fixing and improving (adding functionality) libraries which we are going to use in the project. Furthermore we discussed the overall structure and each of us built some proof-of-concept applications to check if some techniques would work like we planned it.
So in short: We did a lot of preparation to have the project cleaner and faster done in the next few weeks/months and to have our code base updated for the future. Plus there were a few things about technical problems which we need to solve which was already done in that time.
Side note: All of this was done not in the repository of the main project but of side projects, test projects and libraries.

Now it seems that this idiot complained at another coworker (in our team but another project) that we were sitting there for 2 weeks, just talking and that we made no progress in the project as we did not really commit much to the repository.
Side note: My colleague and me are talking in another language when working together and nobody else joins, as we have the same mother tongue, but we switch to the team language as soon as somebody joins, so that other colleague did not even know what we were talking about the whole day.

So, we are nearly the same level experience wise (the other colleague I work with has just one year more professional experience than me) and his work is confirmed to be a mess, ugly and totally bad structured, also not documented. Whereas our code is, at least most of it, there is always space for improvement, clean, readable and re-useable (confirmed by senior and other team members as well).
And this idiot who could implement his (far smaller part) so fast because he does not care about structure or any style convention, pattern or anything complains about us not doing our work.

I just hope, that after this project, I don't have to work with him again soon.
He is also one of those people who think that they know everything because he studied computer science (as everybody in the team, by the way). So he listens to nothing anybody explains to him, not even the senior. You have to explain everything multiple times (which is fine in general) and at some points he just says that he understood, although you can clearly see that he didn't really understand but just wants to go on coding his stuff.
So you explain him stuff and also explain why something does not work or is not a good thing, he just says "yes, okay", changes something completely different and moves on like he used to.

How do you cope with something like this?

  • 2
    Too long; didn't read.
    To my understanding this usually marks a condensed version of a text. And I like to have it at the beginning so that you don't need to scroll all the way down.
    What did you think it means?
  • 0
    It means you, as author, should write a brief summary of what you have written about. As reader you post to show it was too long and you didn't read.
    And you are the author, not the reader.
  • 1
    Sounds like u have sort of excluded him from the project already. Please include & offer your guidance, get him involved, that's how he will learn to do better. If he remains stubborn and ignorant then at least u tried...
  • 0
    How does someone like that even get a job? Shouldn't the interview process detect and avoid that kind of people?
  • 1
    I think you are totally right. This would be the correct way. In fact, we did this multiple times before this project and during the project. Didn't help, didn't change his behaviour.
    For this project we always told him, when we would go to the meeting room for a quick meeting about structure, how to proceed etc, so all 5 people working at the project.
    Usually he didn't even get up to join. Sometimes he came in 15 minutes after we started and wanted to immediately talk about his tasks and his part of the program.
    When we told him that this would interrupt all of us now and we could talk about that after the current topic, but he could still sir down and join (as offered when the meeting started), he got up, told us to call him when we can talk about his stuff, and left.

    I think we have done everything to include him and to show him a better way of working together, multiple times. Nothing ever changed and the whole team is just tired and fed up of trying.
  • 0
    You know. He was fresh from university, so we expected that is code wouldn't be that great. And it seems, according to our senior, he did quite well in the interview (no technical questions though, just the general personal stuff). He solved the programming exercise, with messy code, but he solved it.
    Aaaannd: his brother is one of our team mates. Actually the last part should have been an argument against hiring him, but that was clear to us when it was too late...

    We now know that our application tests test the wrong stuff...
Add Comment