Low quality comment here, but this line in the article "Back in the day, a computer was something so special and expensive that you only had one, and it was set up in a way that everyone had access to it." reminded me of that line in Back to the Future - the scene where Marty makes reference to having multiple TVs in the house and the dad correcting him: "Oh Honey, he's teasing you, nobody has two televisions."
That's the part that really gets to me. It's one thing to say Hey friend, you could have quickly gotten the right answer yourself. It's another thing to say Hey buddy, you asked me a question which I COULD answer, but instead of giving you the CORRECT answer, I'm going to give you AN answer, and let you figure out if it's correct <-- with the unspoken expectation that if it is the wrong answer and I run with it because you gave it to me, it's still my fault.
I'm similar. I do very little with both hands, but I'm split between left and right on individual things. Throw is right, write is left. Where I especially get hung up is learning something to do with feet - surfing, skateboarding, snowboarding, etc... I struggle to figure out which one is my preference. I usually find that I'm equally bad at both.
Our sports teacher in high-school would tell us to stand straight. Then he would shove us from the back a few times. The foot we would stop ourselves from falling would be our leading foot (for snowboarding). So if you catch your fall with your left foot, you're regular. Otherwise goofy. Don't know if that's a safe bet, but it seemed to work out for us back then.
OTOH: I am convinced I can't snap my fingers with my right hand and never will because my specific mix of handed-ness makes it impossible for me to do so, no matter how hard I try and practice. No problem at all with my left hand.
Our track coach would do the same thing! And he got really frustrated with me because the foot that I led with seemed to vary by day. I'd be fairly consistent on any given day, but another day I'd be consistently the other foot.
I think I heard somewhere (can't find reliable source right now) that he created Captain Planet as a revenge. He had some renewable energy initiative/deal that he was trying to get pushed through that got clobbered by big oil lobbyists. So he created Captain Planet as some revenge scheme.
Oil price shock and a curiously delayed hostage situation displaced Carter in the 1980 election. And we've debt-financed trillions in oil commodity market manipulating wars since.
> “Our mission was to inspire and to educate the next generation of environmental activists,” Pyle said. She and producer Nicholas Boxer made it a point to slip as much planetary realness into the show’s fantastical plotlines. In fact, Pyle says many ideas were taken directly from the Global 2000 Report to the President, a 1980 paper commissioned by Jimmy Carter that warned of environmental disaster should policies fail to account for the world’s booming population growth.
Looks like it was predictively close on population estimates, but the 100% increase in food price production wasn't accurate (though we do have soil depletion and foreign mineral depletion instead).
Big oil lobbyists haven't paid their bills for foreign wars.
Over the estimated interval of 1980 through 2000, Gross National Debt to GDP ratio grew from 35% to 59%. GND-to-GDP is approximately 120% in 2026.
The Carter plan for renewables would've saved trillions of dollars and many lives compared to the 1980-1992 Reagan-Bush debt-financed oil wars.
FWIU the Limits to Growth report is more accurate than the Global 2000 report that - TIL - led to Captain Planet and the Planeteers for us kids back then.
Came here to say the same thing. Folks have been saying for a while "it's a tell tale sign of AI!" and I've been thinking - have people forgotten about Microsoft Word (and other word processors) automatically changing a hyphen to an em-dash?
Agreed. Although alternative to a chunk of Earth as a result of a natural impact, I wonder if it could have been a poorly sanitized space probe from the 60s or 70s?
I learned a long time ago to be very careful with mock, dummy, or test data.... because some people will just push anything to prod, take screenshots during your demo and paste it into the official documentation... you name it.
I was giving a demo on how to set up multiple computers in a federated setup using Active Directory, ADFS, etc... I had about 5 VMs named things like Hank, Peggy, Bobby, Boomhauer, Bill, and a test user HHill, 123 Rainy Street, Arlen, TX -- someone screenshotted and took notes during the demo and now that's in some formal training somewhere material. Thankfully, it's all internal.
When I and doing dev work and I need an available port, just any port, I use 666 -- because it's never used by anything and also DOOM. I gave a sprint demo and I used 660 instead of 666 to demo that the customer can specify the port number of screen X. Someone put that in the internal and also customer facing documentation... so now my company's product is default setup on 660, even thought it's completely user-configurable. Thank God I didn't demo with 666...
I've never really understood developers' apparent need to add cutesy stuff into their work product's test data, variable names, easter eggs and so on. Adding this stuff is all downside risk with no technical benefit that you can explain in a written postmortem that will be read by your boss's boss's boss.
I mean, I get the motivation: You're working on a boring, dry, SeriousBusiness project, and have a creative itch that needs to be scratched. We all have a nonzero desire for a little joy and irreverence at work. But, man, scratch that itch with hobby projects, not stuff that's going out into the public! Or start a "wear a funny shirt day" at work or something like that. I know this is unpopular and makes me look like Debbie Downer, but our projects already have enough technical risks without deliberately adding more.
There's a saying: "Don't post anything online you wouldn't want grandma to see." The developer equivalent is "Don't use test data you wouldn't want the client [or boss] to see." This also applies to variable names, function names, and comments in code.
For a project that involved creating fake companies and user records, I purposely choose to use characters from Star Trek, Star Wars, and the Simpsons for each of the different companies. They're whimsical, non-offensive, and as an added bonus, if I see Homer Simpson listed alongside James T. Kirk, I instantly know there's a data integrity problem.
That last bit is the main reason why I use odd or otherwise out of place test data[0]. Test data should never leak into production. Ideally there should be no means of that happening.
[0] Recent example: tissue sample, species: dog, tissue type: bone. Valid combination, just not present anywhere in prod.
Well, the problem is, in almost all the examples here so far, said stuff was not meant to go out into the public. If your customers end up seeing your product's test data and---heavens above!---variable names, there is an organizational issue that needs to be addressed, cutesy stuff or no cutesy stuff.
Also, isn't the point of QA testing just to throw all and any data to your system? Would you rather have a system that's tested against the eventuality that someone abuses UTF-8 in a textbox or a full SeriousBusiness system with zero whimsy and cutesy stuff? Someone's whimsy cutesy stuff is someone else's street address.
I think you just put a finger on why I absolutely loathe SeriousBusiness Banking Software: they were designed, implemented, and tested in a vacuum that even normal users end up putting a toe out of line that just breaks the assumptions of the spec. You have to be extremely average down to your name to peacefully coexist with them.
If dummy data ever proposes a "technical risk" to your projects, I might argue you're using the term wrong.
Variable names are different, and I'll give you that, but creating humorous dummy data in lower environments shouldn't ever be an issue. Injecting a little fun legitimately helps overcome despair, and the harder and more difficult your project/company is, the more it needs a dose of lightheartedness.
No matter what the scrum boards that reduce us to story points say, we're all human beings. When everything is very high stakes, you're in a perpetual state of fight or flight. It's literally physiologically bad for you. Blowing off steam helps.
As a test of our new Sev1 alerting system, I created a phony alert "The hordes of Mordor are descending upon our data center".
I read the comment to mean that we have enough technical risk that we don't need more general risk. This stuff adds risk. As I have heard: "do you want to read your joke in a courtroom for a non technical audience?" - in some fields more so than others, but there is always a risk that something will go horribly wrong, your system will be involved and your code shows up either directly or as a side effect of discovery.
