3: Give a script the same name as a Unix command
Never. Creating a script that has the same name as a Unix command can lead to some very odd effects. This is one of the reasons why some Unix admins will give their scripts file extensions like .sh or .pl. It means that, even if we're unaware that there's a Unix command named mknod, we won't end up with a script named mknod and find that it's been run by mistake. If ever in doubt, we can ask the system which mknod or man mknod to verify that we're not about to use a name we shouldn't.
4: Set the root password on a critical server to some variation of root (e.g., r00t) or password (e.g., pa55w0rd)
No way we Unix admins will ever use a "stupid" password, even when we're setting up a system that we're about to pass over to someone else to administer. We're more likely to use one that you wouldn't remember ten seconds after we told it to you.
5: Issue a rm * account without checking where we are in the file system
Unix admins are fully aware of the power of root. We've come around to issuing commands like rm * only after we have verified that we're running the command from the proper directory. And, if we're logged into more than one system at a time -- as I often am, we also verify that we're issuing the command on the proper system. A few seconds of hesitation before pressing the return key can save us hours of time and months of embarrassment, so we make that hesitation a part of our routine any time we're about to enter a command that, under the wrong conditions, could lead to disaster.
6: Run a command without knowing what it's supposed to do
It's tempting at times. We run into a problem, Google to see if others have seen the same errors or the same strange results, and then find an alleged solution that purports to return our system to a state of OS Nirvana. Even so, we're cautious and distrustful by nature. So we make sure that we understand what the proposed solution actually does and any potential side effects before we risk our troubled system to further chaos.
7: Delete an account without knowing what it's for
Removing an account and related directory without verifying what it's intended to be used for could end up causing more problems than would ignoring the account. Unix sysadmins have come to understand that many Unix accounts are essential for various services and applications and that, were we to remove one simply because no one's logged into it all year or because it looks strange, we could break something important. A good rule of thumb that we use is to annotate these accounts in the "gecos" (description) field in the /etc/passwd file so that the purpose for these accounts is recorded.
We also don't generally remove user accounts without some reassurance that they are no longer needed. Even if a Unix user left the company last month, there may still be files in his/her home directory that are still needed and should maybe be made available to someone else still on staff. We know and take advantage of the difference between deleting an account and disabling an account and use the latter whenever there is any question about whether the files in the ex-user's home directory are of value.
8: Ignore our log files
Unix admins know that most of the data that ends up in log files on Unix systems is routine and boring. At the same time, we never forget that log files are one of the first places to look for clues when something goes wrong on one of our systems. One of my favorite knee jerk reactions when something isn't quite right on one of the servers I manage is to cd down to /var/log and do an ls -ltr. This quickly shows me where the most recent log messages have gone. Then I tail those files and see if there's anything there that helps me to understand the nature of whatever is going wrong. The tail -f or tail --follow command can help with ongoing problems as it show us as messages are being added to our log files.