The word "Deprecated" or, "Obsolete" in red color.

I moved back over to it operations management 8 years ago, but still this:

/* bl rt err somewhere in 1000s of lines of 
   former Cray Research engineer code ... 
   ... including all comments */

int sS; //!bool in case extensibility
sS = sS || p.sTS(l.(oBll.(null) && oNff) || lL.hash(sTS.df)[gB_1]);
log.bLnl(p.sTT(sS).dsc + p.sTT(sS).stt);
log.bLnl(doer.async(p.sTT(sS), glb.cores, this));

debug: true in production ;)

Javascript.

Truncated a wrong table at production database. that is already store 5000 user's data.

Code written by a 3rd party company that your managers accept (and thus, pay for), because it looks like it’s working. Emphasis on “looks like”.

True story:

We release features internally in the company before rolling it to users.

Once, I reversed the check for a certain feature, which broke production for everyone except employees!

Innocent little !: if (!employee) enableFeature()

It passed staging and regression testing and went into production at night. We patted ourselves on the back and called it a day. Was woken up by angry calls at 5am from users sitting in other time zones 🙈

lesson learned: always test as users, not developers

Manager: Go away and make the thing.

Me: Do you have a spec?

Manager: Not really, but I have this sketch I did.

Me: And a deadline?

Manager: It should only take you a couple of hours.

There's nothing worse than general and/or ambiguous requirements. If one's working with an incompetent boss or ignorant clients, it's all the more important to follow best practices zealously and iron out even the tiniest detail.

That way, when a requirement changes, it won't have as big of an impact.

Personally my worst nightmare as a coder is dependencies and upgrade paths. Every single platform has the same problems because that's the nature of entirely independent pieces of software being updated independently, however some projects mitigate this better than others.

I currently have a system that fortunately I am going to be replacing in its entirety, but it's an old Rails 3 application with a *lot* of 3rd party dependencies - some of them being forks of old versions of libraries - and every now and then I am asked to change something or to add a small feature or two to keep us going until the new system is ready to take its place. However a "small" change in this system is an *absolute nightmare* and I have to constantly work around bugs in libraries that I cannot update because updating them requires updating others, which requires updating others, which requires updating others, which more often than not requires updating Rails itself - which then requires rewriting a *ton* of code because of the differences between Rails 3 and newer versions.

Code can be written in a way that it is less sensitive to these sorts of problems, but more often than not it's a problem that is ignored until it occurs (and by that time it's often too late).

You mention rm -rf * in the wrong directory, I have witnessed this first hand as a colleague of mine many years ago was editing the zone files on our DNS server. Being one of the few *nix heads in the company he liked to highlight his prowess by ssh'ing into the remote servers and changing things live, skipping the FTP process that everyone else needed to use.

Anyway, one day we were all sitting around doing our work and we hear a GASP from his desk. We look over and he has his head in his hands staring at his screen with his mouth agape, and we ask him what's wrong. It takes him a minute or two to regain his composure and explain to us that instead of typing vi * he'd typed rm * and indiscriminately deleted all of the zone files for not only our own projects but those of our hosted customers. He then spent the next couple of hours reconstructing everything from DNS queries and his terminal scrollback.

Fun times!

Lack of self confidence! Even seasoned programmers question wether they actually know what their doing eventually.

Customer or manager with stupid requirements and 0 tech skills. Everything else is solvable, you may even somehow recover after rm -rf while, unfortunately, you can't change people.

Lifetime is very limited, choose wisely people to spend your time with, including your boss, colleagues and customers. After all you are 80% of the people around you. Never waste your time on people or projects you don't want.

When the production server breaks completely after deploying a new version and it's not possible to rollback your migrations! 😱