On thing I’ve seen in almost every company that I’ve worked for is trial and error coding. This is where people memorize a bunch of changes to make or commands to run and then use those blindly, praying that it will fix the problem they are facing.
Like the linked article says, you could argue that this follows the scientific method:
We form a hypothesis: “maybe running command X or making change Y will fix my issue”
Perform an experiment: “Run command X or make change Y”
Observe the results: “it fixed or did not fix the problem”
Repeat until fixed.
Unfortunately it’s not particularly effective because the “hypothesis” we’re forming is not based on reasoning and deduction, it’s based on guesswork. We see something unexpected happen and instead of looking at that something and forming reasonable hypotheses about it, we just jump to some conclusion and wing it. This is not engineering; or at least not a form of engineering that will get anything done in a reasonable amount of time.
To make this more scientific, you want to make two changes:
When forming your hypothesis, you want to use some sort of educated deduction: “I think running command X or making change Y will fix my issue because…”. Saying “it worked last time I did it” isn’t great; “it worked last time because of this, and I have reason to believe I’m in a similar situation now” is perfectly acceptable.
When seeing the results, you want to understand why you’re getting those results - both when it worked and when it didn’t. This will help you improve your educated deductions in step 1.
Sure, there are times that trial and error or shots in the dark really are an approach to take. But I’ve found that far more often, engineers are doing trial and error because they don’t really understand how their tools or their system works. Spending a little bit of time looking under the hood goes a long way in improving your effectiveness.