Junior programmers may not (even probably don't) have a good idea of what questions to even ask. Younger juniors (e.g. right out of college) may even feel intimated or anxious that their question is "stupid". This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy.

Reliance on online resources is, in my view not a substitute for experienced mentorship: there is the paradox of choice, and the plethora that creates this paradox is of generally poor quality. Except for textbook or trivial problems, moreover, much of the resource material online is too generic or only marginally applicable to the depth and breadth of technology issues that face a real business and its needs.

Totally agreed. This is, in essence, what I would define as the line between "junior" and someone escaping it.

Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.

> "This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy."

I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.

Ask the right question is a skill, and a good indicator for growth. If you have an ineffective team member on your team, you will know the pain. Junior dev isn't necessarily bad, some of them can ramp and contribute really fast, but some are just lacking.

When you hire a junior developer, they are themselves a project. How else could it be? The need for mentoring is what makes them a junior. If they didn't need mentoring, they would not be a junior.

Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction.

As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them.

From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring.

This path will be different for each person. So: have a plan, but be prepared to adjust it regularly.

There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.

Im hired as junior dev. at a relatively large non-tech company, to provide them with software tools, I built all these tools by myself with no mentoring and no help, My fear is this, my code looks clunky (probably not written according to good software design ?), and hard to read for others, I also have no skills in collaboration, how would I be able to grow these skills without a mentor ?.

You sound as if you are already able to teach yourself, just read more open-source code to find out what is good or bad style.

I would consider soliciting a formal mentor here on hackernews. Hacking on a open source project together would be a way to recieve that help in a remote fashion.

Sounds like there should be a thread to match mentors and mentees here on hackernews. Maybe a bunch of mentors post some open source projects that they want mentees for?

I would jump on something like that, I'm a senior university student currently with no work experience on my resume. I have been unable to do internships during summers because I usually need to spend that time helping out my sick father every year, and it terrifies me that I'm going to have to jump into the marketplace with no internships or anything really on my resume.

Every time I try to 'contribute to open source projects' online I get overwelmed by the size and complexity of most codebases, I have tried numerous times, and have never been able to fix a bug.

This type of thread is something I'm sure I and others would take serious advantage of.

When I started my first job out of university I worked in a team where we were tasked with fixing various issues and requests (e.g. reports or minor features) from the business, so that teams working on features could focus on those. Even senior developers would be rotated around into this team, but as a junior develop it was where you first started, to learn the ropes.

It was a great experience, as other members of the team, who were more senior than you, may not have even understood how the application you were looking at worked (we had ~40 applications/services), so you would have to work together to figure it out - both completely clueless. Usually we would pair because of the unfamiliarity, but if we were familiar with the application we would occasionally work solo, even as a junior.

The best bit was the management: there was enough pressure that you knew you had to get this fixed soon, but not so much that you were stressing out.

Code review is horrible way to teach. Especially with reviewers common in tech who just can't tell difference between differences of opinion and crappy code. Or difference between "how I would did it" and bad code.

I don’t agree with this at all. It’s up to the participants to argue their points and see who has more valid designs. I became a much much better programmer by learning from senior devs who review my code.

Except when Juniors are humble and like "yes sir yes sir", don't defend their design assuming seniors know more and internalize everything. And except when seniors give conflicting feedback based on what they read yesterday. It was mostly impact on those juniors I found bad. They were told their code is crappier then it really was and lost a lot of confidence. They started humble and ended afraid to do anything except simplest tasks.

Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it.

Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.

I feel like the problems you're describing are more workplace specific and not specific to the method of CR itself. For example,

> They started humble and ended afraid to do anything except simplest tasks.

It's the job of the team leads to create an environment where people (especially new people) shouldn't be afraid to try something out and learn from it. I've had plenty of CRs which went for some huge number of iterations when I first started, generally this was solved by spending some time thinking about designs on my own and then having a meeting with senior devs to discuss pros/cons and any suggestions before writing any code.

> Also, they got only and exclusively negative feedback.

This sounds really shitty, and this seems like a problem with the people on the team. I always try to put at least one positive thing in a CR after lots of criticism, and if there isn't that much criticism even better!

All in all it sounds like with or without CR, the team you're describing probably wouldn't be a pleasant place to work.

I agree with you, through I am pretty confident the seniors were well meaning. Insecure in more then one way, but still well meaning people with no intention to cause anything bad.

It is not that CR is has no place in the process. It is that it should not be primary tool for teaching, mentoring and leading. Nor talked about that way. Every forum and blog posts talks about CR as teaching tool and every discussion about juniors puts a lot of emphasis on CR and none on other tools. A lot of people think and act that way.

Yeah, it was a long time ago (2000-2003) but I still clearly remember implementing everything twice as a Junior Developer - first my way, then their way.

On the other hand it's possible for this to lead to senior developers who can't or won't leave their comfort zones entrenching designs and patterns that degrade the efficiency of the organization.

What you said is basically a tautology. "This method of mentoring won't work if you have bad mentors".

The person you're describing shouldn't be mentoring. The problem isn't the methodology, but their personality being poorly suited to the task at hand.

This industry frequently conflates effective producers of lines of code, with an ability to function in a senior role. If you look at other lines of work, seniority often implies things beyond "does the basic job quickly".

1.) Depending on the team, code review is either done by everyone non-junior or by the people most responsible for code base and expected to know most about it. It is last approve/reject step before admitting code.

So yes, this person will do code review. And code review has more functions then mentoring.

2.) Mentoring starts on task selection. Latest when junior start working on it - with senior occasionally checking the junior out while the task is in progress. Code reviewer might be someone completely else who might have noticed that junior is working on code only after it is done.

Sane mentoring should not start when junior finished the work.

If the reviewers are giving crappy code reviews, what makes you think they would be better at mentorship?

I it is different task. And you could assign it to different person.

Also, there is level of knowledge to be acquired about teaching and working with people. A culture that does not conflate code review with teaching nor talk about it as a primary means of how to deal with less experienced developers have better chance to develop that knowledge.

As in, admitting that those are different tasks is first step.