Are there any good reasons to use multiple GitHub user accounts? GitHub organization membership and permissions are well designed in my experience, negating the need for multiple user accounts.
Consultants or professional services folks will be working in their company’s GitHub account and several clients. Requires managing lots of git/GitHub accounts
Even with enterprise SSO, the initial connect to GH can (is typically) "you" (just as you have the same driver license to show at the front desk when registering to visit a secured firm or random hotel), then you elevate "you" into the org through SSO, and what policies apply to you via your org can be 'governed' at the enterprise.
The idea behind this model is that no, you don't have to manage lots of those as you, you're just you, and each of those you aim to use has an elevation that entity controls instead of you controlling it.
This ultimately results in way less key material floating around, and you losing, leaking, or lousing up your own GH cred doesn't auto-give an attacker the SSO elevation.
• • •
Not incidentally, I have a slew of "accounts" given to me by companies that don't bother to make an org, they just invite individuals to repos or make individual accounts for their repo. I suppose it's cheaper in the short run. In the long run, these accounts are 90% still left active years to (no kidding) decade+ later. Seems a better idea to "don't do this." If you're a company, be an org.
> Are there any good reasons to use multiple GitHub user accounts?
Is there any good reasons not to separate what you work on into multiple GitHub accounts? Not to mention some people don't want all their projects attached to one profile, some people also develop in their free-time, and don't want to mix freetime/work projects under the same user account, for multiple reasons.
I use a pseudonym during my free time, so yes. Also my employer is requiring us to use company-specific GitHub accounts, so the decision is out of my hands anyway.
> There's no reason for getting vouched to be difficult. The primary thing Vouch prevents is low-effort drive-by contributions. For my projects (even this one), you can get vouched by simply introducing yourself in an issue and describing how you'd like to contribute.
This just requires one more prompt for your prose/code generator:
"Computer, introduce yourself like a normal human in an issue and wait to be vouched before opening pull request."
We already have a "user agent" as a term for software (browsers, curl, etc.) that fetches web content on behalf of a user. It predates current AI agents by a few decades. I don't think it has much agency either, but here we are (were?).
As for anthropomorphizing software - we've been doing it for a long time. We have software that reads and writes data. Originally those were things that only humans did. But over time these words gained another meaning.
If you don't think code generators are useful, that's fine.
I think code generators are useful, but that one of the trade-offs of using them is that it encourages people to anthropomorphize the software because they are also prose generators. I'm arguing that these two functions don't necessarily need to be bundled.
If you can answer these questions, you can estimate using a confidence interval.
If the estimate is too wide, break it down into smaller chunks, and re-estimate.
If you can't break it down further, decide whether it's worth spending time to gather information needed to narrow the estimate or break it down. If not, scrap the project.
I prefer 1 hour/1 day/etc but yes, this is the only method that I’ve found to work. Be very clear what result you’re trying to produce, spec out the idea in detail, break down the spec into logical steps, use orders of magnitude to break down each step. There’s your estimate. If you can’t break it down enough to get into the 1 day/1 week range per step, you don’t actually have a plan and can’t produce a realistic estimate
What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.
Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works.
On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period.
So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?
Yes, this is basically what happens. Except sometimes there's no realistic way to narrow the estimate. In research-focused teams you don't "scrap" a project that you can't break down. Instead you need to have a way to manage wide estimate windows.
The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(
This why you should use confidence intervals for estimates. Use a 80% confidence interval, for example. 10% of the time, you should come in under the best case estimate. 10% of the time, it should take longer than the worst case estimate.
How do you know if your estimate is good? Would you rather bet on your estimate or on hitting one of 8 numbers on a 10-number roulette wheel? If you prefer one of the bets, adjust your estimates. If you're indifferent between the bets, the estimates accurately reflect your beliefs.
That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month!
When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.
It really depends. Anyone doing meaningful work will have hard time giving estimates.
But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.
You are correct, comparing making the next CRUD application to reinventing the spreadsheet was supposed to be a slightly humorous way to describe the repetitive and not too challenging part of writing business applications.
There also are people who use software to guide space rockets, cars, optimise calculation algorithms and more.
My guess is people with background mostly in CRUD don't get how everybody else messes up estimating so badly and people in the innovative task group find it hard to believe sane people would waste their time giving any estimates other than for technically irrelevant business reasons.
It's like having Michael Jordan with dementia on your team. You start out mesmerized by how many points he can score, and then you get incredibly frustrated that he forgets he has to dribble and shoot into the correct hoop.
When I went to the DMV and couldn't pass the vision test without my glasses, they put on my driver's license an indication that I only passed with the accommodation of corrective lenses.
redo[1] with shell scripts has become my goto method of dealing with multi-step data problems. It makes it easy to review each step of data retrieval, clean-up, transformation, etc.
I use mlr, sqlite, rye, souffle, and goawk in the shell scripts, and visidata to interactively review the intermediate files.
