3 ms·
> 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.
by sanderjd 4y ago
> 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.
- BeetleB 4y ago> 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. -
- sanderjd 4y ago> 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.