If you run a statically generated website, I recommend append-only generation, where you keep your `dist/` (or whatever web root) stateful between builds. This guarantees you don't break URIs even if the static generator changes or the source content is removed.
You can even make an orphan branch and check out that branch into `dist/` as a worktree to keep it under version control.
Even for people who don't practice this, if you're publishing a static site, you can make sure you're generating output with rel=canonical links and at any given point, you should be able to run a tool (entirely separate from your chosen static site generator) over the output to extract those URLs and verify at time t2 that the set of links that existed at t1 (where t1 < t2) is a subset of those at t2.
This reminds me of Exist[1], although their inputs are mostly automatic and so the data quickly becomes overwhelming and tautological ("you spend more time active when you work out for a longer distance"). Glad to see another entry into this space.
Ten years in the industry. I was #90 at Twitch and grew it to its $1B Amazon acquisition. I've been successful backend and full stack.
I have a special eye for increasing developer velocity. I thrive in small companies with teammates who trust each other, where I can wear a lot of hats and have autonomy to solve pressing issues without much process.
Ten years in industry. I was #90 at Twitch and grew it to its $1B Amazon acquisition. I've been successful backend and full stack. Very experienced in Go and Ruby on Rails.
I have a special eye for increasing developer velocity. I thrive in small companies with teammates who trust each other, where I can wear a lot of hats and have autonomy to solve pressing issues without much process.
Ten years in industry. I was #90 at Twitch and grew it to, through, and past its $1B Amazon acquisition. I've been successful in backend and low-JS full stack roles, including bleeding edge HTML/CSS. Very experienced in Go and Ruby on Rails, experienced in TypeScript and Python, polyglot otherwise.
I have a special eye for, and experience in, increasing developer velocity and improving developer experience internally and externally. This includes writing documentation, automating its publishing, building command-line tools to capture complex flows, building CI/CD, writing and speeding up tests, building service templates and service generators, and more.
Have spun up and maintained infrastructure in Terraform, AWS CloudFormation and CDK, Docker, and Kubernetes.
I thrive in small (< 100) companies with teammates who trust each other, where I can wear a lot of hats and have a lot of autonomy to solve the most pressing issues without much process. I do however recognize the importance of measuring outcomes and I am self-sufficient at doing so.
I'm a staff/principal level Software Engineer, full-stack for low/no-JS or backend otherwise. I've worked "in the open" a lot so bonus points for working on open source and/or community management. I have a lot of experience moving monolithic apps to microservices, from the Rails → Go move at Twitch.
You can even make an orphan branch and check out that branch into `dist/` as a worktree to keep it under version control.