The people that live at the edge of the everglades are long tail even on the Floridian scale.I feel like there should be a Florida Man joke here somewhere..
The people that live at the edge of the everglades are long tail even on the Floridian scale.I feel like there should be a Florida Man joke here somewhere..
That’s silly.I'm getting kinda annoyed at this technical manager guy. "I don't want to limit what's best for your development, do minimal permissions needed for your work". Ok, fine, but...some recommended/suggested examples? How about some written general policy/"try and do things this way"? How about recommended access token permissions/expiration/etc?
sigh FFS, this is NOT maturing our development processes.
EDIT: Oh yeah, and apparently the fine grained access tokens (Github) are not enabled on the organization? So only classic tokens are supported. But when I asked the question, he said use fine grained. And is very much "you're smart, you go figure it out". Dammit, you sprung switching from svn to github on us overnight, and YOU'RE the one supposed to be setting some policy, so F@J#@$J set some policy and guidelines (I appreciate not having to be super strict about them though, as he's stated) about security & usage & naming conventions/etc.
Heh, yeah. I think the problem is we have a bit of a fragmented team. Some (most) working on newer stuff, that already was on github and on newer systems/setups that keeps things up to date, and our primary codebase that (was) on subversion and is >14 years old and has so much cruft hasn't had any libs or anything updated in years and years and years. At least we have a decent integration test suite, but no unit tests or anything that's actually working.That’s silly.
A good (automated) dev process helps go faster, speeds onboarding of new devs, preserves institutional knowledge, makes experimentation easier, enables responding quickly to major issues, and provides for a level of disaster recovery.
It doesn’t “limit what’s best for your development.”
Why yes, I have strong opinions here, what gave it away?
I have two thoughts:I'm getting kinda annoyed at this technical manager guy. "I don't want to limit what's best for your development, do minimal permissions needed for your work". Ok, fine, but...some recommended/suggested examples? How about some written general policy/"try and do things this way"? How about recommended access token permissions/expiration/etc?
sigh FFS, this is NOT maturing our development processes.
EDIT: Oh yeah, and apparently the fine grained access tokens (Github) are not enabled on the organization? So only classic tokens are supported. But when I asked the question, he said use fine grained. And is very much "you're smart, you go figure it out". Dammit, you sprung switching from svn to github on us overnight, and YOU'RE the one supposed to be setting some policy, so F@J#@$J set some policy and guidelines (I appreciate not having to be super strict about them though, as he's stated) about security & usage & naming conventions/etc.
1) Nope, he's done this before at other companies, but probably with less....arcane old code base.I have two thoughts:
1) this person has never done the work before which is why they’re not being more specific.
2) no one should feel like an svn to git migration is sprung on them because I feel like it should be expected? git has been mainstream for over a decade at this point. It’s like being surprised when internet explorer is replace with chrome.
I’ve dealt with worse.Heh, yeah. I think the problem is we have a bit of a fragmented team. Some (most) working on newer stuff, that already was on github and on newer systems/setups that keeps things up to date, and our primary codebase that (was) on subversion and is >14 years old and has so much cruft hasn't had any libs or anything updated in years and years and years. At least we have a decent integration test suite, but no unit tests or anything that's actually working.
1) Nope, he's done this before at other companies, but probably with less....arcane old code base.
2) I knew it was coming at some point in time. I woke up to an email saying "we've migrated to github, start using github". Which is not how it should go. It should have been an email "we're moving to github, expected to be X date, so check in your code before that".