A year ago a junior frontend developer joined our small company. He was freshly out from a bootcamp. He is very diligent and will be a good developer.
My problem is, he is very stubborn. He is the "I know it all" guy.
When me and my colleague tell him, that the code he writes is not the best solution for our problem, he is starting to be very aggressive. Couldn't stand any code reviews.
He started to tell our bosses (behind my back), that we (the dev team) are too conservatives, and we should use React for everything, because this is the new mainstream technology and he doesn't like our current stack. He comes here to learn new tools, not to maintain old projects.
2 weeks ago I started to talk about this issue with him. Told him, that we will use React, but not for our upcoming project because it has a strict deadline.
We will use React for smaller projects.
He didn't liked that and started to push us, that we are conservatives, and don't have the balls to change the stack.
After that I asked my managers, that can we allocate time, for making a learning project for React. They agreed.
So we started to choose the tools for it.
I told him, we should use the context API. He started to yell, because he wanted to use Redux. When I asked, why, he told me, that the Redux is the mainstream now.
I told him, that we don't choose tools like that. We choose tools for the project, not what "YOU" prefer and what is the mainstream.
I asked, that "What will you do, if 6 month in the future, the market will say, that Redux is old now and you should use another API"
-"I will use the other API, but why would they told that? Redux will be maintstream for years!"
I know that I have to learn more, for mentoring other developers and have to improve my soft (and english) skills, but right now I don't have the patience for it.
What would you do in my place?
Honestly, it may be time to start looking to get rid of him. There's nothing wrong with have strong opinions and preferences, but they should be:
Backed up by sound logic. It's mainstream is not a good answer, and you should be firm about this with him. If he can't come up with technical reasons why React and Redux is the right choice then it's just a preference and not how business decisions should be made.
Open to debate. It sounds like he isn't. Good developers need to be able to take criticism and open to learning. If he's not, then he's not a good developer.
Point 2 is important, and it sounds like he's missing that. If he can't be counted on to work with existing systems and learn, then he's deadweight on the company. Working with the team is important, and if he can' do that then he's not a good fit.
I agree with @peterj1994.
This developer sounds much like a small kid throwing tantrums because his parents didn't do what the kid is fantasizing about.
Being a good team player and listening to other people's advice and experience is not a question but a requirement for any job. In many other professions, outside of IT, failing to listen to your superiors would have already resulted in firing that employee, no question asked why. (There was a reason after all that hierarchies were invented.)
Third, this will come from someone who uses React a lot, and get paid for it. And I can tell you there are tons of occasions when it is clearly the wrong choice. Not even go into detail that Redux is not the mainstream choice anymore. Again, if something is mainstream is not the reason to use it. (Cats are mainstream as well, but still many people don't own one.)
Firing this junior would give him good experience in cultivating better soft skills. Sometimes the best you can do with someone is throw them a hardball. The developer sounds young, so the sooner this happens the better chances for him to learn from his mistakes. I'm talking from personal experience here. Uhmm, I wish someone would have explained that to me earlier...
One more thing, based on your posting, looks like he is taking away a lot of your time and mental resources. Does he really worth that much? And no, you won't be a bad person to move away from somebody who doesn't want to be taught. Also, there are tons of people who would be happy to have his job and eager to learn and do the job.
And just, well..., one more thing, your managers needs to get their priorities straightened out. Making clear that your expertise that what counts. Your junior going behind your back, just because he is not the one making decisions, is clearly undermining the trust not just in your technical expertise. But also questions that the people who hired you and put you into a leadership position were they making a good decision? Of course, if they are not backing you, which I don't know about, but if they don't, they questioning that people will trust them as well. It's important that one person doesn't undermine the company values, but adds to it.
Sorry, my two cents of thought got quite an essay in the end. Hopefully, it will help you.
I feel you. I am starting to think that because he came from bootcamp, that is the only thing he knows. He may not have the programming fundamentals and experience to deal with learning a new tech.
If he is forced into other stacks, he will feel powerless. He has nothing more to bring to the table.
That was my main thought while I was reading the post. 100% agreed
It's not easy but it is simple, tell him he's on the path to being let go. The job is 50% people, 30% code review, 20% code and it sounds like he's only capable of 20% of the position currently
Show him the responses in this thread :)
TBH, I think he's more or less right (regarding React atleast).
I don't know what your current stack is, how many people, what the project demands etc.
But to be the devils advocate I've also seen many senior/older developers not give a shot at new tech because they are lazy and stopped trying to learn new stuff. When in fact if they learn it (ex: React, Vue, ...) they would actually become a more productive team with better products.
If you're stack is "outdated" (ex: jquery) I would also be pushing the team to "updated" solutions.
It all comes down to a recruitment problem. The role for his job was probably Frontend Developer with React, Vue (w.e) skills. So, when he gets to the job he needs to work with Ember? I'd also be a little disappointed.
Edit: If he's being plane rude, and not presenting logical reasons behind his behaviour than that's just being a toxic co-worker.
This reminds me a lot of someone I worked with on my team at my previous job. I actually interviewed him and was really impressed with his coding abilities, so gave him a strong yes even though I had some doubts about his attitude. He ended up joining our team and gave everyone a lot of trouble from day 1: complaining about the stack, about us being too conservative, etc etc. He had some valid points of course and he was a really smart person and strong developer, but his constant negative energy made him really hard to work with. He ended up switching teams a few times and finally leaving the company. In the end, he wasted countless hours of other engineers' and managers' time.
I would say, let this person go, and try to avoid hiring such profiles in the first place.
I would let him go, but the managers doesn't, because they are worrying about the upcoming projects and human resources. He doesn't want to leave, because this is his first job.
Frankly the manager is failing the company, his job, this employee, and you:
This is really a weak manager/leader problem manifesting as a petulant junior engineer. The problem employee being terminated is the easiest and long-term kindest thing for the individual actually. The manager is the real problem though.
In that case, one way to make use of him without having him disrupt the rest of the team / codebase too much would be to give him a small, self-contained, greenfield project that he can work on alone and focus his energy on... It's not a great long-term solution but it can buy you some time to look for someone else.
'Know it all' types really can't be taught anything. They have to be open to learning and super intelligent people almost always 'know that they don't know'.
A large part of fitting in with a company (and fit is crucial) is being a team player and not having a personality that makes others constantly accommodate you. That's a bit of insecurity and narcissism at play.
I wouldn't hesitate to bounce someone like that in a heartbeat. There are too many really awesome people that have massive skill sets looking for solid work to put up with a clown.
I'm definitely in the camp of firing him. If you didn't exaggerate anything, and it was my company he would be gone for sure. Building a product is not just about the tech. The user doesn't care. They want functionality. He sounds very immature and not worth your time. I wouldn't change anything about your tech based on his comments. He's probably wrong. He just wants to use the shiniest new thing. There's more to it than that.
This is my opinion, letting him go would be a very easy solution, instead take time to learn about how to handle him...
He might be interested in the new framework and maybe realize there are trade-offs when choosing a stack.
These are just few ways to take control and grow as a team. Instead of figuring out a way to suppress or fire him, you should learn to manage and correct him.
Also show him this thread :D.
I'm curious about what your stack is, because it all depends on that...any way,
let's say you are working on some legacy software, this might be a good time to move away from that
We had a guy like that. At some point he was tasked to develop a set of new functionalities in a legacy JSP based application.
Somehow he was able to stuff AngularJS in it and the seniors didn't say a word. The result: now, after he isn't working with us anymore those features he made stopped working and there is no Christ able to make that thing work again. We are going to rewrite that whole session of the application.
My advice: use the fact your guy is a junior and explain him he is not the dev lead. If he doesn't feel comfortable with the project, he can look elsewhere. In case he chills down, great. If not, you know what to do already.
'What would you do in my place?' Can I ask what is your goal here? And also what are you responsible for (you've indicated that decision about firing is with other people)?
My goal is to keep the team together and ship the projects on time. I never recommended to anyone, that we should fire anybody.
I'm a Senior Frontend Developer and my responsibilities are the same as my goals.
Let's say if you this person were to be disciplined for their behavior, would it be you doing it, HRs, your manager?
Fire him fast.
Wow! As many others have said it isn't good for the team on so many levels. He should be trying to learn as much as he can from those that are more experienced around him, not try and dictate what should be done. Having someone with such rigid preference isn't going to help with your goals.
Maybe you could try and get to the bottom of his attitude by asking questions and pushing him the reasons why, "because it's mainstream" isn't a good enough case on it's own. Maybe he is scared to learn something new because of fear of failure? If that is the case you can encourage/support him to see if it helps. If he doesn't open up and even consider an alternative view point or have a constructive conversation with you, then I would vote to let him go. Maybe he'll learn in future, but probably not.
Give him some task to implement it in Assembly. 😂 It's a joke but now seriously, using some tool in favor of the other just because it's currently mainstream should never be an argument since every solution has it's pros and cons. If you need to get your project done quickly it's obvious you'll use tech stack you and your team already know well. Of course, you should improve your skills towards the industry requirements but it doesn't meen you should always do the 'mainstream' just for sake of it.
I would handle your situation by explaining him that currently you use this solution because you know it better and cannot rely the whole project on junior dev because he is the only one that uses this and if he keeps insisting tell him that next time if he wants his suggestion to be considered to argument it very well. For example I'd ask him to make research presentation about this technology, pros, cons, learning curve, how complex would it be to switch, etc. and comparsion to the current. This way he should be able to learn more about both technologies but it may be time consuming if you need him on your project.
But really, you should have software architect or someone with authority and enough technical knowledge to decide of it. Also your people team should do their job too in this case, because that type of behavior ruins culture in your company and from my experience culture is crucial part of well functioning team and company.
Maybe I'm wrong but it's how I see it from my point of view. :)
Let him go. He is not a team player, and you are running a team. It's about the culture of your company, not technical capabilities.
Engineering is not about code only, its about processes, communication skills, knowing what tools to use and when, and obv not because it's mainstream.
If he is a good developer/engineer, he should not have any problems using X language or Z framework.
Fire him
This comment was deleted 5 years ago