borrow

It's self-reinforcing. If commit history is reasonably clean, the barrier to doing code archeology is lower, so you reach for it more often. And if you do code archeology often, you develop a better sense of what's a clean commit history and what makes commit messages useful.

The need for code archeology depends on a project. When you writing a lot of new code it's probably less important than in a legacy thing where most changes are convoluted tweaks made for non-obvious reasons.

Sounds interesting. What reading on such modern architectures would you recommend?

Postgres (which is a wrapper around tokio-postgres, and as a result drags the whole tokio bloated dependency graph). I would love to have a purely sync alternative to that.

SEEKING WORK, EU, part-time remote contracts only

A generalist, programming since ~2000 (professionally since 2008).

Some areas I can help with: * math * advanced algorithms * interfacing with experts in other technical fields * prototyping * figuring out minimalist solutions * performance optimization * Rust, vanilla TypeScript, Python, C++ * DevEx

[email protected]

What if that particular unique ID is deleted right before the client requests the next page?