This is ridiculous. It might be true that there are many great developers that have nothing on github but it is certinaly not true that "actual best developers have little or nothing to point to on github".

There are plenty of "actual best developers" who have prolific amounts of stuff on github, directly or indirectly.

>> The actual best developers mostly have little or nothing to point to on GitHub. You might find this shocking but many of them don't even know how to use Git at all.

It all goes in circles. As soon as Github (GIT in general) becomes adopted by the majority of enterprise (already happened probably) we are gonna see something else which is "cool". Something else, smaller, simpler, cooler gonna attract the next wave of programmers. I am sure there is a great space for innovation.

...source?

Game industry would be one source. At least for many teams and projects, Git isn't very useful (horrible for large binary files common in AAA games). So many companies still use Perforce or sometimes you'll see SVN still. That means a whole bunch of really qualified engineers who have never or rarely used git.

I'm sure there are other industries for which that is true too.

It's a good reminder how small a section of the tech industry comments on Hacker News.

I've encountered this myself as someone who maintains small open source games. Engineers with vastly more experience than I do have approached me with contributions, but needed me to walk them through installing and using git. You could tell they were good engineers because they were so eager and happy to learn it. I can't speak for how big of a demographic these types of engineers are but they certainly exist.

> as someone who maintains small open source games

Are those public? Very intriguing, would you mind sharing a link?

Uh, git is how old? "Engineers with vastly more experience" might be how old?

Hate to tell you, but these engineers probably wrote code pre-Google, or pre-WWW, and actually got stuff done. Amazing, that.

Timeline of Github: https://en.wikipedia.org/wiki/Timeline_of_GitHub

suggests that things really got started in 2013.

Thus anyone with over (2022 - 2013 approx 9 years) of experience might have had substantial pre-git experience.

Noting as well that even post 2013, github might not have been the default in many organizations.

Heaps of us.

A stack of manuals several feet thick...

I started at the end of this era, working on a monitoring team that supported mainframes, network and data center systems. My second week on the job, my delivery of books arrived. About 30 linear feet of documentation. Iirc, it was part of our ELA.

I kept a couple of the references that I spent a lot of time in, along with my Perl books. Good times.

Old people who manage legacy systems, like that one guy duct-taping a bank's online operations.

Are they really the "best" developers? It just sounds like a different skillset and mindset, not necessarily better or worse.

I am willing to wager in a broad sense, that the best COBOL, Fortran, and RPG, that "Old people who manage legacy systems" is probably a fair estimate, and there is probably narrow overlap between developers for those languages and git experience.

There are lots of younger folks who fall into supporting these platforms through experience, but I would also wager that the number of fresh, doe eyed engineers graduating from uni/college thinking "I am going to be the best COBOL programmer!" can probably be counted on one hand :P

I encountered such a person. Her parents were both mainframe nerds and she was a true believer. I think the shock of working as a 23 year old in a group of geezers that had been fighting each other since 1975 was traumatic.

We stole her and she was a pretty awesome DBA last I knew.

Nearly all DBAs i have worked with have been great. Not sure why that is, but it's been very consistent.

Not in GitHub, that's for sure.

SourceForge of course

These "best developers" should really start learning to use Git (and these other newfangled technologies) or else in 10 years they'll be blaming age discrimination when they can't land their next job.

I can believe they don't have an extensive GitHub... but if they can't use Git they must have either only had a few jobs that all used something else(That's fine, just uncommon), or be in a specialist industry that doesn't use Git(Also not common), or they don't know VCS at all.

Plenty of companies use source control other than git. AAA gaming studios are famous for not using git due to git's poor handling of large binary assets w/o workarounds.

I've used other source control systems and they do have benefits over Git to be sure. Access control is a huge one, you can have a large repository and have fine grained access control over who can access what paths in the repository. Heck with some source control systems this access control may even integrate with Active Directory, so there is only 1 account to maintain!

The way to do that with git is to have a lot of tiny repos, with all the advantages and disadvantages that brings.

Don't get me wrong, git's ability to easily branch is huge. I am totally over working in source control systems that required an admin to approve creating a branch, or where merging branches was a huge deal that could take a very long time to do, but git isn't the end all be all of source control systems, and there are certainly features from other systems that I miss when using git.

Game dev always seemed like a highly specialized thing to me. Performance critical, uses real math, lots of local instead of just server work, art assets...

I'm not saying everyone uses git, but it seems like there's probably not many people who have never had to learn it.

Especially when "knowing git" often means memorizing about 8 commands total if you're not on really big team.

When I pushed for a transition from no VCS at all to git, we couldn't use branches at first for fear that someone would need to access something and not be able to, if someone who actually knew git wasn't around.

Maybe their idea of "Can't use git" means "Can't use it well?"

I mean, a lot (most?) of the largest companies in software don't use it primarily. That being said, I agree that "knowing" git enough to for daily use is picked up very quickly. Your day to day usage of git is I'd say, medium complexity for source control. I've used tools where even cloning the repo could be a hassle, and there were nearly as many footguns as git, without reflog to recover.

Regarding large binary assets, I literally Googled "git large binary assets" and had many hits with various solutions. GitHub started offering Git LFS (Large File Storage) in 2015 -- more than 6 years ago. That said, many places still use Perforce.

It's newish (yes, 6 years is newish for projects that don't have a lot more hours, direction, and dedicated drive behind them than git-lfs seems to) and janky or unintuitive in some cases and adds another obtuse nerdy thing for e.g. artists to figure out (or be supported through) and requires extra software and server config to self-host (most of which is, uh, not as complete as one might hope) and makes backups less dead-simple than plain git and has nothing like an official server-side implementation (last I checked GH's "don't use this for production" implementation was the closest thing) and can make any kind of automation or extra tooling used with git a real pain since much of it's not lfs-aware, including some built-in git commands in certain situations (git-archive against a bare repo, for instance, which can be a super handy command in many situations).

Overall, I like it and have promoted its use and stand by that, but not every place has the time or inclination to screw around with it when they can just pay for something that solves the problem (likely Perforce).

While we're at it, git in general would be one fuck of a lot easier to support for cross-platform users and in tooling for complex projects if libgit2 caught up and took over as the official implementation. The pile-of-binaries-and-shell-and-god-knows-what-else (all living on top of a hacky, huge bundle of junk, on Windows) official Git itself is a huge impediment to doing anything with git other than just executing "git [command]" in Unixy environments. It'd also make "build my own GitHub" type projects far more tractable, cutting out some of GitHub's (and GitLab, et c.) server-side moat.

LFS is a pain, right now, even 6 years in, if you don't tie yourself to a major commercial Git host or put in a lot more effort than traditional self-hosting git requires. To reiterate: I still like and advocate it, circumstances allowing, but it definitely is not a mature solution.

I also think a lot of people in this thread don't understand that large companies don't want everyone having even read access to the entire repo.

Using a system like perforce, artists can drop files in the assets part of the repo, translators can have access to script files, and coders can have access to the parts of the code that they are working on.

Source code licenses are still a thing, where after buying a license only a certain # of people in a company are even allowed to view the licensed source code.

The way this is worked around is a build server exists where some pre-built libraries are pulled from during a developer's local machine build.

While I'm happy to no longer be working in that environment, it is unfortunate that many of the commenters cannot imagine an ecosystem different than their day to day. :/

Or use an IDE that has all that build in.