Yup, as of 1.21 drain was still basically a `kubectl` thing – seems like they provided an API for Evictions and for some reason decided not extend that to offer a full 'drain this node' API. That said, Metal3 controllers provide some of this functionality in case you need to manage a bare-metal worker cluster.

Any Cluster API provider will drain the node when you run `kubectl delete machine`

Not sure I agree. Framing the presentation to match the audience’s appetite is what generally helped me get insightful conversation going even with largely non-technical crowds. Each demo can be done in at least a few ways, and if one tries to demo APIs to C-suite as they would to their immediate engineering peers, one could end up at a conclusion similar to yours.

I recently joined a startup, There’s about a dozen of us. Eng demos are scheduled weekly, which feels like a blog post so I won’t get into it here.

Sometimes there’s UI to click around and yes, people are slightly more engaged. However, we’ve had successful demos of infra / API stuff. The key, unsurprisingly, was to surface impact on tangible business goals. No point in trying to explain how Terraform works, but there is value in demoing why it works for your team, how it helps ship and operate infra with confidence, how it helps with repeatability, makes infra changes reviewable, etc. Of course, it’s incredibly important that the group sees demos as inviting and bring their curiosity to the room. If that’s not happening well, that’s a whole other problem.

Good rule of a thumb I tend to use is “half the presentation time for each X% of non-engineer audience”. If there’s 20 min of demo for eng peers, that needs to boil down to 10min as soon as one or two non-eng people join. Less time forces me to focus on value added rather than tech details. X will vary from org to org.

And of course it’s always good to offer more detailed demo in a more focused group later on (e.g. “for those interested in the details of how we use Redis, I can do another demo in a smaller group right after this call”)

I have been wondering the same, and then I stumbled upon one possible answer. There's never any good in generalizing from a single data point, but it offers something I didn't see in other comments.

A Senior frontend engineer at $FAANG I have been talking to recently is struggling with growing into a Staff engineer. They don't want to move away away from user-facing stuff. At the same time, the organization tends to recognize only broad, foundational, cross-team work as Staff-worthy. They are now at a junction: 1) Work on features and stay at current level and in a few years get the "you've been here long enough" promo 2) Build common set of libraries and tools that will be used across multiple teams and get the promo much sooner. Latter is much more aligned with organization's view of "Staff". Although many factors are at play, it's interesting to note that Platform/Infra teams in these companies often more top-heavy than say frontend teams, meaning they have more Staff+ people.

Combining this with what others have been mentioning (stack being approachable, and many people starting their careers in this space) and one can see how anyone with more than a few years of experience in the field is strongly incentivized to build guardrails, and libraries, and whatnot.

Being someone who started as a frontend dev 10 or so years ago and quickly transitioned to backend and finally infra, I will say that fundamental technical challenges on the frontend are little easier to comprehend than the ones in say backend / distributed systems / databases / infra. Combined with huge influx of people, it might just mean there's not enough true problems to solve, so we (re)invent some.

Is “You’ve been here long enough” really true? I’m at diet-FAANG and it’s certainly not true. Same push to build common libraries instead of features.

From what I have seen. I think it’s fairly frequently that an EM runs out of people to put up for promo based purely on merit. When that happens they reach out for folks with tenure in the team. After all, big part of EM’s own promo packet is how many of their reports did they promote.

Another thing is that folks who stick around long enough end up acquiring almost archeological knowledge of systems involved which can be a strong incentive to retain them, for example by awarding a promotion even if they don’t tick many of the “Staff boxes”.

Besides that, I have seen attrition being another cause for these types of promotions. When a Staff TL leaves, it will create a void that an organization often fills by promoting the next most tenured Senior engineer.

As always, FAANGs are huge orgs and these generalizations do not reflect any and all experiences folks might have.

> Many seemingly big decisions are also kind of reversible

Funny how I practice and preach this in my job. When it comes to applying the same framework to decisions in life, I fail to do so

I'm somehow able to find really poor framings that present decisions as irreversible. For example, choosing to go to a smaller co with nice people but worse pay makes the opportunity cost of staying in my current job something that's not reversible (i.e. I'll never get the money et al, so the time isn't spent as good as it could've been). Thanks for reminding me of this, something I need to repeat to myself every day.

Nail on the head! I don't have much going on apart from work and a relationship.

Honestly moving to a new city just before covid ensured I have an excuse for not working on any of that. I'm trying to find a way to travel more, and do more things unrelated to work, but keep telling myself I need to move somewhere else first for a fresh start, and that causes a cycle with what I described in the post.

Thanks for the advice!

Quite a few interesting points you raised, thanks.

> opened one (tech) and the ran down that hallway full pelt Breaking into tech, however unexciting it sounds from one angle, can be challenging from another. I agree I could've done more browsing, but it wasn't a good idea back then. At this point it could be, I don't know. Agreed they are mostly in one narrow realm.

> took the opposite path, worked all kinds of jobs that aren't tech(mining, out at sea, movies). It helped me narrow down what I want If I were to do this, here are some questions that'd keep me up every night: * Can I support myself / dependents working this new job? * X years from now, when it's time to put a downpayment for a house, send my kid to school, or pay for my parents' care, will I regret spending X years jumping between these careers instead of cashing in insane tech salaries? * What is my exit criteria for this exercise? Do I just keep browsing careers that expose me to the edges of the space until I find something I like? Do I have a limited runway? What happens if I burn up my savings and don't find anything life changing? I'm curious how did you think about these?

Don't get me wrong – I am trashing my tech job a bit, but it still gets me the life in which my problems sound ridiculous to 99th percentile of people. Vast majority of other careers won't get me that imho. And writing this comment reminded me I value that a lot, so thanks!

happy to join forces on a side project and make friends.

i'm a fast moving generalist, working on distributed databases and k8s. i am excited about many things, including mobile dev, compilers, generative art, building effective teams, etc.

i can invest anywhere from 2 to 10 hours a week into it, feel free to reach out to me at genmaicha123 at protonmail dot com even if you just want to chat and soundboard ideas.