Hacker News Reader

> have to spent their days explaining how GIT (yes, really...) works to a small army of juniors.

I sympathize with the other comments explaining that Git is highly nontrivial, but I think the point is being missed. Why should I have to teach a junior how to use an essential tool of the job, when I can just point them to good books/guides on the Internet?

My list would definitely include:

Hire people who can and are willing to read. Be it for learning or for understanding specs.

I'm not one of those people who gets upset at people coming to my cube to ask questions - I actually enjoy it (far more than them IM'ing me). But if it's something easy to find on the Internet, or clearly documented in a local wiki/manual, they should have at least tried to read it.

Similarly, I'll take the time to document very well how a tool I built works. Almost always someone will then come to me and ask "Hey, can you tell me what the tool does and show me how to use the tool?" Over 90% of the times it's not because my documentation is bad (which I admit it very well could be), but because they didn't even try to read it.

> 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.

How about just making branches and merging? Why do I need to explain that to an employee? If they can't do with git very basic things it's because they're not willing to read.

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.

Yes, I was in an "agile" org that over-hired senior engineers and then expected them to just do regular "spade" work tickets.. but more quickly / more per sprint. No ownership of long running projects/tasks, no design/planning, just a constant stream of whatever ticket is at the top of the queue - GO.

Over the last 12 months, 55% of seniors have left. Most that remain have been at the firm 0-1 year.. The median senior now has 1 year on the team versus previous median of 3 years.

There's basically no institutional knowledge on the team anymore. Managers have now convinced themselves that all these green engineers are going to build v2.0.. however they are basically recommitting all the mistakes and suffering all the pitfalls that v1.0 did because.. no one is left to ask..

I just want to know how do you keep a job as a manager when you fuck up so badly. The vast majority of what seniors bring to the table is experience. That is also what you pay for. That experience is not like gold, it's like a gold mine - you have to mine it first, then bring it to the surface and only then you can profit off it. The fact that there are software houses out there that do not understand this is amazing (in a bad way). I mean I guess there is some value in a senior dev coding menial tasks (generally more mature, less error prone code with the right amount of abstractions), but that like saying there is some value in a rocket engine pulling a plough... technically true, but not really economical and there's a pretty good chance of most of your rocket engines going away rather quickly.

Larger cultural issues:

Bad engineering - product relationship

Inability to set priorities

Zero roadmaps

No annual/quarterly objectives

The only thing that mattered was the thing someone was screaming about right that minute

Manager walked rather than deal with it anymore as well..

> My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated).

What one developer can do in a week - two developers can do in two weeks!

If we move to a microservices architecture, we can use 100 developers to solve same the same problem in with ten times the hardware!

With growth like that, we'll be unstoppable!

Make sure to deploy your micro services in Microsoft Azure AKS to improve the reliability on the long term, thanks to the included and frequent network issues.

How else will we justify the military grade, globally distributed, multi-planetary federated, immediately consistent Kafka cluster that the CIO just purchased? I’m still not sure how to get all the servers to synchronize when Mars is on the opposite side of the sun.

That has more downtime during upgrades than my college dorm Counter-Strike server built from leftover PC components ever had.

It sounds like you're not having enough coordination meetings. You can make communication more efficient if you add more levels of hierarchy. MBAs are good at managing. Engineers are often wandering off-topic, so put MBAs in between the engineers to manage the communication and avoid unsupervised engineer-engineer-contact between different groups.

I was waiting for a /s at the end of this comment, but now I can't tell if you're kidding.

If MBAs weren't economically efficient, the market wouldn't make so many of them and companies wouldn't pay them so much.

I refer you to the discussion a few days back on people not being accurately modeled as rational agents: https://news.ycombinator.com/item?id=32181987

Companies and entire markets follow similar patterns of only having bounded rationality, IMHO. Markets can also have decades of slack or delay from stimulus to outcomes. Take the slow decline of Boeing after acquiring McDonnell Douglas and their MBA heavy structure. https://qz.com/1776080/how-the-mcdonnell-douglas-boeing-merg...

This is pure fantasy. Markets have never been efficient and actors have never been rational.

I think that was sarcasm. Or at least I hope so.

Markets are more efficient and by rational it means they act in their perceived best interest to optimize their own utility.

You just don’t know economics, that doesn’t make it fantasy

And you surely got enough answers showing why the "\s" is important...

That's like looking at America and saying obesity and opioid addiction must be drivers of economic success.

MBA schools are just credentials laundering services.

They need more morons.

Source: https://www.mit.edu/people/dmredish/wwwMLRF/links/Humor/Admi...

There hasn't been a single job where I didn't have to explain Git to someone. Or that Git is not GitHub.

Wherever I was somehow in charge of some authentication / account management (never been my primary responsibility, but "people who know cloud" teams often get that honor anyway) I have always had someone who didn't understand MFA. Either they assumed because MS Authenticator sends them a push, AWS should send them a push or they would have a clock desynced so hard that the most generous TOTP grace windows couldn't save them.

My partner is in a place right now that had to be introduced to python dependency management. Really. No containers or anything like that either. Just alternate runing the script and installing the latest of a package until the import errors disappear.

I really don't mind tutoring, but many of these people also would rather wait 20 minutes for you to respond than 5 minutes on Google. Or even your internal documentation. That's linked in the Slack channel they're asking. It drives me nuts people value their peers time so little.

It’s hilarious to me to think “let’s put all the managers on one team…”

Reminds me of the B Ark.

https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_...

An interesting sociological question arises about how knowledge is passed down through generations.

One could count the number of software engineering management tenets on one hand. One of them was detailed in a popular book almost a half century ago.

If managers haven’t heard of the Mythical Man Month, how can one have any confidence at all about any of their decisions. Is management a knowledge-free profession?

I knew a CEO that claimed that Mythical Man Month was his favourite book.

As soon as it was decided the team was late (due to constantly changing scope) he put forth a plan to make the team 4x bigger in one year. Contrary to probably the most obvious lesson from the book.

People just don't read. Or admit THEY are at fault.

Manager (or possibly his boss) needs a leaving present of the mythical man month

They'd probably fail to see the correlation in having their senior ICs occupied re-explaining Git to a constantly rotating offshore roster -- they're getting 10 engineers for the price of 1 after all.

As someone who interfaces deeply with Git on a daily basis, please don't imply that it's trivial or simple. There are a million edge cases you can get into, and people with 7 YOE on my team are regularly surprised by the facts we uncover.

Git command UI sucks (compared to some alternatives to SVN, HG, ...).... I'm not teaching that to other people except bare minimum. I will gladly explain advanced stuff, but they need to grok the basic themselves...

Yes, git can be complex. It's also a requirement for modern software development. It is well documented, and not esoteric.

If someone hasn't taken the time to learn the tools their team uses, they will be a burden to the rest of the team. They don't need to become an expert, just experienced enough so they don't cause problems for others on the team.

> If someone hasn't taken the time to learn the tools their team uses,

How does your company handle this? How do you give the people the time/resources to learn those tools?

My company handles this by allowing them to study on the dime. I just ask how much time they want and ask them to do it, and if they need some material or help devising a study plan.

Curiously the two that needed it didn't really want to study at all, and we eventually let them go (they were interns).

I've never seen documentation on Git that was good and accurate. Pretty much every explainer out there commits major errors, claiming things like: commits are changesets, branches are sets of commits, claiming that any Git operation can be undone, implying merge is a symmetrical operation, or saying to never force push.

Being a beginner in Git is probably hell.

But 90+% of the time, it'll be a basic use of add, checkout, commit, merge, pull or push, especially if you're a junior.

Don’t forget the most important operation: rm -rf the whole directory and re-clone the main repo.

git reset HEAD —hard

Yep and if that doesn't work?

Sudo rm -rf

If someone has no idea what ‘git add’ is, the criticism is still on point.

I don't think they were. Software devs hitting the job without understanding git means your hiring team is sleeping on the job.

Some managers do that kind of things to prepare the next step of their career or because they worked for the company they are hiring (which is a variation of the first point.)