Hacker News Reader

Comment by ido | Hacker News Reader

The above explanation is great but I think the example you selected (git) is rarely the right thing to choose as for most companies git isn't where the money comes from (notable exceptions are companies like GitHub or GitLab). Sorta like the difference between working in the IT department vs Development (for a software company).

Maybe a better choice is something like CSS: there's actually a lot to know about it and a lot of companies need people who are good at it for their core product (even though it's not as deep a topic as say being very knowledgeable/skilled in functional programming).

View on HN

It's been surprising to me to see my wifes deep knowledge of git, SVN, and perforce be so cherished in her organization. Surprising because she works for a place that is routinely featured on the frontpage of HN, where very nearly every single person on HN has used their software sometime in the last ~30 years. It was my view, originally, that these people ought to already have the answers to the questions they're asking. I was wrong.

Her and one of her colleagues are the de facto git gurus in her entire department of over 100 people. She's ended up owning tooling in their build pipelines that is quite complex, using libgit, etc... That tooling was eventually exported around to the rest of the engineering teams (~1,000 total engineers). Now she gets random, challenging git (and perforce, to a lesser degree, and she stepped in to help with some SVN issues at one point in time, though those projects have moved over to perforce, I believe) questions from the entire engineering organization.

I do agree with you, though, that git is probably the wrong thing to focus on and that she and her colleague are outliers. But, it's interesting to see nonetheless.

At least in pre git days many large companies had people whose entire job it was to merge and resolve merge conflicts. They were not part of the project teams. They were part of the build and deployment team.

Granted in any sane company this should just be done by the devs themselves. But as the OP said, in most teams knowledge about versioning, branching and version control is very very limited. Even if all you know is how to do a rebase of a longer lived feature branch easily in git (skipping the commits from the other branch) you will be the wizard that everyone goes to. Many many devs will not even attempt a regular rebase. It's black magic for them.

If all you desire is a cozy job in a large company with braindead processes and policies this sort of thing is probably enough to be tipping the scales towards: well we shouldn't lay off that guy coz he's the only one that can work the version control magic AND he codes like mad.

If you wanna stick out in a company filled with John Carmacks you will have to do better, sure.

Managing distributed version control at scale is one of the core challenges facing nearly every growing software company. Performance issues, the increasing incidence of merge conflicts, preemptive CI, build system integration... this is definitely a topic you can go deeply into, and make an impact at many companies.

On the flip side, you are now a source control/build system engineer, and it's pretty easy to get typecast as such (given the outsize impact your specialist skillset will have).

>the example you selected (git) is rarely the right thing to choose

It's clearly just an example, but whether it's a bad one or not is debatable. Git is used by most shops, and most people have challenges with it at one time or another. Further, it is IMO an excellent example of how choosing the right data structure for a problem can have a profound impact on the resulting application. You could do worse for broadening your knowledge of ComSci than by a deep study of Git.

Reply on news.ycombinator.com