Engineer, 20+ years of project management, now tangled up in change management and AI. I share the mistakes behind the lessons: what I did, what broke, and the exact Ctrl+Z moment.
Blog: https://www.theundostack.org/ · Mastodon: @ctrlzee@mastodon.social
Excellent advice, you don’t need anything complex, just install git and you’re good to go.
Think of a commit as a save point before the boss fight. One rule is enough to start: commit every time something works, and always before trying something risky. Write the message as if for yourself in six months.
The server can wait until you have something worth losing. Just remember git on one disk isn’t a backup: copy the folder somewhere else now and then.
Practice :) A tiny deliverable after each chapter or tutorial, something simple you can finish in a few days. Accept that it will “fail” sometimes, that’s part of it.
The best bit: the doubts you hit while practicing tell you exactly what to learn next.
That’s how you get out of tutorial hell: you stop following the course and start following your own questions.
Not exactly a floppy, but close: more than 20 years ago a very dear person gave me an Iomega Zip drive and a couple of disks. Game changer. My hard drive was 40 MB, so for the first time my backup was bigger than my computer. Same speed, too, so not much of a sacrifice.
Later came the tiny Clik! disks: great as a music player, and perfect for carrying data around when 100 MB was a HUGE amount of memory. Through all my university years the Zip was my go-to. I just learned to pray every time I heard a click that wasn’t the brand name. :D
Good point @bold_omi.
I was playing with Linux back in the kernel 2.0 days. The tech was mostly ready for us geeks, but not for everyone else. Switching meant new habits, and “it’s free and open” was never a strong enough reason for most people.
People use big tech products for convenience: already installed, works out of the box, compatible with everything their friends use. Microsoft knew that playbook very well.
No matter how much we argue and explain, if it isn’t more convenient, most people won’t switch.
The silver lining: building small alternatives has never been cheaper
I see a lot of useful replies here.
I prefer to answer to 4 simple questions, helps me have a clear idea without overcomplicating:
The fourth point helps you to determine how “big” the decision is. If it’s easy to reverse, decide fast. If it isn’t, slow down, sleep on it, and talk to someone who has already done it.
I get the appeal of a self-hosted tool, but my suggestion is to do the important ones in person.
When I ran a Linux group years ago, the decisions that mattered were settled around a table. For a big decision, the dialogue and the discussion that lead to a common agreement are the real work, and in my experience no software does that part for you.
For small stuff, a simple poll (or no poll at all) is fine: the core team decides and shares it as information. Save people’s attention for the decisions that need it.
I wish I’d had an AI assistant when I was teaching myself to code at 14, in a small village with no developers anywhere near me. My first stack overflow came from a recursive call, before I even knew what recursion was. It took me months to figure out. A patient teacher next to me would have found it in minutes.
That’s how I’d use AI to learn: not “solve this for me” but “where’s the problem? Why? Teach me.” Used like that, it’s the knowledgeable, patient mentor most of us never had. Used the other way, it does your learning for you, and you learn nothing.