Live data from Hacker News

Count to ten when a plane goes down

johncbeck.tumblr.com

231–240 of 284 posts

Re: Count to ten when a plane goes down

#231
post #180

Earlier quoted context omitted.

Appropriate or not, it's probably what was to be expected in what I imagine even in 1981 was not the most enlightened HR management regime (the US foreign service). Also, 32 years is a lot of time to wash away the bitterness of having been unfairly fired from a summer job, especially if you, as the author, ended up doing pretty well for yourself. Also, whether or not it was appropriate is completely irrelevant to the…

I expect the HR management back then was more enlightened than it is now - the quick-to-pounce media and politically instigated witch hunts (terrorism, save-the-kids, etc.) have ensured that cover-your-ass is more and more a necessity.

That sounds like rose colored glasses. The cold war had its fair share of witch hunts. Granted this was the 80's not the 50's but lets not forget McCarthyism was based around democracy vs communism.

"That Korean announcement and the slow response by the US President—both caused by delayed real information—caused decades of conspiracy theories."

Re: Count to ten when a plane goes down

#232

The author states they felt it was appropriate when they were fired. In what world would it be appropriate to get fired for a single, simple, incredibly easy to make mistake? Doubly insane when there were exactly zero safeguards in place to prevent the mistake from being made.

According to his next post: What I didn’t say is that it was the last day of my summer internship. The next summer they invited me back again. Everyone understood it was a mistake, but by officially firing me, someone had been punished … :)

Makes sense (and is convenient). The people at the embassy had to have someone to blame, and report back to their superiors that they had dealt with the situation appropriately.

Re: Count to ten when a plane goes down

#234

Earlier quoted context omitted.

This was the American Embassy, which follows American work culture. Also, in Japanese companies, it's basically impossible to fire people. They can, however, be assigned to a desk in a windowless room and be given nothing to do for several years, until they take the hint and "voluntarily" quit.

The Japanese way is good in the sense that, as long as you have Internet, you could make your startup without worrying about putting a roof over your head or finding an office space to work from, and you get a still-full salary to bootstrap it without having to put the time. You even get access to a pool of other soon-to-available engineers to work with if you're stuck with other poor sods in the room. Definitely ano…

I highly doubt you are allowed to retain ownership of anything you create on the job though.

Re: Count to ten when a plane goes down

#235

Firstly, firing the intern doesn't make sense - it was a mistake waiting to happen and he just happened to do it at the wrong time. Secondly, the punishment meted out should be: 1. Proportional to the degree of carelessness (in this case not that much since he accidentally hit a wrong key adjacent to the right one, didn't mow down anybody while driving drunk) 2. Inversely proportional to the likelihood of the error (…

I think you're wrong to ignore the consequences of the actions as an input to the punishment. A small amount of unintentional carelessness that causes huge damage could still be punished. One could argue that a certain degree of mindfulness in critical situations is a job requirement, and casually making a careless -- though unintended -- mistake demonstrates a lack of mindfulness indicating that the person is not properly qualified for the job.

I understand that we don't want a culture that fires people for making the sort of mistake anyone might make. But to be so careless on a day that is clearly an exception where something more important than standard business procedure is going on, can't you at least see why firing the intern for such a lack of mindfulness might at least make sense, even if you disagree with it?

I interned for a government organization that maintains hydroelectric dams and the software that controls them throughout the Southeastern US. A careless mistake could -- in the worst case -- cause blackouts, cost the company millions of dollars, or even cost lives (if the data-control feedback loop caused a turbine to spin up at the wrong time or to fail to shut off in an emergency). And, as is quite common in organizations with non-software-engineers running the show, the development processes were entirely haphazard. The environment was such that it would be really easy for me to push unreviewed code, or to make a stupid deployment mistake, or to be careless in a number of ways that the system didn't protect me against.

But it was OK, because they hired smart, competent people who understand the need to triple-check, if necessary, before committing. People who understood the gravity of the situation, and who didn't phone it in if they weren't feeling it that day. If I demonstrated that I wasn't one of those people, I would fully expect to be fired.

Re: Count to ten when a plane goes down

#236

Earlier quoted context omitted.

The worst unix disaster I ever saw happened to one of my co-workers. He was working on a client machine, logged in as root because he needed to compile and install some complicated software. As he was working, he did an ls -l /bin and copy-pasted it to a text editor so he could make sure everything was installed correctly. Unfortunately, after returning to his console, he accidentally hit paste. Most of /bin was actu…

The worst unix disaster ever? Could you elaborate for non-unix people such as myself?

The important character here is the '>'. This redirects output to a file and overwrites the file. The lrwxrwxrwx will only print an error, but the redirect to the target executable will erase the target.

For example:

  $ echo "asdf" > foo
  $ cat foo
  asdf
  $ lrwxwrwxrwx 1 root root -> foo
  lrwxrwxrwx: command not found
  $ cat foo
  $
So basically, this zero'd out every executable on the system.

Re: Count to ten when a plane goes down

#237
post #36

Earlier quoted context omitted.

The world where you know you that a) you have an incredibly powerful key with no safeguards at your fingertips and b) you might be in a breaking news situation and nonetheless you go for the key right next to the dangerous one carelessly enough that you miss? Think about it: Unix is equally as "insane". If you're the guy on the console who meant to clean out some crap dir and accidentally typoed "rm -rf /" and then c…

But typing "rm -rf /" is significantly harder to do accidentally than typing F7 instead of F6.

Eh, "rm -rf $TEMPDIR/$TEMPFILE" in a shell script is just a couple typos away from deleting everything on the network. Yet I've seen people put crap like that in build scripts even after they've previously inadvertently deleted half the network drives.

Fortunately, despite rm's poor choice of options and bash's poor default handling of variable name typos and the obvious PEBKAC, backups saved the day here.

People are human. Policy ought to reflect this.

Re: Count to ten when a plane goes down

#238
post #202

Earlier quoted context omitted.

I run into this all the time, too. Now my -rf usage is almost always wrapped by this: rmgit() { git status read -p "Are you sure? " -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]] then rm .git -rf fi }

I think this would be a bit better for interactive cases. Note: written just now, I haven't actually felt the need for this safeguard... yet. rmrf() { (echo "The following files are going to be deleted!!!" for FILE in "$@"; do echo " >>" done) | less read -p "Are you sure? " -n 1 -r echo if [[ $REPLY =~ ^[Yy]$ ]] then rm -rf "$@" fi }

Doesn't help against network filesystems mounted in subdirectories. --one-file-system (which really ought to be the default) prevents this.

Re: Count to ten when a plane goes down

#239
post #54

Earlier quoted context omitted.

On any modern system it's actually "sudo rm -rf / --no-preserve-root" and then entering your password while staring at the command. "rm -rf ~/blue /" will not come close to deleting / unless you are in the habit of running every command as sudo, even ignoring the presence of --no-preserve-root

Except when: (these are terrible lessons to learn) 1. You type it into the wrong system (D'oh) 2. You have run `mount --bind / /somewhere/else` then `rm -rf /somewhere` a week later :(

It boggles my mind that --one-file-system is not the default :/

Re: Count to ten when a plane goes down

#240
post #167

Earlier quoted context omitted.

I never understood the rationale of "you made a mistake, so you're fired". By making a mistake, the employee has increased her value in that she will never make that mistake again. If you're going to replace the employee you have to pay to hire someone even better (to recoup costs of talent hunt, training) and someone who somehow won't make a typo. It just seems like a situation that is strictly worse than keeping th…

>>> By making a mistake, the employee has increased her value in that she will never make that mistake again This is a far-reaching conclusion. That assumes that a) no mistakes can be prevented before they happen for the first time and b) every mistake can be prevented after making it. The truth of either far from obvious. Moreover, it is routine in our culture that sever mistakes are punished - e.g. if you make a mi…

If you believe that you can find an employee that is more attentive or with more experience, and you are not laying off your employees right now to find those better employees, what the hell is going on? Are you just hanging out, basically sitting there knowing you have suboptimal employees, and eagerly waiting for them to fuck up so you have an excuse to axe them? You know your employees are (dun dun dun) capable of mistakes but it's expensive to lay them off so you're watching like a hawk for when you get to upgrade them?

The key difference here to me is mistakes vs negligence. Employee makes a typo -> It's a mistake. Not severe, negligent incompetence. It's a learning experience. The company is worse off by firing that person who has experience

If someone is slacking off? Yeah, fire them, that's not a mistake, that's negligence. You email a colleague in another time zone asking for help and they ignore you because you didn't CC their manager? Yeah, fucking fire that person.

I mean, in fact we have an industry based around the fact that people make mistakes: it's called software testing. Should we be firing developers when they make a mistake (i.e. their code has more than zero bugs)? That would be ridiculous. You're not even punishing them in that case - they're going to use their current salary at your shop to leverage a higher salary at the new place they (effortlessly) land at, whereas you're going to spend tens of thousands of dollars to hire that mythical developer that you should have fired this guy for a year ago?

Post reply on HN