It is my guess that the text also consciously alludes to Goethe's "Sorcerer's Apprentice" (https://en.wikipedia.org/wiki/The_Sorcerer%27s_Apprentice) - and not just to Harry Potter. Instead of the word "incantation", in many cases I would rather use "Pavlovian conditioning" or "Maslow's law of the hammer" to describe the situation, because there is a lack of basic understanding of the context and people just react ad hoc with a routine. (i.e. if you only have a hammer, all problems will suddenly look like nails). I have observed this with some colleagues, for whom a problem is often solved with a restart of an application server or VM. This is the same "CTRL+ALT+DEL" reflex that every Windows user knows. Frankly, if you are under time or management pressure, the desire for a simple standard solution is understandable. However, this often obscures the traces that could lead to a sustainable solution of the problem. In other words, you don't take the time to analyse system processes and memory usage, create thread dumps or look for network sockets or DB connections.
To go back to your previous article on interview questions, the specific answer to 'rm -- -f' tells me nothing about the applicant's basic understanding of inter-system relationships. The incantation might work under certain conditions. The alternative, which would have told me more about understanding system context, would have been to use inode IDs for deletion instead. And this could then have been followed by the question of what inodes actually are, what they represent and what restrictions apply to inodes.
Many years ago I had the same problem when a developer colleague generated garbage files with non-printable characters in the filenames in the $HOME directory of a service account. Actually, that's the more general case of the problem in your question. Because I could not have entered the file names themselves on the command line at all. But I could enter the corresponding inode numbers.
When I interview candidates for tech jobs, instead of asking about "incantations", I try to ask about solution strategies for problems that have happened to me or my colleagues in their day-to-day work.
Often there is not one clear solution, but you have to successively go through several different alternative root causes. I then ask the candidate about the tools they would use for this and why they would use them. (The exact parameters are less important to me, as you can look them up in the man pages, for example. Nobody can know hundreds or thousands of obscure parameters that are only useful under certain conditions). If you can rule out one of the possible causes of the error with reasonable probability based on the evidence, you move on to the next most probable cause. And so on. In this way, I can see whether the candidate has experience in troubleshooting, whether they know the most important tools and whether they understand logical connections. In my opinion, this is more informative than having them spit out memorised boilerplate solutions.
So on the topic of incantations, wasn't that how medieval cathedrals were built? The Masons didn't know why certain structures worked, they didn't model them on a computer or even with a slide rule, they knew what had worked before and innovated around that. If they innovated too far, the building fell down, which was probably bad for the Mason. They portrayed this as secret knowledge but was it really just incantations?
Timely. https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1471880-systemd-256-1-fixes-systemd-tmpfiles-unexpectedly-deleting-your-home-directory#post1471891
Wow!
It is my guess that the text also consciously alludes to Goethe's "Sorcerer's Apprentice" (https://en.wikipedia.org/wiki/The_Sorcerer%27s_Apprentice) - and not just to Harry Potter. Instead of the word "incantation", in many cases I would rather use "Pavlovian conditioning" or "Maslow's law of the hammer" to describe the situation, because there is a lack of basic understanding of the context and people just react ad hoc with a routine. (i.e. if you only have a hammer, all problems will suddenly look like nails). I have observed this with some colleagues, for whom a problem is often solved with a restart of an application server or VM. This is the same "CTRL+ALT+DEL" reflex that every Windows user knows. Frankly, if you are under time or management pressure, the desire for a simple standard solution is understandable. However, this often obscures the traces that could lead to a sustainable solution of the problem. In other words, you don't take the time to analyse system processes and memory usage, create thread dumps or look for network sockets or DB connections.
To go back to your previous article on interview questions, the specific answer to 'rm -- -f' tells me nothing about the applicant's basic understanding of inter-system relationships. The incantation might work under certain conditions. The alternative, which would have told me more about understanding system context, would have been to use inode IDs for deletion instead. And this could then have been followed by the question of what inodes actually are, what they represent and what restrictions apply to inodes.
######################################################
~ $ 𝚖𝚔𝚍𝚒𝚛 𝙸𝙽𝚃𝙴𝚁𝚅𝙸𝙴𝚆
~ $ 𝚌𝚍 𝙸𝙽𝚃𝙴𝚁𝚅𝙸𝙴𝚆/
~/𝙸𝙽𝚃𝙴𝚁𝚅𝙸𝙴𝚆 $ > '--'
~/𝙸𝙽𝚃𝙴𝚁𝚅𝙸𝙴𝚆 $ 𝚕𝚜 -𝚕𝚒
total 𝟶
𝟷𝟺𝟺𝟺𝟺𝟽𝟾𝟶 -𝚛𝚠-𝚛--𝚛-- 𝟷 𝚖𝚊𝚛𝚔𝚞𝚜 𝚖𝚊𝚛𝚔𝚞𝚜 𝟶 𝟷𝟷. 𝙹𝚞𝚗 𝟸𝟶:𝟶𝟺 --
~/𝙸𝙽𝚃𝙴𝚁𝚅𝙸𝙴𝚆 $ 𝚏𝚒𝚗𝚍 /𝚑𝚘𝚖𝚎/𝚖𝚊𝚛𝚔𝚞𝚜/𝙸𝙽𝚃𝙴𝚁𝚅𝙸𝙴𝚆 -𝚖𝚒𝚗𝚍𝚎𝚙𝚝𝚑 𝟷 -𝚖𝚊𝚡𝚍𝚎𝚙𝚝𝚑 𝟷 -𝚒𝚗𝚞𝚖 𝟷𝟺𝟺𝟺𝟺𝟽𝟾𝟶 -𝚎𝚡𝚎𝚌 𝚛𝚖 -𝚒 {} \;
rm: remove regular empty file '`'/𝚑𝚘𝚖𝚎/𝚖𝚊𝚛𝚔𝚞𝚜/𝙸𝙽𝚃𝙴𝚁𝚅𝙸𝙴𝚆/--'? yes
######################################################
Many years ago I had the same problem when a developer colleague generated garbage files with non-printable characters in the filenames in the $HOME directory of a service account. Actually, that's the more general case of the problem in your question. Because I could not have entered the file names themselves on the command line at all. But I could enter the corresponding inode numbers.
When I interview candidates for tech jobs, instead of asking about "incantations", I try to ask about solution strategies for problems that have happened to me or my colleagues in their day-to-day work.
Often there is not one clear solution, but you have to successively go through several different alternative root causes. I then ask the candidate about the tools they would use for this and why they would use them. (The exact parameters are less important to me, as you can look them up in the man pages, for example. Nobody can know hundreds or thousands of obscure parameters that are only useful under certain conditions). If you can rule out one of the possible causes of the error with reasonable probability based on the evidence, you move on to the next most probable cause. And so on. In this way, I can see whether the candidate has experience in troubleshooting, whether they know the most important tools and whether they understand logical connections. In my opinion, this is more informative than having them spit out memorised boilerplate solutions.
So on the topic of incantations, wasn't that how medieval cathedrals were built? The Masons didn't know why certain structures worked, they didn't model them on a computer or even with a slide rule, they knew what had worked before and innovated around that. If they innovated too far, the building fell down, which was probably bad for the Mason. They portrayed this as secret knowledge but was it really just incantations?