"REST" is supposed to be an architectural style reflecting the Web as used by humans. Humans don't normally manually construct URLs. They navigate based on links from an entry point. (See also: https://hypermedia.systems/hypermedia-components/#_self_desc... )
Sure. But then what words do you use to describe actual REST?
This keeps happening and all it does it cause confusion.
It's one thing to make up new words for new concepts so you can more easily refer to them in a conversation.
It's another thing entirely to give a word a vague but similar meaning without any clear way to differentiate between the original specific and new extremely nebulous concept.
As simple and important as this is for productive code reviews, I observed in my experience that it’s not as common a trait as one expects it to be. I can maybe attribute it to the stigma that is more deep rooted. In setups where rigorous code reviews are not norm, I notice, many if not most people, take the comments on their code as comments on self.
Given how rampant this is at several workplaces, what ways/processes can be recommended to be adopted in such setups to have more productive, open and meaningful reviews and ease breaking the stigmas associated?
It needs to be reinforced by the team, and not left up to the individual. A team or manager can encourage the behavior (even by just setting expectations at the time of hiring) and based on that, hopefully, some technical leaders are encouraged to lead by example.
I also think it has to be part of a bigger strategy of egoless collaboration, and not hiring assholes.
For some context around what makes this deployment so remarkable, watch this[0] video that talks about the engineering/building aspects of the James Webb
[0] https://youtu.be/aICaAEXDJQQ
Thanks for the link. I am interested in knowing more about the organization behind that project: how many people took care of the deployment, how are they organized, how has quality control been done.
