there may be an issue with github TOS not allowing more than one free account per person though. i don't know if that is still the case, but then i would get a paid account for each paid gig and just add it to the bill.

it is: https://docs.github.com/en/site-policy/github-terms/github-t...

I've been trying to do more hobbyist work in public repos. It's not like there's a Greek chorus waiting to pounce on every mistake. Truth is, nobody cares.

It's freeing, in a way, because "I'll publish it when it's done" actually means "I'll never publish it at all".

I also find having some public activity on my gh to give me an ability to include it into the resume. It's a good conversation starter for many people from my experience.

-- There must be some throttling for heavy use. Otherwise it would explode.

I suspect spammers using GitHub to host their spam, as well as inaccurate geolocation e.g. due to VPN usage.

Looks like it spiked as high as 10% of all advertised jobs in 2022. Even though 80%+ of the UK economy is services I still find that impressive!

Remember, for most starting developers (which is almost all developers), a GitHub account is an essential part of their job search, just like having a LinkedIn account.

And then at a lot of companies you get a separate GitHub account because companies do not really want to deal with your personal account, they want to manage it to enforce 2fa, to be able to disable it when you leave (as if it mattered), and so on.

?

But you have take into account that ~37% of households in Brazil have no internet access or computer.

I would guess that less than 2% of Brazilian population even knows what GitHub is.

It stands to reason that Github would want to promote the notion that you can't be a real developer unless you're on Github.

You can't generalize from "number of Github accounts" to "number of developers".

> I doubt I'm unique, nor even unusual.

Yet, you do.

No, I don't. TBH, I don't really know what it would mean to generalize "I doubt I'm unique, nor even unusual". Would that be something like "I doubt anyone's unique, nor even unusual"? I certainly didn't say anything like that.

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.