Boardroom Miscellaneous Thread

Drizzt321

Ars Legatus Legionis
29,639
Subscriptor++
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.
 
Last edited:
  • Hug
Reactions: Scotttheking

Scotttheking

Ars Legatus Legionis
11,580
Subscriptor++
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.
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?
 
  • Like
Reactions: pasorrijer

Drizzt321

Ars Legatus Legionis
29,639
Subscriptor++
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?
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.
 

hanser

Ars Legatus Legionis
41,956
Subscriptor++
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.
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. :p
 

Drizzt321

Ars Legatus Legionis
29,639
Subscriptor++
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. :p
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".
 

Scotttheking

Ars Legatus Legionis
11,580
Subscriptor++
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.
I’ve dealt with worse.
Pay me $2k plus expenses to come sit in your office for an afternoon and work out a path forward, then we can go for tacos after. 😃
 

ramases

Ars Tribunus Angusticlavius
7,849
Subscriptor++
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".

1) come up with your own policy proposals
2) present them for both general and specific feedback to your manager
3) get him to sign off on the policies. Make sure it is formally not Drizzt's Policy but Manager's Policy

It is far from ideal, and especially initially a lot of what enforcement there needs to be will need to be done with soft power (ie persuasion).

But absent a personal change or getting someone in from outside this is the only way you will get something similar to what you want.
 
  • Like
Reactions: Scotttheking