Every ops team has some manual procedures that they haven’t gotten around to automating yet. Toil can never be totally eliminated. Very often, the biggest toil center for a team at a growing …
Yeah, I’m really wondering why they thought this was a good idea. My best guess is that they want to keep everything within one file, since it makes the script easier to deal with. But when automation actually starts being implemented, they want the functions for each task to be grouped (and I believe, Python doesn’t support inline modules), so they abuse classes for that…?
Well, and I guess, it allows them to have pseudo-constants within each task, which don’t need to be explicitly passed around between functions.
But yeah, really not a fan of needing this much boilerplate to start out with. In my opinion, the activation energy required to use this pattern instead of slapping down documentation needs to be as minimal as possible, otherwise folks will slap down documentation instead.
I would very much argue that you shouldn’t add complexity unless you actually make us of it. Them all using a uniform structure doesn’t help readability nearly as much as just not having the complexity…
"grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience
sometimes grug go too early and get abstractions wrong, so grug bias towards waiting
big brain developers often not like this at all and invent many abstractions start of project
grug tempted to reach for club and yell “big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!”
I have nothing to add except: man’s really wrote like 7 classes to just have 1 function each
That is what makes it Enterprise-grade!
Honestly, if they want to go full enterprise at least use the javabeanfactoryfactoryfactory pattern
Yeah, I’m really wondering why they thought this was a good idea. My best guess is that they want to keep everything within one file, since it makes the script easier to deal with. But when automation actually starts being implemented, they want the functions for each task to be grouped (and I believe, Python doesn’t support inline modules), so they
abuse classes for that…?Well, and I guess, it allows them to have pseudo-constants within each task, which don’t need to be explicitly passed around between functions.
But yeah, really not a fan of needing this much boilerplate to start out with. In my opinion, the activation energy required to use this pattern instead of slapping down documentation needs to be as minimal as possible, otherwise folks will slap down documentation instead.
It’s probably to allow for added complexity as they expand on each task. Makes it simpler to import elsewhere too.
I would very much argue that you shouldn’t add complexity unless you actually make us of it. Them all using a uniform structure doesn’t help readability nearly as much as just not having the complexity…
"grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience
sometimes grug go too early and get abstractions wrong, so grug bias towards waiting
big brain developers often not like this at all and invent many abstractions start of project
grug tempted to reach for club and yell “big brain no maintain code! big brain move on next architecture committee leave code for grug deal with!”
https://grugbrain.dev/