4 ms·
If it is overly complicated for you don't use it. However discounting it altogether because you don't need or understand why that complexity exists is naive.
by diveanon 6y ago
If it is overly complicated for you don't use it.
However discounting it altogether because you don't need or understand why that complexity exists is naive.
I hear this a lot in interviews and it's a clear signal that you haven't worked on anything big enough yet.
- echelon 6y ago> I hear this a lot in interviews and it's a clear signal that you haven't worked on anything big enough yet. Quite a bold wager, and totally incorrect. I hope you're not presumptive and rude to all of your candidates. FWIW, I'm a senior engineer at a large tech company where I started pre-IPO and have had pretty great career growth. I've been on a variety of teams dealing with most of the levels of our stack: eventually consistent data models that are active-active, k8s, frontend, tearing down monoliths, etc. I'm fine with microservices for medium to large orgs, and I love Kubernetes. Lambdas and cloud are expensive lock-in, and holding this view doesn't mean you hate distributed systems or complexity. You can staff your own platform teams and manage your own capabilities. Imaging machines, upgrading, failing over - it's all automatable. The excuse I hear is that companies don't want to build things that aren't related to their core competency. But I'd argue your software stack fundamentally relies on the environment it lives within and that ceding control poses a non-zero risk. I'm incredibly fearful of the future where all software runs within AWS or Azure. We'll all be paying taxes to these companies and we won't be able to run or replicate similar environments on our own. It'll be difficult for new engineers to learn as our field will effectively become a "trade". Can you imagine the world where it's expected that everything is composed of SQS and Lambda and other bullshit?
- diveanon 6y agoGreat response. I'm going to focus on one part of it for now. "I'd argue your software stack fundamentally relies on the environment it lives within and that ceding control poses a non-zero risk" This is factually correct, but more nuanced than "just build it in house". Many large orgs externalise this risk by relying on AWS / Azure / Google. Nobody ever got fired for picking IBM is more relevant now than ever, and it is because the largest companjes on the planet have invested huge amounts of time and money solving these problems. I think you misunderstood me at some point, because nowhere did I advocate that everything should be a lambda. Or that everything should be in the cloud. The point I am making is that a lot of people I speak to are afraid of complexity and lock in, when they should be afraid of never being able to grow past what they are comfortable with. To your point about this becoming a trade... Brace yourself, I would wager most development positions will be obsolete in 10-20 years as AI assisted infrastructure and development hits full stride. Especially dev ops and front end.