Every blogger outside the company will carry more weight and expertise than you do, unless you are the CTO. And very possibly even then if your CTO is more of a

Every blogger outside the company will carry more weight and expertise than you do, unless you are the CTO. And very possibly even then if your CTO is more of a business CTO than a T CTO. The bottom line is that there are always going to be problems that are hard to solve, and newer generation just coming face-to-face with them for the first time. Some of the lessons they will learn through fads will be the same lessons you already learned. Some of the lessons with have a slightly better approach, or the fact that resources are generally cheaper means that cool things that were a pipe dream when we were struggling with these things are now a reality. For example, I still can't take docker seriously. It doesn't take security seriously, and doesn't have good answers for some pretty common deployment scenarios. I also sort of hate the way it gets used as function containers, or generally "lambda"/serverless stacks. That still seems utterly crazy to me, and the wasted overhead is completely insane. On the other hand, Vagrant is goddam amazing. Having a perfectly defined dev environment literally a click away is genius. And it works. And it's for dev, so a lot of my nitpicks go away. Both of these things could be described as aspects of DevOps. The core problems are things we had to deal with when we were green, and we came up with other things because resources were just differently constrained than they are now. I'd still argue against docker for deployments--right now-- even though I think that some level of containerization will be a trend that ultimately wins. The reality is that these trends move in predictable cycles. Some new-ish people find a problem that is absolutely gross, and they set to work doing what they are doing: building a solution. Often they are too enthusiastic and miss some of the wisdom of experience, but so what. It's what we do. And we all did it when we were starting out. The idea gets some traction because it's new and fresh and exciting and it trades this really gross ugly thing for some other really gross ugly things down the road that they haven't really run into just yet, so it all seems much better at the moment, so everyone jump all in. First in the startup crowd, and several years behind, your bread and butter in-house shops start to hear about some of these trends and figure they've been around long enough, so maybe give them a try. So your team tries them out. Or goes whole hog. Whatever. Do your research; understand what the pitfalls are; make suggestions to mitigate some of them. You'll find this is hard to do if you haven't really tried them out. So do it. Use the trendy shit and learn them inside out. Make your arguments from experience working with them, not a theoretical point of failure or a medium post about some company that tried X trendy thing and it failed miserably so they went back to the old way. The end goal here isn't to keep things the way they are. The trendy shit will fall over at some point. The goal is for the status quo to land in an overall better place. To take some of the good parts of the new stuff, mix it in with the old stuff and gradually chip away at these same problems we keep running into over and over: team productivity, communication with stakeholders, priority, deployments, reliability, testing, timelines, data management . . . except for those of us lucky enough to work in research labs, these problems are the hardest ones we deal with at work every day. Most of us are not advancing the state of the art. As long as these problems are going to be around, there are going be new and trendy ways of dealing with them. And most of them have at least some novel approach that's worth taking a look at. Sorry for the long post. I guess what I mean is that the best way to not appear to be a luddite is to actually not be a luddite. Engage with and master these trends when they come up. Your instinct will be a good guide in helping you predict where problems will come up. Listen to that, but give them an honest chance at the situations they are designed to solve. Doing this has a number of good side effects: 1. You will learn something valuable from a different approach, even if it's almost entirely wrong-headed. 2. When people start to realize the trends isn't a good fit, you will have a voice in the conversation about resetting the status quo. People will listen to you because you took the time to become an expert on the system. You've been tracking its successes and failures, and you already know where the good parts are that can be salvaged and added to previous ways. People will trust you because you approached the situation with intellectual honesty, technical curiosity, and aim to improve the overall health of the organization. 3. Your resume will look smashing good the next time you go shopping without having to read 20 "getting started with X" articles so you can put a couple dozen buzzword trendy technologies on your resume under the <1 year of experience category of your skills list to get through recruiting filters.