Ctrl Zee

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:

• What success looks like. Be concrete: “in a year I want X”. If you can’t say it, probably it’s not the right time for the decision.
• The risks. What could go wrong, and how bad would it be? Money, time, people affected.
• The known issues. The problems you can already see today and are choosing to accept.
• The way back. If it goes wrong, how do I undo it, what would it cost, and when will I check? Put a date on it, like “in 3 months I review this”.

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.