3 ms·

> As long as no adopting advice at face value and no cargo culting follows, sure. I advise you to take all advice with a grain of salt. :) It's just what someo

> As long as no adopting advice at face value and no cargo culting follows, sure. I advise you to take all advice with a grain of salt. :) It's just what someone else thinks, it's not something magic. > I'm worried that someone senior will do that, because they want microservices on their CV Heh. I was going to say that the only way this advice is "dangerous" is if a point-haired boss hears about it. Someone padding a resume is the danger though, not the technology they choose. > This is something I can get behind for internal pilot projects, side projects, or hackathons and such. This is not something that I can get behind for projects with potential contractual penalties. Just don't merge it into the main branch. > The entire e-health system of my country is a good example of this [...] I'll check it out. Thanks.

KronisLV 4y ago
> I advise you to take all advice with a grain of salt. :) It's just what someone else thinks, it's not something magic. Agreed, of course. Or maybe even suggestions that have some caution codified into them, such as "innovation tokens" from: https://boringtechnology.club/ https://boringtechnology.club/ Moderation in all things and so on. > Heh. I was going to say that the only way this advice is "dangerous" is if a point-haired boss hears about it. This is also true. I would definitely suggest that there are industry wide trends that urge people to rush towards "the next big thing" or sometimes adopt certain technologies or approaches because "others are doing it, so clearly we also have to". Perhaps a lot of it can simply be summed up by hype cycles: https://en.wikipedia.org/wiki/Gartner_hype_cycle https://en.wikipedia.org/wiki/Gartner_hype_cycle > Just don't merge it into the main branch. The problem the way I see it, is that people don't just experiment with new architectures within the confines of an existing system. Typically they give in to the "second system effect" in regards to their former tech choices when starting a new project, which can have long term implications and choices that are really hard to change down the line: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect But hey, at the opposite end of that spectrum, maybe I shout at the cloud too much; exploring new stuff is certainly desirable - there were certainly benefits to being an early adopter of something like Docker or 12 Factor App principles, even though not without seeing what works and what doesn't in non-prod projects first.
- LawTalkingGuy 4y ago
  > The problem the way I see it, is that people don't just experiment with new architectures within the confines of an existing system. Typically they give in to the "second system effect" Have you tried to advise them otherwise? > Or maybe even suggestions that have some caution codified into them But then every suggestion is couched in a ton of warnings. Not only is this a bit useless, but if someone does start to depend on it they're at risk of a suggestion which lost its warning. Like, say the warning runs onto the next page and that page got lost. There are an infinite number of possible suggestions and all could potentially rabbit-hole a team to death. Why not embrace immutability? Why not go serverless? Why not migrate to on-prem hardware? Why not use a memory-safe language? It seems far better to build some sort of suggestibility-immunity by listening to others, and their suggestions, until you can understand but not feel compelled to copy their ideas.

KronisLV 4y ago

> I advise you to take all advice with a grain of salt. :) It's just what someone else thinks, it's not something magic. Agreed, of course. Or maybe even suggestions that have some caution codified into them, such as "innovation tokens" from: https://boringtechnology.club/ https://boringtechnology.club/ Moderation in all things and so on. > Heh. I was going to say that the only way this advice is "dangerous" is if a point-haired boss hears about it. This is also true. I would definitely suggest that there are industry wide trends that urge people to rush towards "the next big thing" or sometimes adopt certain technologies or approaches because "others are doing it, so clearly we also have to". Perhaps a lot of it can simply be summed up by hype cycles: https://en.wikipedia.org/wiki/Gartner_hype_cycle https://en.wikipedia.org/wiki/Gartner_hype_cycle > Just don't merge it into the main branch. The problem the way I see it, is that people don't just experiment with new architectures within the confines of an existing system. Typically they give in to the "second system effect" in regards to their former tech choices when starting a new project, which can have long term implications and choices that are really hard to change down the line: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect But hey, at the opposite end of that spectrum, maybe I shout at the cloud too much; exploring new stuff is certainly desirable - there were certainly benefits to being an early adopter of something like Docker or 12 Factor App principles, even though not without seeing what works and what doesn't in non-prod projects first.

LawTalkingGuy 4y ago
> The problem the way I see it, is that people don't just experiment with new architectures within the confines of an existing system. Typically they give in to the "second system effect" Have you tried to advise them otherwise? > Or maybe even suggestions that have some caution codified into them But then every suggestion is couched in a ton of warnings. Not only is this a bit useless, but if someone does start to depend on it they're at risk of a suggestion which lost its warning. Like, say the warning runs onto the next page and that page got lost. There are an infinite number of possible suggestions and all could potentially rabbit-hole a team to death. Why not embrace immutability? Why not go serverless? Why not migrate to on-prem hardware? Why not use a memory-safe language? It seems far better to build some sort of suggestibility-immunity by listening to others, and their suggestions, until you can understand but not feel compelled to copy their ideas.