It's not. "Generalising" means taking an individual observation, and drawing conclusions about all cases (or a large class of cases). I think you're saying that "I'm not unusual" is a canonical example of generalization, i.e. claiming that my case applies to a large class. But I didn't make that claim.
It's possible that my observation was wrong - that I am unusual. But that would mean that the majority of my recent colleagues were also unusual, because I don't think more than a tiny fraction of them had Github accounts.
Given a specimen case, and absent evidence to the contrary, it's a mistake to suppose that specimen case is unique or unusual. It's much more likely to be common. And if you discover similar cases, then it's definitely not unique, and unlikely to be unusual.
But I think this is litigious point-scoring; I say that having a Github account is not a good discriminator for "software developer". If you disagree, please explain why, instead of claiming that I contradicted myself by saying I wasn't generalising in a post that contained a "blatant generalisation".
[Note: I'm a brit, trying to transition gracefully from "-ise" to "-ize"; I'm having trouble internali[zs]ing the rules.]
[Edit] Just noticed that the commenters above that seem to agree that I'm unusual, are all different commenters. I'm puzzled that people think I'm unusual, even to the point of asking about the work I do/did. But the sub-conversation is about Github; I presume that most of these commenters is a Github user, who works in Githubby environments, and so is exposed to a lot of Github users.
I'm really not very unusual; I'm just an opinionated graybeard old-fart software geek, like a lot of us. We all have strong opinions about what software we're prepared to try to cooperate with.
I found git over-complicated, and Github quickly became like a cross between LinkedIn and a sort of Facebook for coders. I never trusted it at all.
I was born in 93. In 2000s all of my then web-deving with html/php was without even an awareness of something like version control. I was storing snippets of code in .txt files in case my change (often made directly on the FTP server) was to crash everything. Of course, this was just a hobbyist environment, I was a teen running some small personal communities. Then, I stopped programming for years and when returned around 5 years ago `git` was basically everywhere. Now, after working in "professional environment" with software development, I don't imagine running any project without some version control when more than 1 person is involved.
What were you using for version control, how did that work between programmers committing to the same new feature?
I started with CVS. I had been aware of sccs from an early Unix training course, so I knew how diffs worked, but I never used a VCS until I needed CVS. Later I switched to Subversion, which I think is pretty good, for my use-cases. Subversion flags a conflict if your commit against rev1.1 is submitted after another commit to the same file, but against rev1.2. You have to figure it out yourself, or grab rev1.2 and redo your changes. Git has lovely features for dealing with conflicts, much better that Subversion. But in practice, in a team of (say) three working on a feature, and communicating well, conflicts are rare, and easily resolved.
I should have been using revision control since the early days, of course; but I don't think many of us did - it required more storage, and floppy disks weren't cheap.
[Edit] Perhaps I should note that for a time, I had to work with Microsoft's Visual Sourcesafe, over Frame Delay, to a repository across the Atlantic. Those were bad times.