I had something similar to that with Power BI DAX where the same “intuitive” structure (a table definition) had different syntax for two similar purposes.

The inline table constructor for a single column table is {value, value, ...}, with the column just named “value”. The constructor for a multi-column table is {(value, value, ...), (value, value, ...), ...}, and the columns are named “value1”, “value2” and so on.

The function DATATABLE allows both specifying the column names and types for the data. The syntax for the data argument is {{value, value, ...}, ...}.

If you can spot the difference, you will have figured out why simply transplanting my constructor into a DATATABLE didn’t work, but copying an example and replacing the values one by one did. It took me way too long.

Maybe you just missed some nuance your brain skipped over?

Let me count the ways it has been for me… Capitalization, using -, not using -, wrong quotes, mismatched quotes, no quotes, reading the command the same wrong way about five times and typing it that way. Well this could take forever to list them all.

I just copy paste first now. That way I learn none of the commands or syntax at all

Been there, found undefined behavior where there should not be any. Imagine a function that takes a bool param with the following code, but neither branch gets executed:

if (b)
   doStuffForTrue();
if (!b)
   doStuffForFalse();

In a function that is passed an uninitialized bool parameter, in gcc compiler, both branches can get executed even when b is const. Reason: uninitialized bool in gcc can have values of a random integer, and while if(b) {} else ({} is guaranteed to execute only one branch, bool evaluations of a bool value take a “shortcut” that only has defined behavior with an initialized bool.

Same code with an uninitialized integer works as expected, btw.

I find myself saying this about 35 times a day, at nearly every turn, with about everything I interact with.