Exactly. Both projects mentioned in this thread (UNIX, Git) have clean cuts visions of what the authors wanted to achieve from the beginning. Nowadays it is almost impossible to FIND such a project. I'm not saying that you can't write another Git or UNIX but most likely you won't even bother using it yourself, so what's the point? That's why I think "research projects" don't fit here -- you learn something and then you throw them away.

What I have in mind are embedded projects -- you are probably going to use it even when you are the only user. So that fixes the motivation issue. You probably have a clean cut objective so that clicks the other checkbox. You need to bring a dev board, a bunch of breadboards and electronics components to the cabin, but that doesn't take a lot of spaces. You need the specifications of the dev board and of the components used in the project, but those are just pdf files anyway. You need some C best practices? There must be a pdf for that. You can do a bit of experimental coding before you leave for the cabin, to make sure the idea is solid, feasible and the toolchain works. The preparations give you a wired up breadboard and maybe a few hundred lines of C code. That's all you need to complete the project in 3 weeks.

Game programming, modding and mapping come into my mind, too. They are fun, clean cut and well defined. The thing is you might need the Internet to check documents or algorithms from time to time. But it is a lot better to cut off Internet completely. I think they fit if you are well into them already -- and then you boost them up working 3 weeks in a cabin.

There must be other lower level projects that fit the bill. I'm NOT even a good, ordinary programmer, so the choices are few.

Back in 2000, our builds, C modules to be consumed by Tcl, Apache and IIS modules, DB drivers took about one hour per OS for a full platform release.

OS being Windows NT/2000, Aix, HP-UX, Solaris, Red-Hat Linux.

That's fine when it's self-motivated, but it sets a terrible precedent for expectations. Doing things like this can put in management's mind unrealistic expectations for you to always work at that pace. Which can be unhealthy and burnout-inducing.

I worked at a place in love with their ERP system. Some there had been using it 30+ years, since it ran in DOS.

My Excel skills completely blow, and I hate Microsoft with a passion, but I created a shared spreadsheet one long Saturday afternoon that had more functionality than our $80K annual ERP system. Showed it to a few more open-minded employees, then moved it to my server, never to be shown again. Just wanted to prove when I said the ERP system was pointless, that I was right.

IMHO the biggest thing is that they were their own customer. There was no requirements gathering, ui/ux consultation, third party bug reporting, just like you said. They were eating their own dogfood and loving it. No overhead meant they could focus entirely on the task at hand.

Impossible! How can the product managers maintain control without the bureaucracy? /s

I also think people under estimate how much pondering one does before starting a project.

That's why Magit exists

The Mocha prototype was better than what I did after the ten days. The biggest wart, == implicitly converting operand types, came after the ten days and was me being an idiot by agreeing with early inside-Netscape adopter requests for slop.

Ryan Dahl gave a speech decades later saying "don't do them" when you are tempted to add little features that might be "cute": https://youtu.be/M3BM9TB-8yA?t=900.

Unfixability is a property of the Web and applies to CSS and HTML as well as JS.

Where feasible, I like to start a suite with a unit test that validates the unit's intended side effects actually occur, as visible in their mocks being exercised.

"never trust a test you've never seen fail." has kept me honest on more than one occasion.

// Todo: remove

return true;