[kaliszad]

Not really. You should develop better tooling to visualize debugging information. Today's serious systems (this in my opinion includes e.g. collaborative rich text editors) are just too complicated to just eyeball. Pavel, a colleague of mine is developing a new collaborative rich text editor for OrgPad and here is, how we do some testing currently https://www.youtube.com/watch?v=VeVcNmNFzmc We use UUIDs for basically everything. It is simple, we have good tools for working with UUIDs. When we present any IDs to users, those are URL-safe BASE64 encoded UUIDs. In some places, we have "short" links that are about half the length - they cannot really be guessed but are much shorter to type/ Copy&Paste/ visually compare for our customers, who are not always super computer literate. :-)

[hu3]

Disagree. /user/edit/5 tells me easily what record it is about on the database without having to copy paste an UUID.

Dev experience truly is a case of death by thousand cuts. I avoid every little cut I can like the plague so energy goes into making cool stuff.

> Should develop better tooling to visualize debugging information.

Thing is, why would I spend time overengineering tooling I don't need if I can get away with incrementing ids? When optimizing for value, I'd rather spend time solving business problems.

Your editor is very cool btw. And it's clearly a case where incrementing ids are not optimal.

[kaliszad]

Thank you for the reply. You are totally right about the dev experience and the death by thousand cuts.

I really was talking about serious/ complicated systems, where you want some consistency in the components it is made of even if a particular case could just use an incremental id. I my view, you don't spend the mental energy on switching between models. I have just adjusted/ rewritten a part of the system, where we for historical reasons used logins instead of UUIDs. By using logins in this particular case, we had subtle bugs that wouldn't occur with UUIDs. It would never have happened, had we used UUIDs everywhere from the start. Those already have standard validation functions and you don't have to think about stuff that really isn't your business problem. We are also talking engineering days thrown out of the window just for the change from logins to UUIDs later on. I don't think you waste so much time copy&pasting stuff.

I guess, we arrive at the same conclusion but have our differences about the ways leading to it. We both want to focus on business problems as much as possible.

[throwawayboise]

You're not wrong, but (as I suspect is the case with a lot of us) the vast majority of my work is CRUD and I don't reach for heavyweight debugging tools unless printf() or the equivalent fails me (which is rare). Integer IDs work great in this situation.