My gut feeling is that this is right. Some devs really do seem to have little respect for "code on the ground", and the problem is magnified in places without a

My gut feeling is that this is right. Some devs really do seem to have little respect for "code on the ground", and the problem is magnified in places without any DevOps culture / a sense of developer responsibility towards operations (ie, Devs who won't do oncall or refuse to write RCAs). I think it stems from a culture where people want strive to adopt the most "elite" way of doing things (ie, running Kubernetes for everything, because Google) because it lets them show they're capable and knowledgeable, and nobody is going to say Google is doing it wrong. The downside to this is that cheaper, faster, and more practical solutions get thrown aside as "hacks" because they don't scale to google level. When really, a lot of places don't need that kind of scale, and having too much complexity can be a risk of it's own. I'm not saying scalability isn't important, it can be critical for some things, but I rarely see devs give the same attention to usability or monitoring in their designs (there are lots of misconceptions that using orchestration solves monitoring, when really it can make it harder if you don't plan for it up front). So I say let google and co worry about impressing people, and just spend your time on making things that solve problems. And maybe, in OPs case, (this may be unpopular) you don't have to share everything you write, especially if it's not something that solves a problem for other people. Put it on your github and resume, but if it's not solving real problems, it's just for your learning.