

What I find tricky, is that you’re always describing a work-in-progress. I also wanted it to be useful as soon as possible, so I started building the actual core logic first and documented that part of it.
But to actually use it, you need several steps before, which need to be documented, but preferably automated or ideally eliminated.
So, you kind of don’t want to invest time documenting that, because you know it’ll change a lot still.
And just as well, any quirks you document, it’s always like, okay, but what if I fixed this quirk instead?
Obviously, one has to strike some kind of balance. Things will never be 100% perfect or final. And I am most definitely lying to myself, when I figure that fixing it won’t take much longer than documenting it. But yeah, it’s just a constant struggle to find that balance…

















Yeah, I always plead for as much as possible to be automated offline. Ideally, I’d like the CI/CD job to trigger just one command, which is what you’d trigger offline as well.
In practice, that doesn’t always work out. Because the runners aren’t insanely beefy, you need to split up your tasks into multiple jobs, so that they can be put onto multiple runners.
And that means you need to trigger multiple partial commands and need additional logic in the CI/CD to download any previous artifacts and upload the results.
It also means you can restart intermediate jobs.
But yeah, I do often wonder whether that’s really worth the added complexity…