A typical project manager will get a range, take the lower bound and communicate it as the only relevant number to every other stakeholder. When that inevitably does not work out, all the blame will be passed on to you unfiltered.
Depending on where you work it may or may not be worth giving someone new the benefit of the doubt, but in general it is safer to only ever talk about the upper bound and add some padding.
I would argue that people who feel the need to prove their masculinity tend to be the ones not realizing that, and people here are making fun of that.
But is it USB-IF’s fault manufacturers tried […]
Yes, it absolutely is USB-IF’s fault that they are not even trying to enforce some semblance of consistency and sanity among adopters. They do have the power to say “no soup certification for you” to manufacturers not following the rules, but they don’t use it anywhere near aggressively enough. And that includes not making rules that are strict enough in the first place.
They are not bad at this. You are bad at understanding it.
I work with this stuff, and I do understand it. Some of my colleagues are actively participating in USB-IF workgroups, although not the ones responsible for naming end user facing things. They come to me for advice when those other workgroups changed some names retroactively again and we need to make sure we are still backwards compatible with things that rely on those names and that we are not confusing our customers more than necessary.
That is why I am very confident in claiming those naming schemes are bad.
“don’t even bother learning it” is my advice for normal end users, and I do stand by it.
But the names are not hard if you bother to learn them.
Never said it is hard.
It is more complex than it needs to be.
It is internally inconsistent.
Names get changed retroactively with new spec releases.
None of that is hard to learn, just not worth the effort.
Sorry, didn’t want this to look like an attack or disagreement. Just wanted to highlight that point, because arbitrary maximum sizes for passwords are a pet peeve of mine.
At least the character limit had a technical reason behind it: having a set size for fields means your database can be more efficient.
If that is the actual technical reason behind it, that is a huge red flag. When you hash a password, the hash is a fixed size. The size of the original password does not matter, because it should not be stored anyway.
TL;DR: The USB Implementers Forum is ridiculously bad at naming, symbols and communication in general. (And they don’t seriously enforce any of this anyway, so don’t even bother learning it.)
Conserve what? Certainly not the environment, human rights, common decency or democratic traditions. So, what else?
This is beyond micromanagement. Nanomanagement? Or did they skip a step and go straight to picomanagement?
So his “crime” that you want to punish him for is that he improved things in a way that made sense in the context of his time instead of looking decades into the future and forcing a drastic change immediately long before society was anywhere near ready for it? Seriously?
I drew better trucks in crayon when I was 5.
I like to describe it as “a five year old’s idea of a cool car”. I guess you had better taste than most at that age.
It’s not like there was nothing at all in that space before git came along, e.g. we had svn before, and mercurial more or less in parallel.
RustyRooster: C is the root of all modern languages
FORTRAN: Am I a joke to you?