[jlewi]

Being able to review a command isn't the same as being able to author that command without errors. An obvious example is queries (e.g. SQL or Cloud Logging). I can easily know enough to be able to review them and decide a query is safe. That doesn't mean I can easily remember the precise syntax that each tool/system requires.

[JTyQZSnP3cQGa8B]

Is there a difference with a set of scripts that have been carefully reviewed and approved? Those scripts can have parameters, and use authentication to handle the different scenarios.

If a scenario is new, the sysadmins should handle that by changing the scripts or hide it in the CI. Again: approved and reviewed.

And if it hasn’t been approved AND you don’t know what you’re doing, you shouldn’t experiment on the infrastructure of the company and let professionals do their job. I don’t see the added value of Foyle here.

Also:

> As developers today, we often know what we need to do but struggle with the how

It’s false. I struggle with what I need to do, and that’s why I talk to product owners, bosses, architects, and employees. Once everything has been clearly defined, the solution is easier to implement. Engineering is about understanding what needs to be done and that’s the hard part.

[jlewi]

> Is there a difference with a set of scripts that have been carefully reviewed and approved

I think Foyle is complementary. Creating a script/tool/higher level abstraction is valuable when you do the same exact task over and over. This is creating a so called "paved path". However, paved paths often limit flexibility. To optimize flexibility we often divide a task into composable tool chains. Foyle can help you compose these chains. So it can help you in instances where it doesn't make sense to create a bespoke tool because it wouldn't be used frequently enough.

(I'm the creator of Foyle)

[from-nibly]

What's the difference between someone who can review a command and someone who can't? How do you know you have reached that point?