Ask HN: How do I coach junior devs who wont listen?
Two months ago I joined a dev team at a large company as a senior software engineer on a web app. I joined a team where their last app that they worked on before I joined became maintainable and failed after 6 months (they blame the fact that they used React over Angular). I have been trying to suggest architectural changes as well as suggestions for how to make the app more maintainable, but the junior developers don’t want to listen. (For example, they want to replace our Postgres DB with MongoDB because they don’t understand normalization well enough). Our software lead, despite being a bright guy who knows what he is doing, mostly lets them get away with doing whatever they want to avoid conflict. How should I handle this situation?
9 comments
Change the culture and the devs will follow -- refactor code and illustrate best practices with the team. Emphasize testability, writing tests, simplicity, etc.
Spend time reviewing PRs and making thoughtful suggestions on how to improve things. Don't bikeshed on technology -- like mongo vs postgres, angular vs react -- if the code is written in a clean way, those technology decisions don't really matter that much.
Spend time reviewing PRs and making thoughtful suggestions on how to improve things. Don't bikeshed on technology -- like mongo vs postgres, angular vs react -- if the code is written in a clean way, those technology decisions don't really matter that much.
The problem is not the junior developers. The problem is your lead engineer.
Lead from the front, explain patiently, change what you can, don't fret about what you cannot change, don't get into conflict over technical issues - they are not important.
Read "The Prince".
I have to say though, what sort of technical lead is letting the juniors define anything? Their opinions are worth listening to, but it is the role of the leader to make the decisions.
Read "The Prince".
I have to say though, what sort of technical lead is letting the juniors define anything? Their opinions are worth listening to, but it is the role of the leader to make the decisions.
Perhaps I should have a talk with my lead and ask suggest he take a more authoritative approach?
I'd tell him that if he is not comfortable making solid technical decisions then he should delegate that to the next level of seniority down by appointing someone as the "architect". Tell him it does not work at all to have juniors dictating tech strategy and he risks his position by allowing it. Tell him that the opinions of juniors are welcome but they should not be making the decisions or dictating outcomes, unless of course he either doesn't care or is aiming for big problems later.
Honestly he sounds like a shit tech lead - a leader should, well, lead.
Honestly he sounds like a shit tech lead - a leader should, well, lead.
Odds are that you can't change the situation. Therefore you have to deal with the situation. Your top priority should be taking care of yourself. Are these guys making you frustrated? That is bad, find a way to not get frustrated about it. Because it is not like you are alone -- lots of people are working with "not very bright" colleagues.
In the grand scheme of things, the choice between Postgres vs Mongo for a silly website is insignificant. Don't lose to much sleep over it.
In the grand scheme of things, the choice between Postgres vs Mongo for a silly website is insignificant. Don't lose to much sleep over it.
I remeber myself being a junior - overwhlemed by enthusiasm and lack of experience, eager to just create things, not thinking about how to maintain them in the future. What a pain it was for our leads to handle us.
"Herding Cats: A Primer for Programmers Who Lead Programmers" is a good book for psychological issues like this.
"Herding Cats: A Primer for Programmers Who Lead Programmers" is a good book for psychological issues like this.
A master must prove his worth.
Just because you are senior people will not do what you want them to do.
Building a team of noobs takes a lot of work. That kind of work, I'll only put in a startup where I've ownership.
Building a team of noobs takes a lot of work. That kind of work, I'll only put in a startup where I've ownership.
Ask them why they won't listen. In my personal experience as a junior dev I was working under idiots because everytime I asked certain questions, they never gave me a plausible answer.