Create a folder on your computer or get a sturdy box made of good cardboard with a lid. Name the folder “Process”. Write the word “Process” on the box.<p>While working, occasionally take photos or screenshots of what you are doing showing your workspace, the computer desktop, the desk with pencils and papers and cables everywhere, the wall or piece of string with notes. Show the messy process of creating something.<p>Type notes on text files and save them with a name like yyyy-mm-dd-note-title.txt. Write notes on bits of paper and notebooks and journals with pencils and pens that you keep all around the places you spend most of your time in, including within arms-reach of where you sleep.<p>Practice writing down notes on a piece of paper in the dark, so you can do so when waking up in the night, before daybreak, to jot down thoughts and ideas from dreams.<p>Record messages and melodies using your pocket computer and remember to save these in your Process folder, too. You are looking for your voice.<p>Put these digital and physical notes in the Process folder and in the Process box.<p>Thank yourself later, in years to come.<p>You are what you observed. Experiences, memories, stories to be told. Put your marker on the map in time, that others may find and learn from.
Just a hint, which I think works well for some more complicated programming project setups: if the project is close to be shelved then preserve it in a virtual machine. Make some trivial auth, or auto login, put some notes on login/desktop screen, setup some IDE inside, check if it builds with no Internet.<p>Myself I use lightweight Xubuntu destkop for my VMs. I also dump hard disks of old Windows machines I am done with and make sure they run fine as VMs.
My main, albeit simple, local organizational pattern is: 1. everything under ~/dev 2. all projects are their own folder under a year folder. And if I ever restart work on something older, I move it to the current year.<p>I have hundreds of project folders and it’s helpful day-to-day to just be able to look in ~/dev/2023 for current stuff. But it is also relatively easy to find older things since I have a sense of roughly how far back they are. Making a new year folder right around Jan 1 and rolling forward active work is always a treat.
My corollary axiom: “always be documentin’”, or, “document or it didn’t happen”.<p>I’d say easily 3/4 of the best stuff I’ve ever done was never bounced from the DAW/NLE, turned into a non-realtime/static artifact from code, or otherwise made archival, and far fewer projects / prototypes / physical experiments got the respect of any capture of any kind.<p>On a certain level I like the wabi-sabi nature of that. On another I wonder how many opportunities to converse or collaborate about mutual interests or future opportunities went by the wayside because I ‘labored in obscurity’ for so much of my life.<p>I’ve been doing some coaching for folks coming up in my industry recently and this has been an idea I’ve tried to convey early and often - “always be documentin’”.
I once created a simple counter [1]. I used it to remind me of eating every two hours. I thought to myself "it's a good counter, I'll show it to people" then posted it on HN. People were like "that is just a counter, why are you showing us that?" So i kind of stop sharing everything, haha.<p>But my GitHub used to be a replica of my projects folder, i would upload everything. I don't do that as much now a days.<p>1 - <a href="https://github.com/victorqribeiro/simpleCounter">https://github.com/victorqribeiro/simpleCounter</a>
I really regret not archiving my projects as a kid. I didn't care to save much of anything back then so they got lost to various HDD crashes and migrations to other systems.<p>I started programming at 11 and don't have anything I made before I was 19. Mostly video games in C++ and small PHP projects I did for money in high school. It's fun looking back at what I have so I really wish I had the stuff from way back in the day.<p>My oldest program of any significance, a console based poker game, was lost with Planet Source Code and isn't in any of the publicly available archives. I started looking for it maybe 6 months after the site went down.
I've started tracking an index of projects and their status in Notion. Then I create an extra page based on a template to put things on hold but make them resumable in the future.<p>In my index, I track: name, status (active, paused, inactive), description, goal and a link to the archive doc if it exist.<p>My archive doc looks like this (I generally delete any sections that aren't relevant to keep these easy to create):<p><pre><code> # <TITLE>
### *Handoff to Future Me: <project name>*
### *Snapshot Date*: <date>
---
### *Project Summary*
- *Objective*: Briefly state what you're trying to achieve.
- *Motivation*: What drove you to start this project?
- *Current State*: Is it in the ideation phase, research phase, or have you already built something?
---
### *Essential Context*
- *Related Projects or Dependencies*: Are there any other projects or tasks that are connected to this one?
- *Technical Specs*: For example, in your lamp project, what type of metal, what voltage for the lamp, etc.
- *Non-Standard Tools & Environment*: Any unique or specific tools you're using. For example, a specific code IDE or a special type of screwdriver.
---
### *Progress and Milestones*
- *Last Completed Milestone*: What was the last significant thing you accomplished?
- *Next Steps*: Like you said, for your lamp: research, clean metal, buff, etc.
- *Stumbling Blocks*: Any challenges you foresee or have encountered?
- *Any Experiments/Tests Conducted*: Brief on what you've tried and the outcomes.
---
### *Resources*
- *Important Files & Locations*: Where are the project assets or codebase stored?
- *Reference Material*: Links to guides, tutorials, or papers that are crucial.
- *Key Contacts*: Who can you consult about this? Even if it's an online community.
---
### *Handoff Summary*
- *Why Stopping*: Why are you pausing this project?
---
### *Notes to Future Me*
- Personal notes, reminders, or advice to your future self about the project.</code></pre>
Just wanna say, thank you to the people in this thread sharing your archive strategies. Gave me a fuzzy feeling reading them all, idk why.<p>Have a great day.
Re: Saving to Web Archive: just a minute ago I found out that one of my old projects isn't loading on Wayback Machine because they forgot to crawl the JS file. (Odd, not sure how they decide which dependencies to crawl...)<p>I was just beaming about the virtues of shipping web apps as a single self-contained HTML file (all CSS and JS in the file, rather than linked as external dependencies) for unrelated reasons, when I found that my other web app on the Web Archive works fine because I had followed this principle!<p>(So it also works in Wayback's *id_ mode, i.e. shipping the original HTML unaltered, because the functionality is independent from <i>where</i> the HTML is served.)
Or don't. It is so liberating not to have to periodically migrate data from one medium and file format to another, and worry about corruption. What are you getting out of it? What are you going to do with your preserved data once you die; burden the next generation with it along with the rest of your junk? Cull data every with every migration.
If not putting them online publicly how do you store / organize them?<p>I just recently bought a NAS for 20 euros and have been thinking about setting it up but am skeptical of relying on it for anything too important. But then again don't feel I can really trust anything too important to be in google drive either.<p>I also even have a hetzner nextcloud instance that I use for most low/medium importance stuff but I've found it a bit unreliable with the connection failing, mountainduck causing finder to crash, and the website getting quite sluggish when I upload a bunch of photos.
I start my projects in `~/tmp/<project>` and when I feel like I'm getting somewhere with them they graduate to `~/src/<project>` and get published on GitHub (and a few mirrors for the most important ones). Anything on `~/src` need to be backed up but things in `~/tmp` can be lost without missing them.<p>When I start working on a new feature for a project I create a PR on GitHub and document my research and then the implementation with screenshots.<p>I also have a text file on my computer where I write a few lines everyday about what I'm doing. From time to time I send it to myself by email.<p>It's relatively simple and low effort but has proven to be very helpful many times.
ArchiveTeam can help get your old sites on archive.org, and Software Heritage can save your old code:<p><a href="https://wiki.archiveteam.org/" rel="nofollow noreferrer">https://wiki.archiveteam.org/</a>
<a href="https://www.softwareheritage.org/" rel="nofollow noreferrer">https://www.softwareheritage.org/</a>
I copy my entire home directory across to every new computer, so I have a lot of random crap laying around in random places that I occasionally rediscover by chance. The oldest stuff I have is from ~15 years ago, when my hard drive died in the middle of a semester in college and I hadn't yet started making backups.
A few months ago I went through my repos on GitHub and marked everything I built with Vue as “archived” which is nice as it prevents any new issues being opened and very clearly indicates the project is no longer maintained.<p>I think it would have been a bad idea to simply outright delete them, though I did delete a few.
If you've got some nodejs, Javascript, Ruby or Python projects and you want to keep them around for posterity then I recommend thinking how you can package them up so they can be safely archived. You could use docker or a virtual machine image.<p>In my editor project ( screencast <a href="https://github.com/samsquire/live-interface/blob/master/screencasts/screencast1.mp4?raw=true">https://github.com/samsquire/live-interface/blob/master/scre...</a> )<p>and in its various components written in Nodejs, Ruby (sourceclassifier) and Python (dot renderer) and they're all in disrepair because I failed to pin dependencies.<p>Also recommend taking lots of screenshots.
> compiled .exe files<p>> Not sure what to do with these besides deleting<p>I was recently digging through some old backups for fun, and have so many little exe's I built in highschool and college just laying around.<p>I moved to Mac shortly after college and made the questionable decision to back up my old hard drives as Mac .dmg files before getting rid of the computers, so getting the exe's into a running version of Windows to even test is a pain.<p>A lot of the older ones are pretty neat little games and graphics demos made for DOS. Be neat to get a little VM up on my site running some of these but I suspect it might be a pretty large undertaking.
Reminds of the quote from Adam Savage from Mythbuster:<p>"The difference between science and screwing around is that in science you write things down."
Funny enough, I was scrolling through an old hard drive of mine about a week ago and on it I found a cli I made in c++ at some point during the first half of the 2000s to solve quadratic equations. I had completely forgotten I ever made it but I bet it cut the time I spent on my math homework drastically. I remember how boring and tedious I used to find them...
Also consider archiving them to the web in a Digital Garden<p><a href="https://maggieappleton.com/garden-history" rel="nofollow noreferrer">https://maggieappleton.com/garden-history</a><p>The most grounding for me are screenshots and scripts with expected output.
What’s the best way to encrypt data for archival, so that it can be decrypted decades later?<p>The encryption software can be discontinued, or change over time and be backwards incompatible.