existencebox

I've reread it and I stand by my statements that it's an isomorphism, simply replace "container" with "machine AAD/auth-system boundaries" in your example.

The "Your credentials stay out of the sandbox" problem, to quote them, is what I see your "require your perms system to enforce it" as implicitly solving for.

(Their "sandbox as cattle" discussion had less bearing on the "which pattern" question to me, since I tend to treat most parts of my agent stack as cattle-like, potentially out of a bias towards that architecture broadly, as I find it's much easier to reason about when as much as possible is disposable/idempotent/eventually consistent. The durable execution point also assumed aspects of the agent scaffold ala prompts don't have to be turned over in deploy, or conversely, can't finish their tasks and then migrate incrementally, and while I might cynically raise an eyebrow at the focus on 25ms for sandbox calls given the dev loops I currently experience, I'd argue there are other ways to solve that problem in both an in or outside of container sandbox pattern.)

I'd even agree with their final point "Consistency is the part we haven't answered" but in a different angle than they intended, as to why my focus was on "how do you _constrain_ agent behavior" since that has been, in my experience, the biggest bottleneck to letting agents do more.

I'd argue you are still using a sandbox, just at a higher ring (outside the machine/VM) and relaying on app/resource level permissions on each of your external resources to enforce it, which requires _all_ of those external systems to be hardened vs. the agent host itself. The capabilities a full machine has for exploring and exploiting external, ostensibly secured systems, has already been touched on via incidents like the anthropic internal model jailbreak. [0]

Giving the whole machine also doesn't answer the question for how the agent can hook into actions that eventually require more perms, and even if you "airgap" those via things like output queues that humans need to approve, that still feels "harnessey" to me.

I feel a bit guilty of debating semantics here, especially as I can't/don't intend to convey any confidence in a "right answer", but my reason for being pedantic is that I do think there are interesting tradeoffs between "P(jailbreak or unexpected capability use|time)" and "increasing power/available capability set", as well as interesting primitives emerging in terms of the components you'd need regardless of where you drew that line (ala paragraph 2.)

[0] https://www-cdn.anthropic.com/3edfc1a7f947aa81841cf88305cb51... (specifically section 5.5.2.4)

While I typically avoid touching non-technical topics, I have the opportunity to chime in as another PA highschooler from the 90's, we absolutely were taught that, down to details in AP courses such as the impact of individuals like John Brown. While I'm not sure I'd have worded it precisely like the parent, the concept of "the four boxes of liberty" and the progression thereof was certainly understood and conveyed. (There was substantial study of the labor rights movements and conflicts/resistance therein as well)

As a manager, I've tried for years to balance both sides of this coin. However, what I find in practice is that your success depends almost entirely on the trust your leadership has in you.

Strong support? Doesn't really matter what you work on, legible or not. Weak support? You can do exactly what they ask and it'll still be an uphill battle, leaving you in a hard situation where you can find ways to do the illegible work, but it will require spending political capital you already don't have (And to preempt the "make that work visible and valued" counterargument, that only goes so far if incentives are misaligned), or gambling that you can change their perceptions by only focusing on the legible work for a time even if it results in worse long-term engineering outcomes and may not bear fruit.

In short, I'd say the most actionable advice I'd give is less about where you spend your time, and more finding a team (or more importantly, a sponsor) where however you spend your time will be valued.

I'm similarly bemused by those who don't understand where the anti-AI sentiment could come from, and "they must be doing it wrong" should usually be a bit of a "code smell". (Not to mention that I don't believe this post addresses any of the concrete concerns the article calls out, and makes it sound like much more of a strawman than it was to my reading.)

To preempt that on my end, and emphasize I'm not saying "it's useless" so much as "I think there's some truth to what the OP says", as I'm typing this I'm finishing up a 90% LLM coded tool to automate a regular process I have to do for work, and it's been a very successful experience.

From my perspective, a tool (LLMs) has more impact than how you yourself directly use it. We talk a lot about pits of success and pits of failure from a code and product architecture standpoint, and right now, as you acknowledge yourself in the last sentence, there's a big footgun waiting for any dev who turns their head off too hard. In my mind, _this is the hard part_ of engineering; keeping a codebase structured, guardrailed, well constrained, even with many contributors over a long period of time. I do think LLMs make this harder, since they make writing code "cheaper" but not necessarily "safer", which flies in the face of mantras such as "the best line of code is the one you don't need to write." (I do feel the article brushes against this where it nods to trust, growth, and ownership) This is not a hypothetical as well, but something I've already seen in practice in a professional context, and I don't think we've figured out silver bullets for yet.

While I could also gesture at some patterns I've seen where there's a level of semantic complexity these models simply can't handle at the moment, and no matter how well architected you make a codebase after N million lines you WILL be above that threshold, even that is less of a concern in my mind than the former pattern. (And again the article touches on this re: vibe coding having a ceiling, but I think if anything they weaken their argument by limiting it to vibe coding.)

To take a bit of a tangent with this comment though: I have come to agree with a post I saw a few months back, that at this point LLMs have become this cycle's tech-religious-war, and it's very hard to have evenhanded debate in that context, and as a sister post calls out, I also suspect this is where some of the distaste comes from as well.

I've appreciated reading your posts broadly/for years prior to this as well, so definitely same statement back your way. If you're ever in the PNW, beers/coffee is on me.

While tone on the internet admittedly makes it hard to tell if your comment was tongue-in-cheek, I'm going to take this in good faith and express my appreciation that you even read through that entire ramble above :)

While "try it and see what happens" may work for low-risk efforts, the costs and chaos associated with this in a system as complex as global employment seems eminently short-sighted. We've already seen how "Try it and see what happens" works for tariffs, have we not?

To your point of cranking it up, I argue that there simply is not a clearing cost that makes US labor viable for many of these positions in the modern world without effectively rendering that service non-viable or dropping US worker purchasing power by a similar multiplier to the salary gap.

In that respect, last I heard, voters and representatives were _viscerally_ opposed to anything that sounded like "Degrowth" which would be the practical outcome of such a policy. (Not making a personal statement here beyond addressing your theory)

In short, my thesis is that if we really want to fix the offshoring issue, there are fundamentally more significant issues that need to be addressed, and absent fixing those, we're only harming ourselves.

Edit: your parent post substantially changed in between my response and now, so I'll address it as currently stands as well:

I'm not sure where "spirit of the law" comes in vs. being a convenient phrase for whatever is being advocated for. I've seen it used innumerably on this very site to defend pushback against worker protections for the last decade in defense of duty to shareholders, certainly.

There is no law that dictates fiscal decisions without regard for practical outcome; that's just bad policy. We appear to not even expect our executive to follow laws at this moment, so the rest of your statement seems to be even more of a non-sequitur. The business-as-a-conceptual-entity will not "suffer" as it's not a human being as much as we'd like the schadenfreude. While it may take a hit in revenue, it has the ability to act globally, it has the ability to shift costs, individuals do not have nearly as much ability to arbitrage, and often have their hands forced. (Look at how UPS is dramatically raising their fees, and will likely profit substantially despite reduced volume. Who is hurting there, the business or the people?)

I'm also not sure what your statement about zoom is in respect to; these business centers are often self-contained entire LOB or call center vs. working across borders. Just on a basis of population, companies like india can provide services that are not realistic for the US , and we are now taxing ourselves for needing to take advantage of that in a globally competitive environment.

(It feels weird to be arguing this since I'm largely pro-supporting-local-labor-markets, and extremely pro-labor broadly, but frankly this is just counterproductive legislation and not the way to go about it. We need to lean on our comparative advantages, not cut off our hand to spite our face.

To make this even more explicit with an example: I would not have this argument were the legislation targeted at specific tactical sectors where the US currently has a meaningful moat or margin, and were an all-out ban against offshoring within those sectors alongside concrete measures to support onshoring, vs. a tactlessly-broad half-measure.)

I respectfully think you overestimate the impact this will have.

Like with the H1-B cap discussions there were murmurs about some time back (Not actually reducing the cap, but instead priority-weighting it by salary instead of difficulty to fill the position, something that'd actually _hurt_ US workers in the positions they can actually compete and be paid well for) this change feels a lot more like a performative money grab than something that will actually change the economics.

Indian headcount is not 25% cheaper for the roles I've seen it used for. It is integer-N cheaper, where N can sometimes be >3-5. Additionally, there simply is not the functional, social, or business infrastructure to spin up a new 10k person business center overnight in the US, meaning that for many use cases even if individual labor is findable, it's not realistic in the same respect.

If anything my fear (and what I've observed thus far) is that businesses will see overseas staffing as critical enough that the cuts will come out of the highest cost center: US employment.

Chiming in with a slightly different perspective: I often bookmark things I see in passing that might not be useful now but may in the future based on things I know I want to do.

Case studies in certain engineering/programming tasks, something I read that I found useful and want to have handy to share with others in the future, project ideas or notes for long-running efforts I pursue and sometimes want a "bucket to pull from" for instance.

While it's certainly true that I probably _use_ 10-20% of what I bookmark, I don't think it would be possible to realize the same positive outcomes without the 80% that I don't. (Just last week I was able to braindump a large piles of 'examples/essays I found helpful learning about neural network optimization' to one of my engineers because I'd kept them handy after they helped me.)

I should say though, I sense this is a slightly different use case than the "I want to read this article just to read it" bookmarks where I know I never will, which is certainly something I've experienced but is a minority case in my life nowadays, so I wanted to vouch for productive scenarios too.

While I normally keep the political threads at arms length, this is an interesting enough game/voting-theory question that I'm honestly surprised no one has linked the fact that this is a well-studied effect, to the point that it has a specific name: Duverger's Law. [0]

[0] https://en.wikipedia.org/wiki/Duverger%27s_law

I take a very mechanical view on this, but take this with a grain of salt as my success has been "banal" at best. You have people paying you for your product. This is more fit than most people achieve.

Some good advice I heard is to find and focus on a KPI that aligns with the sort of use that'd indicate healthy consumption of your product+costs, with a guiding principle of "if people are paying us and using it with a trendline moving the right direction, we're succeeding."

Have you thought about what you'd need to do to get more users/get more eyes? (Presuming you've proven enough traction+lack of churn from existing users that it wouldn't be premature) Similarly, are you talking to users who find value in your product and identifying ways you could provide more value?

I personally see tons of potential avenues for growth given what you've said; but obviously saying this ignorant of much of the reality on the ground so take it with a major grain of salt.

This is a bit orthogonal to the broader conversation, but you've hooked me with your predicament: Can you allow for preorders or "Expressed interest" at a new price point? (or at a hand-wavy price point to assess interest re: overhead/bulk/etc.) If tariffs come down, you can refund/credit, but for customers who wanted this, something-at-some-price may be better than nothing-at-any-price.

I'm going to disagree with this as a long-term ARPG fan and a long-since-washed-up game dev.

Up through the last few years, I was playing Path of Exile rather regularly. The grind in that game puts what we used to do in D2 to shame, to me at least.

(Comparing the amount of time I used to spend baal/cow/key/pindle running to gear a character sufficiently for e.g. ubers vs. what I'd consider equiv endgame bosses in POE from tree-boosted maven/Sirus/ubers/etc, outside of explicitly low-gear bossers like trapping)

I also regularly wish I could go _Back_ to playing it, specifically 1.13-1.15 (harvest) as it was, in my opinion, the peak of ARPG gameplay, as it turned progression from pure RNG where a wrong roll would brick an item or where you had to rely on the market to find your gear into something slightly less punishing where we could experiment with a far wider variety of builds. But the powers that be in POE saw it differently, that it watered down the endgame and made progression too easy, and proceeded to remove the vast bulk of the mechanic, while doubling down on other mechanics that were, frankly, not respectful of anyone's time. (e.g. scourge.)

This to say, I think game incentives have changed over the last few decades. Something subtle, motivated by microtransactions, subscriptions and streamers, has changed the nature of grind from primarily something that needs to be kept fun to make the game meaty enough to play, to something that must sufficiently extend gameplay to keep the microtransaction faucet going and keep certain goals effectively out of reach.

As another hybrid "TLM->EM" with a similarly sized team, over a similarly sized product, I definitely feel many of the same pain points you call out.

BUT. And I say this with all respect, since I broadly find a lot of value in your comments: I strongly disagree to your assertion that remote "is less efficient."

My theory to what is happening is that there are existing methodologies people are used to working in, including 'hacks' to build consensus that were developed in an in-person environment. (Namely, pulling a bunch of people into a room and arguing it out.) My perspective is that remote work makes a bunch of things that are just as critical in-person (shared documentation, good communication channels, trust and rapport, etc etc) non-optional, and your previous hacks far less effective. But I don't see this as a bad thing. If anything, it's like a strongly typed language: It forces you into a more effective pathway. (For instance, imagine how remote folks or even folks-just-not-around-at-the-moment felt in not being able to participate evenly in the "in-person-bash-it-out" sessions or hallway chats without a strong culture of proliferating knowledge and documentation?)

While you may reasonably say "Ok, that's fine, people built up methodologies, why flip it on its head and disrupt a status quo that works" to which I'd emphasize the "we were relying on suboptimal ways to build consensus, and it was a local maxima." I would also propose that I believe a good manager _HAS_ to change their methodologies in some ways more disruptively than just the local/remote shift when dealing with certain styles of employee, (their own) manager, and org+busines structure/process/incentives, and as such, this should just be part and parcel with the constant process of adapting to refine your own methods and style.

(As an aside, I was tempted to make this comment on your upstream comment[0] talking about "maybe I'm not actually succeeding, it feels like winning at a fucked up system" since I definitely feel you there. I got into management in large part out of a "I'm frustrated by how management is often done and how it ends up percolating down to ICs, and I want to put my money where my mouth is that there's a better approach", and while I definitely feel like I've succeeded in some respects, and continue to get "rewarded" as you say, I'm intimately aware that I'm likely still screwing things up/finding the optimal way to balance pathological incentives, and still have a ton to learn. In short, I'd not be surprised if both of us are "doing fine but still have blind spots," so please take my above just as one person's opinions/"attempt to draw the elephant" :) )

[0] https://news.ycombinator.com/item?id=38984369

I will admit your response gave me a little whiplash :P

When I started reading I was getting very ready to disagree vehemently ("remote work is overhyped and only works for a tiny sliver of the workforce")

But your last paragraph seems to describe far more what I've seen in reality; that it's often risk-aversion/not-wanting-to-commit-to-change/leaning-on-what-they-know/wanting-to-look-like-they're-doing-something that I've seen driving RTO in various locations. This hypothesis is supported by, as you point out, the increasing, albeit incrementally, list of companies and teams that have implemented remote successfully (my own included, obviously only speaking for myself/not for my employer).

So, to be clear, I don't think you're wrong that there's intentional focus on communication and collaboration that is _absolutely_ needed to make remote work, and that's harder for someone who doesn't know what that looks like (or for someone junior without experience working in that modality).

HOWEVER I would object to is the assertion that it's "overhyped and only works for a tiny sliver of the workforce."

Since starting to lead remote teams ~5 years back (after having been a dev on one for a few years prior) the delta between remote vs. in-person has been a _negligible_ friction point vs. much more "typical" aspects of management: Individual work habits, motivations, life externalities, team and org dynamic, "standard" disagreement or conflict, etc.

I'd be lying if I said the remote aspect was zero cost, but not only was much of it recouped in building better processes as you may have suggested above, but this enabled both hiring some amazing folks who likely wouldn't have been options if we only looked local, and supporting all of our lives with significantly increased flexibility, both in terms of personal life and in things like time-zone based coverage for outages and on-call. All-in-all, a massive benefit.

(Obvious disclaimer all views are my own and not my employer's)

First, let me say that I don't disagree, pragmatically, with the truth of what you're saying, in terms of increasing your odds on the whole as a candidate.

But that said, as another hiring manager, let me respectfully disagree with this as a strong hiring signal. I say this, to boot, as an engineer with an, in my experience, above average OSS contribution, research, and patent portfolio, although these things are a bit power-law-esque so obviously I'm nothing next to many.

When I interview, I want to know you have a track record of high quality delivery, and are good for the skills you attest to. I can understand some folks looking at the public displays as a proxy to that, but I'd argue, at that point, indexing on the "public" part is orthogonal to what we're looking for it to display, and carries both false positives and negatives.

To some degree we may be agreeing loudly here, where you'd say "well that's what them putting it in public is" but I'd worry that by caring about the public component vs. a more generalized examination of professionalism and accomplishment, we preclude folks who have no time or interest in curating that sort of profile.

If I put myself into the absolute edge case of two candidates all things being equal but one seems to have also made a more visible portfolio of work, MAYBE, MAYBE that would move the needle in terms of establishing a degree of external validation, but I think I'd be looking _hard_ for other aspects to differentiate that would seem to have more direct applicability to our day-to-day needs, and am hard pressed to think of a time in the last few hundred interviews I've had to make such a choice without a stronger differentiator for any candidate above a very junior level.

Documenting everything ruthlessly (meeting summaries, action items, personal knowledge, TODOs, passing thoughts ala things I want to discuss with peers, etc) in a centralized and easily searchable/cross-linkable/organizable fashion.

Build this doc repo as well as the TODO component within it for absolutely minimal mental overhead. In fact, optimize for minimal mental overhead in all things, and ability to reenter/pick up where you left off effectively "on autopilot." This (low mental overhead, reentrency) applies to things like email triage as well.

I realize this is both very terse and very open ended, but it's really the crux of my ability to deal with exponential levels of randomization, complexity, and parallel tasks. If there's any "Secret sauce" this doesn't contain, it's the need to adjust your systems/organization/methods to whatever is "natural" for you (this perhaps goes hand in hand with low mental overhead and reentrency, even the process must be low-overhead and easily 'reentrent', for instance, preparing for forgetting where I put something, I should know my own tendencies for where I'd look such that I buid my organization upfront that I'd readily find it again.)

I'll cap this with one more meta item before I turn this into an essay: Retrospect. regularly ask yourself "how are things? how is what I'm doing? can it be improved? has anything gone wrong/should I be paying attention to anything I'm not? are there any questions I'm not asking?"

While I can't speak for every manager, I can speak for myself managing a hybrid team going on 5 years now (obvious disclaimer, not necessarily the views of my company etc)

Imagine being an IC software developer and being stuck on dial up. That’s what it’s like to be a manager in a remote environment.

This is hyperbolic. I would also suggest it takes some autonomy and responsibility away from managers to adapt and learn new ways for building an understanding of your engineers. If adapting to remote is problematic, adapting to employees with dramatically different methods of thinking and communication (of which there are many) will also be problematic.

Are there challenges? Sure. From my perspective, the largest among them likely being the loss of organic opportunities to casually interact and build rapport, such as over lunch. The second worth mentioning is the friction added to nonverbal communication. (Onboarding is one of the most critical places these hit, but they're ongoing headwinds as well.) But neither of these are in any way insurmountable, or even high on the list of "things that keep me up at night" managing a team. At the risk of a simple answer, I've found they're usually well addressed by intentionally making opportunities to just... interact, and of course finding what works for an individual dev, with a team-wide emphasis on async methods of alignment, knowledge sharing, and consistency/coordination.

None of the things you mentioned, what a dev is doing, what they want and need, should have in-person as a requirement. The statement of "more intrusive" is especially ironic, as I find knocking on an office door and interrupting flow, or bugging someone in the hallway or over lunch "what's the status of X" far more intrusive than having a good process and cadence and ongoing awareness for work being done, and trusting/cultivating engineers to reach out if something comes up. (These are systems which, to emphasize my point, come very naturally when one is supporting a remote or hybrid team, but have broad benefit.) I'd add as well that "is someone smiling" is an... extremely lossy and unreliable heuristic for knowing your engineer, to put it more gently than I probably should.

The funny part with all this said: Your core point, that managers are contributing to the RTO push, potentially has some truth to it. (although I'm inclined to disagree that it's THE major component just knowing the discussions and tax implications between legislators/business owners/bigcos in my own city, it's totally a guess on my part) I've just been reading a bunch of posts lately that seem to defend what is, in my eyes, a cop-out for a manager who should be adapting to far more than remote on a day-by-day basis, resulting in concrete costs both for employees in location/commute and for managers in being unable to hire high quality remote engineers, and this being said so overtly pushed me to write this wall-of-text.

Question for ya if you don't mind: I had to do some PDF scraping a while back as part of a side project collecting alternative social/economic datasources.

Even within a single site, there were often errors at the fringes, especially if things like layout/styling changed, and my concern about giving bad data to users (or needing to constantly be checking data quality and adjusting custom parameters for each target site) held me back from ever feeling confident enough to convert it into a paid product.

I don't mean for you to give up your secret sauce here, but wondering if you ran into this same issue, and what your approach was from a business/customer expectations perspective?

There's definitely a line to walk there re: consumer education, but I'll give the analogy that if you walk into a bank to obtain a loan, you'll hand over _far_ more sensitive information than is in a HAR file. Typically this is fine though, because we're confident we're talking to a party that actually needs this and is whom they say they are, both to lend legitimacy and potentially follow back if something goes wrong. (The fact that we initiated the interaction as well would seem to lend some legitimacy to otherwise "escalatory" requests) I personally see a similar relationship when I reach out to some service provider/utility with an issue, e.g. I'll tell them my SSN but if someone on the street walks up and says "I'm from the water company tell me your birthdate" I'd... make a very confused face.

Both as such, and to be clear, I am sensitive to the making it impossible part, and stand by my earlier statement that ideally you should be able to push back enough to get a cogent answer from the PG as to why they need it, or get an exception if not. (We should absolutely teach people to have informed reservations. Ideally we'd also have better mechanisms for easily verifying identity and securely sharing and ring-fencing information, but if wishes were nickels etc.)

(To wrap this ramble up, I will grant you a scary addendum though: A slight variation to the phishing attack you described even broaches the "We initiated the communication" trust-exercise, as a more sophisticated phisher may be able to by side channel identify that you're having a certain issue and may have reached out for assistance, and can try to intercede in that by extending help pretending to be the intended respondent. The mitigation to this one is typically "never trust someone who reaches out to you, call the trusted verifiable root-of-identity yourself each time." but it illustrates the balance one has to strike in keeping ahead of the escalating cat and mouse game while still being able to securely exchange information when necessary.)

Some perspective, since I've been on the other side of exactly this issue, but for another bigco:

While there may well be a backend issue, in many cases, the HAR file contains tons of useful details (in my product's case) for things like "what were responses from other service calls, was anything failing locally, was any state in a weird... state" that can then let me better understand what's going on in the backend, or even know where to be looking in the backend. These large services are _so complex_ nowadays that looking at a slice of backend logs without the frontend to dovetail can often be a very partial view of the world, or be a needle-in-a-haystack scenario.

I'm giving them the benefit of the doubt here that it's similar to my project, clearly, they could maybe just be running a script (since we similarly request a HAR for all reports, since 99% of the time in practice it _is_ very useful), and you won't be harming anyone from trying to get a clear answer as to if the PG/triage group actually needs it to move forward and pushing back if they don't.

I also imagine that, if they're anything like us, you could request explicit deletion of all your support data from that case after the case is done, and they'd have to comply per GDPR/etc (We certainly would) and they likely already have to silo the information in ways that explicitly makes sure that sort of PII doesn't end up in buckets it shouldn't. I don't know if this moves the needle for you, CC #s are still touchy, but just thinking out loud.

Anyway, I hope this doesn't come across as apologetic for lax security practices, just wanted to give this perspective as I just remember the feeling of frustration of the customer refusing to send logs with a similar justification and my going "but it's going to be _much_ harder/impossible to diagnose your issue without that, and I have 0 doubts in my team's ability to properly handle and dispose of secure data as professionals, we are literally legally obligated to."

I can confirm this on pure (native) FF as well. As someone who has run multiple large web properties this hurts to see. I've observed firsthand the impact of what adding friction to certain browser segments does to utilization, if large corps decide that FF is a "risk" it will do a number on their already struggling traction, and we already live in far too much of a browser monoculture.

(Disclaimer, MSFtie, all opinions are my own)

So, I normally stick very hard to tech topics on HN, but this (dance and tall folks) is so close to heart I have to chime in:

Have faith! Don't feel bad, lankiness while dancing is just "the emergent property" of what happens when a tall person is learning. Short dancers (of whom the 2 of the best footwork-heads in my old crew were) have their own pathologies to get over, it's not all free lunch, they just look differently when they do. And similarly, as they improve, they can gain a really distinctive style of crisp, clean, fast, small motions. HOWEVER, tall dancers aren't precluded from mastering styles that works with our body either, it just, tall as for short, takes practice. Have a link to one of my favorites, Kapela [0]. I can only hope it inspires others like it does me :) (Going to go do my footwork practice now, in fact, as talking about this got me excited.)

[0] https://www.youtube.com/watch?v=AoBveCfGCZk

My somewhat cynical hypothesis regarding "Why does everyone insist on putting customers into price brackets based on such a useless metric" (And I do not mean this as a dig at Gitlab, to be clear, just an examination of the strategy.)

If there is a curve "amount of money a company of a given size will pay", in certain applications, server load, bandwidth, and disk space utilization likely scales far below that trendline, whereas per-user tracks far closer. It also ensures there is effectively no upper bound on CLTV as a given customer scales out, even if net-usage only increases logarithmically/asymptotically.

To try and be even-handed and take a more generous interpretation as well, the former is also less likely to be cogently communicable to a customer, and may have painful UX when limits are hit.

(I want to preface this comment by saying I don't mean in any way to rebut the thrust of the article, I worried this could be taken that way, rather it's a commentary on the inconsistency of feed implementations that I don't find discussed much.)

As a somewhat orthogonal observation, I've found it's surprisingly hard to write a crawler that's well behaved with consistent heuristics across a variety of different feed providers.

Usage of published vs pubdate vs updated, which is changed when, (or all three just containing 1970 and/or the current time), reordered feeds, items published out of order _regardless_ of the scheme used, changing urls/ids, etc. Whatever set of heuristics one uses for some sites may not apply to others. Now, this begs the question of "why not make parameterize and tune", and yes, this is largely what I've resolved to, but it's, to the core point, more of a moving target than one would expect from how ostensibly simple RSS is.

At the end of the day, in many cases I just fall back to using a cache of recently-seen-urls and, when possible, short-circuit the enumeration when I cross one. (Similar disclaimer, I do love me some RSS, I've just never had a good opportunity to rant about this.)

Hah, I must admit the shadow of that question crossed my mind while I was writing my post; for better or for worse I do not work for teams :) I'm currently on the power-query side of the world, and have largely worked in the data/distributed systems space.

I can't speak for Google, but as a Microsoft eng/manager, I _CERTAINLY_ keep an eye out for discussions on my product not only here but on other social channels, and will, if actionable/relevant, try to get it in front of the right eyes; you can likely find some of this in my comment history.

Full disclosure, this is not some MS policy or otherwise, and I don't want to convey that I have some deep system/make assurances that I catch everything, just to emphasize that I find keeping an ear to the ground valuable, and that peers often appreciate hearing the news as well, even if (and sometimes especially if) it's bad news.

In terms of what they "make of it", that's obviously situational, but I've usually seen it approached constructively or as a potentially novel/holistic source of insight.

I used to consider the dislike count. I am still inconvenienced by its absence.

To give one example: In the major categories of videos I watch (tutorials, niche historical topics, video games, music) it was very common for at least some type of "Trojan horse" content to show up (heavily amateur/improper/incorrect content, potentially troll content or in the music case bad rips/"remixes"/mislabeled songs etc.)

Previously, dislike count gave me a way of catching this trivially, even in cases when comments were disabled, before I wasted time loading the page or getting blasted with max volume noise (human screaming in one case IIRC) to the point of clipping my speakers (I hit this post-removal as well, thus this rant).

Low view counts are effectively meaningless as an oracle given that it's largely expected in many cases.

This change has for me as a user severely hampered Youtube's utility as a platform (I effectively no longer use it for discovery), and as a technologist, lowered my respect for the functionality/integrity of the software and its design choices. (I doubt they are unaware of this, but I also doubt I'm their target demographic, and find their stated justifications disingenuous at best.)

when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?"

Wanted to chime in and say _thank you_ for giving me the prompt that this is an "OK" thing to do. (as a technique for trying to encourage/help devs build in good buffer)

As another dev-converted-to-manger, who was also somewhat taken back by that same perception of the malicious manager (I certainly had that perception from time to time as an eng, so it's not entirely foreign although I am surprised by how widespread it seems to have become) what you've written really resonates with me; One consequence is that I've become way more forgiving (in terms of trying to proactively improve it) for what I used to perceive as "bad management" as I struggle to improve my own techniques :P

This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned!

I swear I want to scream this from the rooftops in many of the ragging-on-management threads I see but I know it's not the dev's fault for feeling miffed, a bad manager can _wreck_ your life, but I wish I had a magic password I could tell devs to let them know "I'm here to make you/your work successful, not the other way around, and if I'm ever failing at that I _want to fix it_."

(As sister responses point out, this is something earned, and fully agree, it can just often be an uphill battle, potentially rationally from what devs have experienced prior; again just trying to give everyone in the picture the benefit of the doubt as I'd hope they would me.)

what would I know, I'm just a dumb-ass manager

You're in good company :)