Microservices

I realize you're being sarcastic (I think), but I actually would put microservices in the same boat. There was a huge push to microservices in the mid teens, and a lot of companies came to hugely regret it. There is a reason this video, [this video] , is so popular. And it's not that "no one is using microservices", it's just that tons of companies realized they added almost as many complications as they alleviated, and that for many teams they were just way too premature. And a lot of the companies that I've seen have the most success with microservices are also the most pragmatic about them: they use them in some specific, targeted areas (e.g. authn and authz), but otherwise they're content using a well-componentized monolith where they can break off independent services later if there is an explicit reason to do so.

Having worked in big tech and small startups, I think GraphQL is a brilliant way to solve an organizational problem that massive tech companies have. It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to add the work to their roadmap and get back to it in a few quarters. Relevant Krazam: [this video] At a small start-up, if the GET /foo/:fooId/bar/ endpoint is missing a field baz you need, you can usually just add it yourself and move on.

>The fundamental anonymity model Google have employed is that the VPN tunnel is authenticated using "blind tokens" which are signed by an authorization service "Zinc." The Zinc service validates OAuth credentials passed in from the client app to verify a user's subscription, then signs the blind token created by the client app to authorize the user's session with the actual VPN backend "Copper." Ostensibly, this will separate the user's Google identity from the VPN identity since the VPN service only knows that it got a valid, signed user token, not what user that token belongs to. In video form for those not keeping up: [this video]

> First off, it's not dangerous. It's just loosely defined. I'm not sure about this. Some people might take it at face value and end up with dozens if not hundreds of services for a domain that doesn't quite need them. Ergo, the project that they work on might have the development velocity plummet, because it has too much accidental complexity and ops overhead. That's how you get humorous parody videos like these ("Microservices" by KRAZAM): [this video] As anyone who has ever seen SOLID or DRY taken as gospel, many people out there would probably agree with the claim that some general advice can definitely be dangerous.

I think we are mixing two different scopes in the the discussion here. If you are naming a company or a product that will be offered to clients, name it something unique that'll appear in searches. However, if you're writing a piece of software that's not going to go outside the company, having descriptive name is the way to go. You can even name your products with generic descriptive names, if your company's name is unique enough, then that'll act as a namespace for product with generic names. Think of packages in Java, C#, we don't debate about that we have to use a cute name for a X.java or X.CS, because that problem has already been solved by namespaces. Product name Excel and Office works for Microsoft because that "Microsoft" acts as namespace and "Microsoft Office" and "Microsoft Excel" are unique enough to be fully qualified names. The ntietz entry is talking about using cute names for internal services, which is very bad idea. Please enjoy [this video]

good article see also this important technical clarity video -which I think is very realistic to real life technical conversations with management: [this video] I think a lot of engineers would rather try to solve a thorny technical problem or even re-architect a whole system than have to explain anything in words to a senior manager or VP. As a result, those of us who can communicate well in both engineering and management speak tend to rise in the ranks More seriously, good communication is REALLY REALLY hard -communication is not writing a good article, doc or giving a good lecture on the backend. communication is making sure the intended audience understands the situation well enough to make an informed decision on the task in hand. It means getting feedback on their understanding of the situation, trying repeated ways to get your message heard until it does. -What I mean is having empathy for the audience or recipient's point of view and spending time to make sure they understand what you are telling them.