Hacker News new | ask | show | jobs
by preconsider 4172 days ago
To those name-calling the author of the script:

The product/update is hyped and the release date is set in stone. Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals.

A last-minute showstopper bug comes in, caused by file leaks. Everyone is scrambling, and the file belongs to you so its on you to fix it alone. There is no time for code review, and delaying isn't an option (so says management). "I'm afraid if we keep seeing these delays in your components, we might have to consider rehiring your position".

The rm rf works -- it's a little bit scary, but it works. You write a test case, and everything passes. Still, you add the "scary" line for good measure. You have two more bugs for fix today and you'll be lucky if you're home by midnight and see your wife or kids. You've been stuck in the office and haven't seen them in days.

Are you an "idiot", "talentless" engineer that "deserves to have his software engineering license permanently revoked"? How do you know this wasn't the genesis of this line of code?

7 comments

Yes, that person is still an unprofessional idiot.

If a doctor accidentally removes the wrong organ because administrators have overscheduled him, "whoopsie, not my fault" is not the appropriate answer. The same applies to engineers working on bridges. Professionals take responsibility for their working conditions.

There is an enormous shortage of programmers right now. Anybody shipping stuff that is bad or dangerous is choosing that. If we drop our professional standards the moment a boss makes a sadface, then we're not professionals.

It's hard to be professional if no one wants or values it but you. The word your manager would use is "obstinate."

If they have not internalized the consequences of the risks they're asking their subordinates to take, they'll weigh what look like vague misgivings about "mumble, should be better, dangerous, blah blah" against the better understood risk of their bonus disappearing if the product doesn't ship on time.

Even if you choose to sacrifice yourself, your reputation, and your future prospects--again, if almost no employer in your industry would value what you call professionalism over short-term profits--someone else will ship the code you wouldn't.

That isn't a defense of anything; it's just a fact. Taboos (e.g. against bad code) don't work if they're not shared by the majority.

Sure, you can tell yourself that, and it will remain true. Or you can act like a professional and seek out places that value that. I have, and know others who do. I don't think we've sacrificed anything.
> If a doctor accidentally removes the wrong organ

Incidentally, that sort of thing does happen sometimes.

http://www.cnn.com/2010/HEALTH/10/18/health.surgery.mixups.c...

Agreed 100%. The number of people defending the author(s) of the code or saying the user should have backed up their data is disturbing. This isn't about protecting programmers' egos, it's about not deleting users' data.
So I guess it's a choice between getting fired for not meeting a deadline, and getting fired for destroying customer data.

I'd rather take the first option. At least my reputation will still be somewhat intact.

And as a bonus, I can get out of that hostile environment earlier.

> I'd rather take the first option. At least my reputation will still be somewhat intact.

I'd take the same option, but for different reasons: the customer's data. Only pictures of e.g. a deceased wife, no backup, and you just deleted them. You can arm-wave all you like about backing up, but you deleted them.

Dude, I am already stressed when hitting big red buttons in production, and from now on I can imagine the possibility of erasing unrecoverable memories about lost loved ones... This profession is tough on the most unexpected levels.
If you want more nightmare fuel (or just want to see various ways technology goes wrong), check out http://catless.ncl.ac.uk/Risks .
The choice is between definitely getting fired and maybe someone's data getting deleted.
This.

This is the reality of corporate development. I think we should be demanding more before buying software from vendors, especially when you can't just whip out the source code to audit or fix yourself.

Suff like this doesn't have to happen, but we let it.

> Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals.

Valve doesn't have bosses, remember?

Except of course they actually do. It'll just take you half a year to figure out who they are.
Totally agreed but isn't Valve a company famous for not having all that corporate deadline stuff?
but the same wouldnt be acceptable in other lines of work right? Try a civil engineer or surgeon... what would you expect someone to do in similar situations? Probably escalate the issue and perhaps delay the release.

Pushing in shitty broken means you're not doing your job. If your company forces you to do this then they are not doing their job.

How do you know it was?