Is this targeted at startup bros with an MVP and a dream ?
In almost any other scenario I feel the author is being intentionally obtuse about much of the reality surrounding technology decisions. An engineer operating a linux box running postgres & redis (or working in an environment with this approach) would become increasingly irrelevant & would certainly earn far less than the engineer operating the other. An engineering department following "complexity is not a virtue" would either struggle to hire or employ engineers considered up-to-date in 2006.
Management & EXCO would also have different incentives, in my limited observations I would say that middle and upper management are incentivised to increase the importance of thier respective verticals either in terms of headcount, budget or tech stack.
Both examples achieve a similar outcome except one is : scalable, fault tolerant, automated and the other is at best a VM at Hetzner that would be swiftly replaced should it have any importance to the org, the main argument here (and in the wild) seems to be "but its haaaard" or "I dont want to keep up with the tech"
KISS has a place and I certainly appreciate it in the software I use and operating systems I prefer but lets take a moment to consider the other folks in the industry who aren't happy to babysit a VM until they retire (or become redundant) before dispensing blanket advice like we are all at a 2018 ted talk . Thanks for coming to my ted talk
While you you're making good points, this shows that engineers and industry intentionally make work more complex than necessary in order to justify higher prices for labor. This is not so uncommon in today's economy, especially white collar and regulated work that most people don't understand, but worth thinking about regardless.
To be fair, it's hard to imagine economy and civilization crashing hard enough to force us to be more efficient. But who knows.
“We care about a collaborative environment,” and you look at their values statements and it’s all about delivering shareholder value or hitting the bottom line. Well, you’re not actually encouraging collaboration and pausing to get to know somebody—there’s a disconnect.
Trying to encourage any sort of camaraderie in environments where the default experience is that you are a disposable commodity is laughable.Even the revered workplace of google was firing employees with 20 years at the org by locking them out of slack to buy back their own shares. I would prefer knowing where I stand from day 1 than getting blindsided.
I've tried options 2 and 3 and I prefer spending my time working instead of constantly having to look busy. Remote work (aside from the obvious life and time benefits) in my experience has forced management to evaluate performance based on output and not bums on seats.Change is scary but I don't think this is going away anytime soon.
It's all about control and the art of performing "work" so that managers can "manage". I'd rather jump off a bridge than go back to spending a 5th of my life in traffic .
Great question! As mentioned in our talk (https://youtu.be/8fiYVyISyz4), we use Cilium to restrict network traffic out of certain workloads running on the cluster. These are L7 network policies. We call this a "data sandbox" because we are restricting the flow from these workloads.
In almost any other scenario I feel the author is being intentionally obtuse about much of the reality surrounding technology decisions. An engineer operating a linux box running postgres & redis (or working in an environment with this approach) would become increasingly irrelevant & would certainly earn far less than the engineer operating the other. An engineering department following "complexity is not a virtue" would either struggle to hire or employ engineers considered up-to-date in 2006.
Management & EXCO would also have different incentives, in my limited observations I would say that middle and upper management are incentivised to increase the importance of thier respective verticals either in terms of headcount, budget or tech stack.
Both examples achieve a similar outcome except one is : scalable, fault tolerant, automated and the other is at best a VM at Hetzner that would be swiftly replaced should it have any importance to the org, the main argument here (and in the wild) seems to be "but its haaaard" or "I dont want to keep up with the tech"
KISS has a place and I certainly appreciate it in the software I use and operating systems I prefer but lets take a moment to consider the other folks in the industry who aren't happy to babysit a VM until they retire (or become redundant) before dispensing blanket advice like we are all at a 2018 ted talk . Thanks for coming to my ted talk