> Hire people who can and are willing to read.

Also make sure they are able to read more than the first few words of the first sentence…(from bitter experience)

Reading is a huge problem with certain developers.

It's not only documentation, which they ask for but never read. They also won't read error messages, and ask seniors for help on almost every situation.

(But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)

> (But the most infuriating thing is when they assume the error message doesn't have any info, and when sharing the screen you have to repeatedly ask them to not navigate away because you're reading it)

Oh yeah - this drives me nuts, although I've seen it more from laypeople than developers. Some people are hard wired to just hit Enter for any informational window that pops up on the screen. I've talked to people who have no idea they're getting errors: "I just hit Enter so I can get to the program."

I kinda understand when laypeople do it, can't really blame them.

I guess developers who do it got the habit from their layperson days.

> I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed.

Git is nontrivial and has many ways to do things, and it is only one of many ways to do most of these things.

If commit messages and merge squashing take the discernment and nose of a winemaker, you can't tell them to crush some grapes and leave it at that.

What you need to shepherd them toward is not the commands to run to branch and merge, but the why. Why are branches useful? When should you merge? What do you do if there are conflicts? Most of this stuff isn't book material. It's what senior developers should be teaching junior developers.

Although the original commenter referred to junior people, I'm often having to explain these things to those who are not - sometimes to people with more experience than I have (e.g. 15-20 years).

Besides, there are plenty of online resources as well as books on the purpose of branches, and its benefits. Some of these have been around since before Git existed. I don't have a problem explaining the why, and pointing them to resources. It's the inevitable "OK, but how do I do that with Git?"

Extending it a bit: I often work with people who will never read a manual. They'll want to find a quick SO answer, or a short tutorial for everything. But once in a while, you need to read the man page, or the official docs.

Ok you convinced me that you're approaching this in a reasonable way. I also eventually check out from helping people who I become convinced are unwilling to help themselves.

> Why should I have to teach a junior how to use an essential tool of the job

Why shouldn't you? Unless you're a junior developer yourself, mentoring and developing the skills of the rest of your team is an even more important part of your job than whatever programming you're doing.

> Why shouldn't you?

Because I expect people to have basic reading and Internet searching skills.

As I mentioned elsewhere, I don't have a problem mentoring them on what skills they should learn. I also don't have a problem directing them to resources where they can learn - even telling them what to focus on and what not to focus on. But I expect that once I point them to a resource, they'll go and read it. For things that don't have good resources, or if it's just a small tool/library that's not essential for their job, I'm happy to walk them through it.

Put another way: If you were my boss, would you want me to spend my time teaching the same basic Git usage to every junior hire? Teaching the same stuff over and over again? Wouldn't you rather I either write docs or make a video once and just have them watch it? Or even better, just point them to the many existing docs/resources out there?

> Put another way: If you were my boss, would you want me to spend my time teaching the same basic Git usage to every junior hire?

I guess I think it depends. I think some companies absolutely do need to take this on, hiring very green brand new hires and investing a large chunk of their more senior engineers' time into showing them the ropes. How else would it get done? I don't mean only for this specific example of git usage, but every entry level employee - whether from a college program or a bootcamp or self taught or whatever else - is gonna have a lot of gaps, and the company, and thus its more senior employees, should recognize that it's their job to mentor them through those gaps. Personally, I think companies are too hesitant to hire truly entry level employees and invest in training them.

> I don't mean only for this specific example of git usage, but every entry level employee - whether from a college program or a bootcamp or self taught or whatever else - is gonna have a lot of gaps,

That's understandable - the issue under contention is how to address the gap. I absolutely do not expect people to know Git when they start. If you look at my comment history, including in the last few days, you'll see that I dislike Git and think there are better alternatives.

The issue is: Once a gap has been identified, and there is plenty of documentation/resources out there, why is it not enough to point them to it? Why is it not enough to have a Wiki page listing all the tools they're expected to know/learn, with guides to resources to learn from? If there's a specific, obscure or internal tool with poor docs, I can understand spending time with each hire. But should a developer always teach:

- How to use Git

- How to write makefiles[1]

- How to do regular expressions (including teaching the syntax, etc).

- How to use a standard shell (bash/zsh/csh/tcsh)

Larger companies often have senior folks teaching courses on these, which I like. My complaint isn't that these courses shouldn't exist. It's that with some employees, directing them to the course simply doesn't seem to suffice.

I think the role of mentorship by senior folks is more for :

- Teaching them certain design principles/patterns

- Pointing things out during code reviews

- Teaching how to test things well (I still haven't found a single good resource for this).

- Teaching when to shun/embrace complexity

- What they should learn/focus on (e.g. identify strengths and weaknesses, and how to overcome weaknesses).

And so on: Basically things that are mostly gained out of hard experience or that are undecided (i.e. differing opinions in industry - senior giving his/her take).

But certainly, if there were books/resources that unambiguously teach items from the above, I think a junior employee should be given that resource and they should learn.

(And by learn, I mean on the job, on company time).

[1] Although I'd used makefiles to compile tools for over a decade, I never learned the syntax. Then for one job I needed it. No one would teach me it. It's a heavily used tool and it was understood that I should just read the Make docs. I didn't think it unreasonable. -

> Why is it not enough to have a Wiki page listing all the tools they're expected to know/learn, with guides to resources to learn from?

It's not enough for the same reason that we have classes and teachers in schools rather than just lists of textbooks.

But I agree with you that some things are more and others less valuable to teach interactively rather than through "book" study.

> Put another way: If you were my boss

If you have a good relationship with your boss, talk to them. Don't whine. Have a solution or a fact finding plan.

Why are they coming to you? How is that expectation being set and reinforced? I don't know how many people this is, or how big the entire org is, maybe you need an org-wide bootcamp. If they don't have basic reading and internet searching skills, how did they get the job? I smell something for management to handle here.