The Joel on Software Discussion Group

Since I can't personally relate to many of the Rockstar programmer stories, I thought it would be nice to have a thread that includes stories about programming acts I actually have a chance of committing.

So, what's the stupidest programming related thing you've ever done?

Here's mine:

Back in school, I used to create a separate directory for every little assignment, work on the assignment, TAR up the source code, exe, and other files and put the TARball into a archive directory for safekeeping. So far, so good.

Anyway, I was working on an assignment, on the day before it was due (as usual). I had just finished my final test run when, for reasons that still elude me to this day, I typed:

"rm" -rf *.*

But wait, my stupidity reaches even more impressive heights. I used to use C shell in school. I'd lost work before to unintentional recursive deletion blunders and had aliased 'rm' to move the resulting files to a directory called .trash. I then had my logout script clean out that directory. By "quoting" the command I told the system not to use my nifty safety feature and everything was gone-gone.

I've never since had a moment where I  was so stunned. Absolutely unbelievably stupid.

It cost me another all-nighter to reproduce the work. The memory of that still makes me laugh today, though.

You did an rm -rf and only wiped out your own work.
You didn't take down an entire countries telecoms system or wipe out a high-street bank - sheesh you don't even make it to level 1 of stupid programmer tricks!

You might enjoy this web site: http://worsethanfailure.com/

Did a SQL 'delete from important_table where id in (select statement with a very unfortunate join mistake)'

learned to always do select count(1) from <whatever clause> to make sure the result is sane.

Also leared to do:
BEGIN TRAN
before the delete statement with ROLLBACK TRAN sitting handily nearby in case of emergency.

Also did a 'truncate table very_imporatant_table" thinking I was logged on to the development box when in actuality was on a production server.

Learned the value of good database backups that day.

About evacuated my bowels both times, though.

I don't fancy myself nearly as good or bullet-proof as I did before, so I suppose that is a plus as well.

I was experimenting with the shutdown script on a UNIX system.  It took me a few tries to get my version to work.  Finally, it did work.  It then occurred to me that the location that I put it in that was conveniently out of the way was *not* a good choice.

I put it in /tmp.  UNIX empties that directory on boot.

Sincerely,

Gene Wirchenko

I'm not into messing up my files.  My stupidity targets other's files.

Back on a Univac 1160 main frame I did an @asg,ar on a friend's "file" ("file is what Univac called a directory). I meant to type @asg,at.  The 'r' option tells Exec 8 to remove (delete) the file when you @free it or when you @fin.

Dang sys admin guy traced the logs and pointed at me.

Did I over-rev the wayback machine for you kids?

Once I was ssh'd into the production webserver (client was a large carmaker) doing something with a logging script. When I finished.. wait, what was the name of the shell script that shuts down the logging? Was it 'shutdown'? Yeah, that's probably what it was. Wait, why am I disconnected?

I created a custom float rounder for a formatter which was buggy. Luckily I found out before it caused much damage, replacing it with the platform's supported one.

I tried to create a common interface to several different GUI toolkits, making it easy to run the same program in any of them. I persisted on this mistake for a while. Nowadays I avoid GUI altogether.

I've created a custom translation library which works like "gettext" but has just a fraction of its support. I persist on this one.

For some of my GUI, I used a custom framework which made things more straightforward. But it meant that I didn't use methods a whole lot, only "functions with closures" (lambdas). I learned that it works great for a few tens of lines of code. But when it reaches a thousand lines, it tends to suck. One of the problems is that the order of the functions in the code matters, while with methods it usually doesn't matter. This one persists.

Another one is that acronyms work great when they are a few, but they tend to suck when they are everywhere. So naming modules CR, WR, TR, GR, tends to suck in the long run. I renamed them using "grep" which is supported i my editor. With one exception: JR in JavaScript because I need it there and it's the only one. :-) That's not to say that I have banned the one letter variables though. :-)

I embrace mistakes. :-) That's a mistake.

We were developing some software on a remote system on a hospital site. Logged in. As root with no password (because it was the only account information we'd been given); so we figured this was just a test machine that they'd allocated for us to play with.

Fiddled with some code for a while... and the machine rebooted.

Didn't quite believe it was my code that had crashed the thing that hard, so we wait for it to come back up, log in again, and run it again. And... yep. That's a kernel bug.


It was at this point we started getting phone calls. It turned out that this wasn't /just/ a development machine, but had several hundred people trying to run the hospital on it as well.

I'm not claiming full responsibility for this because userspace apps should not be able to get the kernel to fail like that[1], but I probably should have checked how many users there were before I considered crashing the machine a SECOND time...




[1] IBM refused to take the bug report, saying we had to talk to Bull, who sold the machine. They said we should to talk to Motorola who maintained the OS in the UK, and they said they knew nothing about this and we'd have to call IBM. So it didn't get fixed..

Only those that don't do anything don't make any mistakes. I expect my programmers to have bugs, and I expect my top developers to have more critical bugs simply because they work on more critical pieces of code. I don't penalize my developers for their bugs unless:
1. They didn't follow the rules, e.g. unauthorized check-in during code freeze
2. They wrote sub-par code
3. They tried to shrink responsibility for their bugs

All this being said, we do try to learn from our mistakes: improve testing, more effective code reviews, etc. Also, if a particular developer consistently emits low quality code he or she will get terminated.

Since the main theme of this thread seems to be about accidentally deleting data, here is an example of some stupid programming on my part: an app I once developed stored data about entities in files under folders (directories) - one folder per entity. When an entity was removed the app would remove the appropriate folder. Since these folders could contain subfolders, I used a recursive delete function. Unfortunately I had this bug that when the app was upgraded the folder location was reset to root. Rather than clobbering my own drive it clobbered somebody else's, which actually made it worse ...

I have done the equivalent of

cd /
rm -rf *

but only on old minicomputers where the peripherals manager sorted in front of the CLI and you could with a little luck climb out of the hole.

My favorite tricks have been with pointers:

a. In x86 assembler for a school project, writing into the BIOS, fortunately achieving only a reboot.
b. In minicomputer C, smashing my own stack and causing a machine used by 40 or 50 people to go 100% CPU busy.

"Only those that don't do anything don't make any mistakes. I expect my programmers to have bugs, and I expect my top developers to have more critical bugs simply because they work on more critical pieces of code."

Excellent point. As someone once said: only wise men make really serious errors as nobody trusts fools with anything important.

Run a UPDATE or DELETE query and forgetting to put in the WHERE clause...

End up with a table with everyone named Bill.
Or end up with nothing at all.

I've done this more than once, too!

Call me crazy, but one thing I won't share on this forum are any major mistakes I MIGHT have made in developing software in the past!!!!

Kudos to all of you who are willing to share your stories!

> Did I over-rev the wayback machine for you kids?

Not me.  While screwing around with friends I mangled the paper tape of a 16-bit micro's operating system.  It couldn't be repaired was the only copy of the complete OS.

You don't necessarily have to use your real name...

Memorable mistakes made by code monkeys at my shop include:
One guy who deployed a new database from the development system to the production, by overwriting the production database with the development version, with data and all.

Another deadwood told me a clever story about a time when he decided he was going to "format his computer", ie reinstall Windows.
His method of choice?
Reach down the back of the computer and flip the PSU switch from 240VAC to 120VAC.
The smoke signals emanating from the computer indicated to him after a while that his method was flawed...

Once was writing VB-based multi-tasking system to connect to 25 different databases at the same time, and use DTS services to duplicate their records for the previous day to a centralized database.

The centralized database got about 1 million records per day.  After about a week of this, I edited the VB code.  The next time it ran, the VB code did a 'delete' SQL statement, but the "WHERE" clause was missing. 

Result -- cleaned out the ENTIRE centralized database.  By an act of EXTREME good luck, the DBA had just that day completed a full backup of the database.  So that day we got to "verify the restore procedure" big-time.

I don't THINK they'd have fired me over that, but my reputation would have suffered greatly.  SOME PEOPLE would have thought seriously about it, I'm sure.

I was working at this place that didn't believe in the value vs. complexity of cvs (yes, really[1]), so I was keeping checkpoints on my work with tarballs.  One day I needed to restore part of the tree because I realized I'd just been headed down the wrong path for a few hours and wanted to revert back to where I'd started for convenience, and muffed the selective expansion from tarball, neatly overwriting ALL of my work for that day, flushing six hours or so down the drain.

Sure it's possible to screw up data with rm, but it takes a special level of "DURRR!" to do it with a command intended to *preserve* data rather than delete it.

[1] But eventually the leadership of the department got canned far enough down the chain that like-minded friends and I rose to replace them and we implemented comparatively sane things like cvs and bugzilla.  We eventually all quit because of other stupidity at the company but at least for a year or so there we had things running smoothly in dev.

You know, I'd read about the rm -rf thing, but I'd never done it until August 2007. Then I did it twice in two weeks.  Both times I was going for rm *~ to remove emacs backups and I hit enter instead of tilde. Turns out I am human too. Who knew?

I was new to Unix and working on a large telco's billing systems.  On my test server, I developed the habit of logging out with “kill -9 -1” (which kills all of that user’s running processes).

Sure enough, it wasn’t long until I ran that while logged into the production machine.  I freaked out and tried to get the production processes running again.  No-one complained, and we later found out that the software we were maintaining and enhancing was updating a database that no-one was looking at.

This was an oopsie with my own company. After developing our first product over five years, I personally archived the source on CD and put it in a bank safe deposit box. Five years later we discontinued the product, removed it from our repository because we still had that CD archived, and ended up moving the company cross-country and into a new niche. Then another company offered to buy the original product and source code for $100K, so I flew out to get the archived source from the CD -- and opened it up to find it just contained a folder "Src" with no contents. Oops. Guess I didn't check the "copy recursively" box (it was made when you needed special software to write to CD's), nor did I verify it before sticking it in the vault.

No source, no sale...

Accidentally deleting the password file on my Linux box, so I ended up having to reinstall. I did this twice.

Now I keep the following advice in mind that I got from a sysadmin, made up of two simple rules:
1) Respect the privacy of others
2) Think before you type

Another rm -rf story:

I was working with a program that started with "r"; let's call it "rambo". My sequence of commands went something like this:

> rambo
> rm -rf // clear stuff out

> ...  // bunch of commands here

> !r

Thought I was running rambo again.

Another link for the youngsters: http://www.team.net/mjb/hawg.html

Spaces and semi-colons have been my mortal enemy. Once did 'rm -rf /somedir/ *' from the wrong directory (note the space before the asterisk). Now 'cd /somedir; ls' is hardcoded into my fingers first.

And a variant on the SQL DELETE: 'DELETE FROM IMPORTANT_TABLE; WHERE...'

Oops. And they didn't believe in dev boxes or regular backups. We were lucky to only lose a couple weeks worth of data. That was days after starting a new job. First thing I did was set up my own dev environment (this was frowned on as unnecessary make-work until then.)

I don't fully blame myself for that last one - any sane set up would have prevented doing that on live production data. Still left me with a sinking feeling for a couple days.

Like "fair to middlin", I did a 'TRUNCATE <important table>' on a production box. Thing is, it was an interface table from the court system I was working on to the county Sheriff.  Almost forced a reissue of 65,000 already-served arrest warrants. Oops. Really learned to appreciate our DBA that day...

It seems the rm -rf is a very common issue.

Late at night, applying an update for a company system:

...everything runs fine, so lets get rid of a temporary directory I created while doing the update and some tests...

...taking too much time...err...it seems like...NOOOOOOOO!

I executed the command from the root! System down for a day until I got the server up again.

It was the first and last time I made such a mistake, every time I need to run rm I double check I am in the correct directory.

> Both times I was going for rm *~ to remove emacs backups and I hit enter instead of tilde.

I've been burned by that a couple times. I started shoveling the backups off into a specific location.

;;file: ~/.emacs.d
(setq
  backup-by-copying t 
  backup-directory-alist
    '(("." . "~/.emacs.d/autosaves/"))
  delete-old-versions t
  kept-new-versions 6
  kept-old-versions 2
  version-control t)

Our favorite error here has been forgeting to UNcheck "include dependent objects" in MS-SQL copy function.

Go ahead, install that view from test to production...

All the tables are "dependent objects".

I wrote an animation compressor and decompressor/player as part of my first task at my first job. It ran on a 386.

After a couple of months they asked if would port the code to run on a different machine, a game console. It ported pretty easy, but when they ran it, it was about 10 times slower and no use at that speed.

Well, the compression/decompression was in theory pretty simple and fast, so I was looking through the code for ways to speed it up.

Finally, I found it. The solution is left as an exercise for the reader ...

// temp, slow down so we can see what's happening
int i=100000;
while(i--);

Ditto to "UNcheck 'include dependent objects' in DTS. I attempted to move several tables from dev to prod, for a VERY large military website. After angry phone calls began coming in to our support staff, I realized I crushed about half of our production database/dependant objects.

Not a good day.

``Both times I was going for rm *~ to remove emacs backups and I hit enter instead of tilde.''

Yup -- been there, done that.  I prevented it ever happening again by writing a little script called `cleanup' that holds the correct commands in a carefully vetted form.

One effect of my own `rm *' nightmare was that it removed the only up-to-date copy of a fairly complex interactive Perl script.  Fortunately, (a) I had a copy of the script running, and (b) it had an undocumented debugging feature that allowed the evaluation of arbitrary Perl code.  I learned to love Data::Dumper that day...

When I was a green junior in the games industry I was tasked with the job of writing an IPX driver for our games.

I coded it very carefully and painstakingly, knowing the unforgiving nature of assembler. The code I wrote had only *one* bug in it (it was really just a thin layer between the game and an existing API). When it came to the all important call that passed the packet data down to Netware, instead of using DS as the segment register, somehow I typed ES. (They are pretty close on the keyboard), and so, randomly malformed packets went out onto the network.

As soon as I assembled and ran it, the network started going down. I got the blame. To this day I'm unsure exactly *how* I did it, but after the Netware server was rebooted, I spotted the mistake, changed the D to an E and the packet processing routine worked perfectly. One character made the difference between success and utter disaster.

I like to think Software Engineering has matured a bit since then.

Every time I fail to resist the urge to patch out a fix to production code late on a Friday afternoon (or evening) before a holiday weekend, I earn the Stupid Programmer title.

I once ran a JCL script on a mainframe that destructively read a production MQ and dump the contents on a file.

Only after the job ran successfully that I realized that the disposition of the output file was (NEW, DELETE, DELETE) which means:
1. Create a new file
2. Delete the file if the job is successful
3. Delete the file if the job failed.

Obviously I had used a script that I used to flush development region MQs.

We spent the following weekend recovering data from 500 or so systems that used that MQ to send the data.

It's 2007 people. Honestly, it is. Hell, it's the end of august - it's almost 2008. UNIX is very very old. Windows is very very old. There are people with real jobs who were born after UNIX was writen, and even some bright young people who were born after the first Mac was built.

While the "rm -rf" issue seems to bite a lot of people, the truely incompetent and utterly worthless buffons who're passing themselves off as semi-evolved monkeys are the idiots who write filesystems without built-in support for an undelete operation.

I don't get it.

Do people still think this is the dark ages?  Has noone told these losers about modern inventions like "electricity"?

How god-damned hard would it be to adjust the file allocation table to include a 'deleted' flag, allocate sectors for new files from the oldest deleted files, and possibly even do some background defragmentation?

Yes, yes, I know there are situations where perfection is impossible, but it truely seems like noone is even making an effort.  (And for god's sake, people need to stop logging in as root/administrator/whatever. And if not, they need to stop being surprised when one plus one doesn't add up to eighty three.)


Also - developers distributing code by dumping it straight from their machine to the production machine?  Dammit, what the hell is wrong with you people? Been there, done that, had a lot of one-line fixes that broke more than they fixed. And I know exactly what was wrong with me - I didn't have the guts to tell the boss that we were doing something really amazingly stupid. Do any of you at least do a code review before uploading the new code to a customer's server?


And yes, I'm sure you're all smart people who just had bad luck and/or made a perfectly understandable mistake - it happens to everyone.  But really, so many of these mistakes could be prevented so easily, and people never seem to learn from them. It's one thing to delete a customer's entire database - but it's a whole greater level of incompetence when you refuse to learn and prevent it happening again.

Mine didn't affect anybody else, but it gets points for stupid.  I was new to working on Unix and was given the task of setting up an SGI.  I wanted to update something in /usr/bin and /usr/lib.  So, I did what you would do if you were a good user messing with stuff they didn't understand would do.  I made a backup copy.

But I was copying my stuff into those directories and wanted to make sure nothing old was still sitting there.  So, you guessed it, I typed the following:
  mv /usr/lib /usr/lib2
  mv /usr/bin /usr/bin2

Things started to not work, so I applied the 'standard fix': shut down and reboot.

Had to reinstall the OS.  Oops.

"But really, so many of these mistakes could be prevented so easily..."

That was kind of fascinating too. I was now imagining in hindsight that during the 70s, somebody would have realized that was a common mistake and explicitly hard coded shells to confirm remove operations. Students in the 90s should never have even realized that was possible. And yes, I've been guilty of the same mistake. It's sort of a baptism of fire.

And yes, the problem has been fixed to some extent between journaling filesystems, some specific systems that explicitly support an "mark as delete but don't erase until overwritten" philosophy, and shells that prevent you from casually messing with system directories. Unfortunately, these tend to be optional features.

I think more to the point, this whole category of mistakes can be attributed to the idea that in UNIX/Linux/BSD, you do something as quickly, cheaply and efficiently as possible until something actually blows up. Then you prevent that specific scenario from happening again. In other words, you don't necessarily sit around trying to conceive of every single possible thing that can go wrong, from the get-go.

I don't think rm -rf style mistakes are a stupid programmer trick as they are (as I said) a baptism of fire that helps you gain invaluable experience and teaches you how to decide which contingencies are worth preventing and which ones are a waste of your time to prevent.

My stupid programmer trick was learning how to spawn child and zombie processes in Perl, and inadvertantly creating a fork bomb. I had to hard power off the system because...  a) it was creating too many maximum priority processes to allow any sort of non-simple program to run, including shutdown or halt, and b) those processes would fork and die off between execution of the ps command and the execution of the kill command, despite the results of one being directly piped into the other.

Now whenever I create any sort of looping mechanism, literal or otherwise, a clean exit condition is always the first thing I code in that loop.

(This was back in the day when I was a junior programmer)

I wrote a function in visual c++ called something like:

CString TokenizeString(CString strInput, CString strToken)
{
}

... one of the other programmers found it and said something like "dude, you re-wrote strTok!"

... and then I started reading up on library documentation.  It's amazing that common problems have librari-fied solutions. :-)

Any destruction you can do with rm recursion from root can be matched, even amplified with chown recursion. The files are still there ...

In college was giving a presentation to a crowd of about 40 people. The demo required me to log into a web site, but after I had entered my username I didn't press the tab key all the way, and my password was typed in plaintext in the username field.

Not only did everyone have to sit through me changing my password then and there (the audience members had laptops and wifi), but everyone found out I chose things like "fux0nt3hfurbies99G" for my password.

Two things:

1) SQL Server Mangement Studio is a big improvement on the old Query Analyzer in at least one way: You can change the connection a query window is connected to, instead of having to open a different query window and copy and paste your code from the first window into the second.  Very convenient.  Too convenient. 

Testing a fix for a bug I had a query window full of SQL statements, connected to the dev database.  Most were select statements to check the fix was working.  However, there was a set of trancate table statements to clean out the tables on the dev database so I could run the test again from scratch.  I'd learnt from past experience to place any scripts that update the database within a block comment so I'd have to consciously select them if I wanted to execute them.  So far so good.

Happily testing and debugging for a while I got a call from the customer - a whole lot of messages had been reprocessed.  Several thousand of them.  Hmmm.  It was then I noticed that the query window was connected to the live database and not the dev one.  At some point I'd connected to the live system to check on something and forgotten about it.  So those truncate statements were executed on the live system.  (Luckily for me, and the customer, the truncated tables were transactional tables, reloaded from another database.  Data just ended up getting processed twice as the tables were reloaded).

2) When I started working at a new place the boss told me that all work was to be saved on the local drives of our PCs, rather than on network drives.  He said to log out the machine each night, as a script would scrape the hard disk and back up all the data. 

For some reason, the first  project I worked on was not saved into source control so I made very sure that I logged out and shut down each night to ensure the work was backed up. 

About 3 months into the project the hard disk on my PC crashed, taking all the project files with it.  Took about a day to set up a new disk and then I was ready to download the last copy of the project files from the backup.  It was at this point I discovered the backup script did not run on log out.  It actually ran at midnight.  My boss had meant "log out but don't shut down".  And, because I'd been so worried about backing up the data, I'd been especially vigilent about logging out and shutting down every single night.  I almost fainted, literally, when I realised that I'd lost everything I'd done since I started at the place.

Happy ending though: The boss had put on drinks for the staff on the Friday prior to the disk crash.  Distracted by the social I'd left my machine running over the weekend.  The script had run and scraped my machine on Sunday night.  I'd only lost 4 days worth of work.

I used to be one of the systems administrators of a University in Turkey, like 7 years ago. We had like 6000 users in our main e-mail server: academicians, management staff, other employees. At that time SPAM e-mails with ZIP attachments started to consume our disk space so bad (you would remember that virus comes with a zip attachment which contains PIF, BAT or EXE file in it).

So.. I wanted to do something quick to check the content of the attachments of incoming e-mails. But unfortunately we were using qmail and it's collaboration with other tools like virus or spam filters was really weak. So I decided to write a script to by-pass the local e-mail delivery and check the content of the attachments if there were any. Unzip the attachment, check the contents of it, if contains something nasty, drop it. Otherwise deliver it. As simple as it could be.

I wrote the script. I also add another feature into the script to inform the user about this e-mail which dropped by the server. You people would like to know what's going on about their precious e-mails. The message was something like this: "we dropped one of your e-mails. it was coming from 'this guy' with 'this subject' and the attachment of it has this BAT file in it. if you believe that this e-mail was important for you send an e-mail with this id number and we will forward it to you otherwise it'll be deleted after 7 days". I tested the script with some ZIP attached e-mails. After a couple of tries it was working perfectly.

I set up the qmail server to use this script and tried to send a couple of ZIP attached e-mails to myself from another e-mail server. It was working like a charm and I went home happily; like any other responsible systems administrator would do. I didn't have to wait for anything, I could accept compliments one day later for this marvelous idea..

The next day when I went to university I didn't know that 'complaints' were waiting for me instead of 'compliments'. I walked into my office, checked my e-mails. There were maybe 40 messages about dropped e-mails in my inbox, sent by my script. It was so cool. On the other hand I realized that the only new e-mails were those notices...

I immediately realized what was happening and shocked. Basically just because I didn't test the script with normal e-mails, I couldn't realize that script wasn't working properly with the e-mails without any attachment. Of course the consequence of this mistake was pretty unpleasant. During the entire night, all e-mails that came to the server (except e-mails with zip attachments!) went into the most fascinating virtual device node of the UNIX systems: /dev/null. We lost at least 50.000 messages and I lost at least one day by explaining to users what the hack happened to their e-mails..

Testing is important. Testing a software with every possible input and observing the expected output for every input is more important...

Hacking some registry backup/restore code and accidentally merged someone elses entire registry backup into my own
...on my dev box
...while stepping through the code in my debugger

The time i tried to use net message to tell me a long automated build process had finished and got the cmd slightly wrong.  All 2000 people in the company domain were notified that "Its fricking finished!"

My first proper exposure to the world of the PC was years ago when my father started bringing home a Compaq laptop from work. It came with some version of MS-DOS and Windows 3.1. I already knew how to get around in Windows but decided to use it to teach myself DOS.

It all went really well until one day I discovered the FDISK command and tried it out (yes, in spite of all the warnings). I think I forgot that it wasn't actually my computer. Anyway, once the IT department had rebuilt it my Dad didn't bring it home as often after that...

I write an application that manages 500 firewalls. It had a bug where it wasn't writing the ids into the database correctly. I went into the live system with my SQL Query Browser and ran:

update interface set countryid=6 where deleted=0;

...I forgot to add the " AND Id=3234;" part which was quite important.

one firewall with 5000 interface cards and 499 firewalls with no interfaces at all.

Who's got a backup? Bollocks!

I actually fell victim to rm -rf once too...
but to my defence I must say that it was a misplaced
TAB key press on bash completion that triggered
removal of /... i lost some weeks work, but
afterwards, I

a) always have plenty of backups
b) dont use tab completion (and instead use
aliases and place files in other specials
dirs so that cant actually happen)


Always keep backups guys, ALWAYS!
The little extra stuff you have to do
for the automatic backup is totally worth
it!

A colleague had connected to a network drive and for some reason it was showing up in the taskbar.

Let's get rid of the annoying shortcut says I and delete it. Only a couple of minutes later do I find that I have deleted all the files from the server, and of course, if you delete a network drive there is no copy in the trash bin of either the server or the desktop you deleted it from.

I still maintain the stupid programmers were the ones that wrote Windows, not me!

Well, was trying to fix some screen resolution problem on my Windows XP box at home. After some clicking around on the Display settings in the control panel, arrived at the Monitor Plug and Play Device Driver settings, and noticed a drop down which had this value: "Do not use this device(disabled)". Selected it and applied the value, and promptly the monitor went dead.

Had to reinstall the OS.

The assignment was to do a collision test on an IP network, to see how it copes with many collisions.
I picked the major backbone of my country.
I found the point where everything collapses ;)
It was in '94 and that backbone had no redundancy.
Took the country offline for 4 hours.
My mentor was not pleased.
Dunno why, I did exactly what it told me to do :P

We had an assignment in a class to basically duplicate "chmod", with most of its options.  While logged in as root and playing with the options to get a feel for how they worked in detail, I managed to type something similar to the following command.  "/bin/chmod 000 /bin/chmod".  At this point I could no longer read/write/or execute chmod, nor could I change this, because changing this requires executing chmod.  On the plus side, it did give me an incentive to write my program sooner.

Me: "OK, we're stuck on this, can you send me that on a floppy"

Client: "Sure.  I have a floppy here, I'm not sure if its got anything on it though"

Me: "OK, no problem, put the floppy in"

Client: "OK"

Me: "Now type D-E-L-Space-A-Colon-Star-dot-Star"

Client: "It says 'Are you sure'"

Me: "Say YES"

Client: "OK"

Me: "Now type C-O-P-Y-space-C-colon-F-O-O-dot-B-A-R-space-A-colon"

Client: "It says 'File not found'"

Me: [cold sweat] "Type D-I-R-space-C-colon"

Client: "It says 'No files found'"

Client had heard

"D-E-L-Space-A-Colon-Start-dot-Star"

and interpreted 'A-colon' as meaning to type a single Colon, rather than "A:".  Computer was logged to the C: drive, DOS [bless it!] thought that

DEL :*.*

meant to delete the current drive [Doh!].

Result, trashed C:

John Connors: "I like to think Software Engineering has matured a bit since then."

Fantasies are often rather unrealistic.

Paranoid Android: "Every time I fail to resist the urge to patch out a fix to production code late on a Friday afternoon (or evening) before a holiday weekend, I earn the Stupid Programmer title."

I am going to visit my mother tomorrow for Friday to Sunday, but the scenario is close enough.  I have some changes that I have to do before leaving or do not bother.  I have saved my work in progress.  If I finish, my boss gets the new stuff; if not, he get the save.

Those awards are not worth it.  You did read the thread on them, right?

Sincerely,

Gene Wirchenko

"How god-damned hard would it be to adjust the file allocation table to include a 'deleted' flag, allocate sectors for new files from the oldest deleted files, and possibly even do some background defragmentation?"

It would be easy.  Windows has the Recycle Bin.

What do you do if you need the disk space?  Now, the mistake can be that the Recycle Bin was emptied.

Yes, some people have used the Recycle Bin to hold files that they did not intend be deleted, and yes, Support has emptied it in some servicing of the system.

Sincerely,

Gene Wirchenko

Lots of "del" stories, here is a "dd" story.

Everyone that knew some linux/unix a couple of years ago also had a "wannabe hacker friend".
One day, I was working on dunno what and I had a console window maximized and over that, a regular one, with the always on top set. After I finished what I was working on, on the small window I opened screen + irssi, just to see some messages from my hacker friend. After I switched to his window, somehow my mouse pointer moved over the "background" window.

The guy was bitching that someone screwed his computer and asked me what's the linux command to flood the other guy. And as I was pissed with his multiple stupid requests, I typed:
"dd if=/dev/null of=/dev/hda"

The wm I was using back then had an option to give focus to windows without having the user click on that window. Hopefully, I was using FreeBSD, not linux...

I've done plenty of the usual fat-fingering and what not, but this story tickles me because of how I ended up solving it.

I had to write a basic intrusion detection system for a security class when I was in school.  In retrospect it was laughingly simple, but hey I didn't write the assignment.  The program was required to read a TCP dump and determine if some pre-described detection had occurred, and we were required to write it in C.

I did the project in entirely the wrong way.  I waited till the last minute and wrote it very quickly.  I choose not to iteratively test small pieces as I developed.  And I choose to dynamically malloc/free.  I could have gotten away with not using malloc at all, but I thought it would be more elegant.

So, I "finish" writing the code and try to compile.  I get the basic compiler errors fixed and then I try to run it.  Sure enough there is some sort of pointer error and I segfault.  Am I trying to access a freed space?  Is a pointer getting set to NULL? With the deadline fast approaching (measurable in hours, maybe minutes) I search unsuccessfully to find the bug.

Alright time to find a duct tape solution.  I quickly add a signal handler to the program so that when I get a SIGSEGV the program makes its best guess.  Turns out its best guess was good enough and I got full credit on the project.

One of my first development projects as a professional was building a classic ASP application that maintained a database of about 1300 people.

The people were subdivided into chapters. One of the features of the application was to be able to do a mass mail send to a specific chapter, and send a message to all members.

I wrote this part late one evening, and went to test it. I set up a small chapter with 3 members, each member having an alias of one of my e-mails.

However, when I clicked to send the test e-mail, I accidently forgot to select this test chapter, and the resulting e-mail system fired off "TEST" to the first chapter (about 400 members).

Compounding the problem, I had forgotten to stick a recordset.MoveNext() into the code, so the system became stuck in an infinite loop, and fired about 5,000 e-mails before the script timed out.

I had to spend the next day doing damage control, and the hosting provider was very unhappy with me.

I was given a C++ assignment at school that required me to write a text file encryption program using my own invented encryption algorithm. 

My program used a file pointer to access and encrypt data in a file but did not check for the 'end of file pointer' condition.  When I ran the program it started encrypting the file but it didn't stop there.  It kept encrypting and encrypting. I watched the CPU light flashing for several more seconds before realising that something was seriously wrong and hit the reset button.  But it was too late, when to computer started up, it didn't boot or anything.  All I saw was some large jaggerred system font immediately appear on the screen.  It read "SYSTEM HALTED No operating system BIOS found". 

My program was encrypting the entire hard disk :-O  I had to go the manuals to find out how to reset it.  There were some instructions in the manual which said I had to short circuit the CMOS by moving a jumper on the PC board from one set of pins to another and then back again.  I did that and it restored the BIOS but I lost absolute everything on my hard disk.  I had to reformat and install the operating system, application software, and everything. 

It was a lesson learnt on the dangers of pointers and not backing up my work.  I remember contemplating whether or not I should hand it in to the teacher like that ;)

> "Do not use this device(disabled)". Selected it and
> applied the value, and promptly the monitor went dead.
> Had to reinstall the OS.

"Last known good" didn't give you a chance to recover?

> "dd if=/dev/null of=/dev/hda"

I haven't tried that, but intuitively I wouldn't expect any trouble even if it worked.  There's a big difference between /dev/null and /dev/zero.

Of course I have my share of stupid programmer tricks too, but most of them I don't remember.  There are reasons why I learned to make backups, reasons why I learned to remove write rings from tapes when they were write-protectable, reasons why I learned to verify that backups were readable, etc.  So there are reasons why I don't remember most of my stupid programmer tricks, they were too long ago.

My first job in college required me to learn unix admining.  I decided to install Linux on my home machine.  After one week, I made this mistake:  I had some shell scripts I didn't need anymore in ~/bin, so I was in my homedir and did rm -rf /bin.  I waited a while, and nothing seemed to happen.  Then I types ls.  Error.  find. Error.  I ended up having to run to the office and copy /bin from a machine there (it all fit on one floppy!).  Luckily that worked, since it was the same distro.

Did the Chernobyl Nuclear Power Station emergency shutdown code. 'nough said.

I was student some years ago, we were learning COBOL...
On a IBM AS/400
I was at home, trying some code...
I managed to DDOS the AS/400 with 5 or more process... I love infinite loops... The sysadmin still hates me !

It was my first day of work in a company. Everything was explained to me, and stuff. They used *gasp* SourceSafe for source control.

By lunchtime, I was told to check out the project to my local box so I could start familiarizing with some of the code.

Unfortunately, being a CVS-user before, I was used to the "no-lock" system. And it turned out that "checkout" in SourceSafe (by default) uses locks. I was supposed to do another operation (which I can't quite remember the name now) instead of checkout.

Well, it was taking a long time, so I thought I would just go and have lunch and it would be done by the time I came back. Of course, I had someone call me about a half-hour into my lunch and ask me WTF was I doing. :)

People in different development sites were calling my site and asking "Who the hell is this Marcelo guy? He locked ALL files in the project to himself!".

FIRST DAY. I worked there for a year, have left the company about three years ago, and the friends I made there still call me "checkout", to this day. :)

Didn't do this myself, but still get a kick out of it...

We had an RS6000 running a typical 80's piece of everything AND the kitchen sink software to the run whole business.  Myself and "Dan" are the sum total of IS.

9:30 - head of Shipping comes in to tell me about a bizarre bug that makes no sense.  I start looking into it.
9:37 - head of Accounting comes in to tell me about a bizarre bug that makes no sense.  Huh?
9:43 - head of Sales has a bizarre bug that makes no sense.  Dan!?!?

Dan was pretty pleased with his recursive shell script to chmod and chown all the files in the project he was working on.  Dan had accidentally run the command as root from /