5 ms·

Everyone, even experienced engineers can make mistakes. Calling that 'bottom of the barrel' isn't helpful. Especially in a larger team you can't expect everyon

Everyone, even experienced engineers can make mistakes. Calling that 'bottom of the barrel' isn't helpful. Especially in a larger team you can't expect everyone to know fine details of every other part of the system. If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't. I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors. If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects.

stephenr 3y ago
> If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't. Either we have very different ideas of what "mostly" means or you don't know what the different versions of UUID include as well as you think you do. If we're considering the 5 published versions: 1 is built from random data; 2 are built from time & host data; and 2 are built from a namespace and a "name". If we consider the 3 proposed additional versions: 1 is built from time & host; 1 is built from time & random data; and 1 is built from custom data. So I personally wouldn't consider "most" to mean either 1 of 5 (20%) nor 2 of 7 (28.6%). > I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors. I would expect someone who is writing software and encounters UUIDs to take the few minutes needed to understand the basics of what goes into the different versions, ensure they're being used correctly. > If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects. They don't need to "hold the entire system in their head". They just need to (a) have the most basic understanding of what a UUID contains, and then (b) use it appropriately.
- smallnamespace 3y ago
  Yes and anyone who doesn't meet your expectations is 'bottom of the barrel' in your book, you've made it clear. Sorry mate but not everyone gets to always work with the best of the best. I went through this exact exercise in the past and avoided v1 IDs because I suspected there is a risk they become externally exposed down the line, perhaps even years later when I'm gone. I suppose you might decide otherwise and then blame others for incompetence instead if down the line someone failed to comprehend UUIDs like you so effortlessly do.
  - stephenr 3y ago
    > anyone who doesn't meet your expectations is 'bottom of the barrel' in your book Please try re-reading what I wrote because you clearly didn't comprehend it the first time. I never called anyone bottom of the barrel. I said the reason not to use them is "bottom of the barrel", as in, it's a poor excuse for not using something, based on blatant misuse. Like saying "people mis-type URLs all the time, we should get rid of them" or "people get electrical shocks when they stick utensils in power outlets, we should stop using electricity"

stephenr 3y ago

> If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't. Either we have very different ideas of what "mostly" means or you don't know what the different versions of UUID include as well as you think you do. If we're considering the 5 published versions: 1 is built from random data; 2 are built from time & host data; and 2 are built from a namespace and a "name". If we consider the 3 proposed additional versions: 1 is built from time & host; 1 is built from time & random data; and 1 is built from custom data. So I personally wouldn't consider "most" to mean either 1 of 5 (20%) nor 2 of 7 (28.6%). > I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors. I would expect someone who is writing software and encounters UUIDs to take the few minutes needed to understand the basics of what goes into the different versions, ensure they're being used correctly. > If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects. They don't need to "hold the entire system in their head". They just need to (a) have the most basic understanding of what a UUID contains, and then (b) use it appropriately.

smallnamespace 3y ago
Yes and anyone who doesn't meet your expectations is 'bottom of the barrel' in your book, you've made it clear. Sorry mate but not everyone gets to always work with the best of the best. I went through this exact exercise in the past and avoided v1 IDs because I suspected there is a risk they become externally exposed down the line, perhaps even years later when I'm gone. I suppose you might decide otherwise and then blame others for incompetence instead if down the line someone failed to comprehend UUIDs like you so effortlessly do.
- stephenr 3y ago
  > anyone who doesn't meet your expectations is 'bottom of the barrel' in your book Please try re-reading what I wrote because you clearly didn't comprehend it the first time. I never called anyone bottom of the barrel. I said the reason not to use them is "bottom of the barrel", as in, it's a poor excuse for not using something, based on blatant misuse. Like saying "people mis-type URLs all the time, we should get rid of them" or "people get electrical shocks when they stick utensils in power outlets, we should stop using electricity"