-
Notifications
You must be signed in to change notification settings - Fork 0
Adds a new hotdogging blog #81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
--- | ||
title: "I Got Destructively Hotdogged" | ||
authorId: "aleric" | ||
date: 2025-04-21 | ||
draft: false | ||
featured: true | ||
weight: 1 | ||
--- | ||
|
||
### Pranks We All Know | ||
|
||
Pranks among software engineers aren't new, people often leave their machines unlocked, inviting playful hijinks. Some host a party on the company group chat, and some remap aliases. Mostly done for people to understand the risks and to propagate good security practices. But recently, when I returned from grabbing tea and saw this command executing in my home directory: | ||
|
||
``` | ||
Check failure on line 14 in content/blog/hotdog.md
|
||
rm -Rf .* | ||
``` | ||
|
||
I managed to hit Ctrl+C in time, but the damage was done. Most of my dotfiles were gone, fortunately, I still had my `.zshrc` and some others. | ||
Check failure on line 18 in content/blog/hotdog.md
|
||
|
||
I knew it was going to be a pain to recover from, but I underestimated the pain. | ||
|
||
### The Domino Effect | ||
|
||
Getting back to work, came my first hurdle. | ||
|
||
My terminal did not look and feel the same, thanks to `.oh-my-zsh` directory no longer existing. | ||
aleric-infraspec marked this conversation as resolved.
Show resolved
Hide resolved
aleric-infraspec marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
After fixing that, new hurdles started showing up: | ||
|
||
- My IDE was missing plugins and configuration. | ||
|
||
Check failure on line 31 in content/blog/hotdog.md
|
||
- My virtual environments were gone. | ||
|
||
Check failure on line 33 in content/blog/hotdog.md
|
||
- Random errors popped up in tools I was using. | ||
|
||
Check failure on line 35 in content/blog/hotdog.md
|
||
|
||
Check failure on line 36 in content/blog/hotdog.md
|
||
Each fix revealed another hurdle, making me think **“I hope I don’t find any more surprises…"**. | ||
|
||
### Sparking Interesting Conversations | ||
|
||
Working in a startup, the news spread fast. | ||
|
||
And what began as dotfiles mourning evolved into discussions and planning on how we could harden not just the personal machines but the services and servers in the office. | ||
|
||
- Automating server setups with configuration management tools like Ansible. | ||
|
||
Check failure on line 46 in content/blog/hotdog.md
|
||
- Scheduling regular syncs to the cloud or local NAS | ||
|
||
Check failure on line 48 in content/blog/hotdog.md
|
||
- Hardening the network redundancy we had and a notification system for it. | ||
|
||
Check failure on line 50 in content/blog/hotdog.md
|
||
|
||
Check failure on line 51 in content/blog/hotdog.md
|
||
By the end, teammates who had not thought of these things walked out learning something new. | ||
aleric-infraspec marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
### Lessons Learned | ||
|
||
The pain got worse. Ironically, I had been wanting to version control my dotfiles on GitHub for months, but other priorities kept getting in the way. However, this incident made me look back and think about: | ||
|
||
1. **Not procrastinating on solutions for known pain points.** | ||
|
||
2. **Documenting every setup step**, even when it feels tedious. | ||
|
||
3. **Investing small efforts upfront to save hours later.** | ||
|
||
|
||
### Hope for the Best, Plan for the Worst | ||
|
||
Unexpected failures are part of software development (and life). When things go sideways or systems break, the difference between chaos and control is preparation. By building redundancy and easy recovery, the disruptions turn into a short detour rather than a full stop. | ||
|
||
Now let me get back to building that redundancy, so the next time someone tries to hotdog my machine, the joke's on them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Grammar issue:
propagate
Suggestion:
promote