Speculative, but had we used containers from the start we would likely have built "fatter" Lambdas running full web servers with an extant web framework (someone else in this thread mentioned Flask - we don't use anything like that, we have one Lambda per... function, and our functions just consume the raw Lambda event).

"Just move" or "just get a new job" is great advice for a highly mobile household where the workers have skills in high demand (e.g. young tech workers with no dependents).

For a great many people, "just move" is terrible advice. Moving is financially burdensome, socially disruptive, at times irresponsible, and at other times impossible. Not everyone has the option of just picking up and moving to a place that's more economically viable. They may not have the money to move. They may have obligations tying them to a particular geographical area. There might be legal barriers preventing them from moving.

"Just get a new job" is similarly terrible advice for most workers, for whom a job is not an easily disposable or replaceable thing. It's nice to work in software, where anyone with a reasonable network can organize half a dozen interviews next week with close to no effort. Most people aren't in software, though. A friend with a STEM PhD recently spent 18 months looking for a new job. Now think about people who have less desirable education or skills. "Just get a new job" is not advice that they can act on easily; certainly not quickly in response to rising fuel prices.

I was going to write a long thing here about autonomy and economic circumstances, but I can't really be bothered. In short: people really don't like having their entire lives disrupted, and we shouldn't be building a society that expects that of the average person.

Places that reward non-leaders for impact are doing so intentionally to encourage people to self-organize into teams that produce the most value for the business. The theory being that the people on the ground often have a clearer view of whether value is being created than the various layers of middle management do. If you work in a place like this it's actually part of your job to stay plugged in to the business side and determine whether you're working on something valuable or not.

This doesn't happen in practice. Instead, people get stuck in poverty traps.

I can't recommend Serverless Framework. The abstractions are leaky and it's quite opinionated about architecture. We regularly need to step away from Serverless Framework to use various features offered by AWS. Meanwhile, it's led us to build an infrastructure that reflects our org chart in some really unpleasant ways. I wish we'd used AWS CDK from the start.

Lambda currently makes sense for us cost-wise, but we are approaching an inflection point where that will no longer be true (something like Fargate will probably be cheaper). Problem is, the cost of migrating from Lambda to Fargate will be non-trivial for us. I wish we'd used containers on Lambda from the start.

We struggle regularly with global state in the Lambda runtime. Some devs avoid it assiduously, which can result in costly inefficiencies which have bitten us badly a few times (think hitting API limits due to calls happening on each Lambda invocation rather than only when needed). Other devs make use of global state for efficiency benefits, which then bites us by causing difficult-to-reproduce bugs. I don't think there's a great solution to this in the Lambda runtime.

Overall I think the benefits of security, process isolation, scaling, cost, etc. have all made it worth it, but there are things I would do differently if I was setting up a project from scratch.

https://en.wikipedia.org/wiki/Pro-ana#Effect

Some kids did this and didn't grow up, because someone in their online community committed suicide and that prompted them to do the same.

This is a real problem. It's been a problem since the 90s, yes, but it's getting worse.

Plenty of people do, but good interview processes are highly context-dependent and not trivially transferable.

And most companies just cargo-cult something associated with a name brand, then tweak it to something they're personally comfortable conducting.

I'll quote myself from an old comment:

> Every time one of these interviewing posts bubbles up I skim it to see if the author mentions things like: company size, team composition, the nature of the work the team is doing, the nature of the industry the company exists in, the way hiring decisions are made, the desired properties of their hiring process, their offer rate, acceptance rate, turnover rate, the amount of time positions tend to stay open for, or really just anything that would offer some context on what, specifically, their interview process is optimized for or achieving.

> Nine times out of ten that stuff is absent and the post is just a bunch of opinion and conjecture.

This post is more of the same.

> Others couldn’t believe what they’d just heard. “Did Mark just say there are a bunch of people at this company that don’t belong here[?]” a staffer asked. Another responded: “Who hired them?”

Two sorts of responses, emotionally opposed, but both coming from people V. Rao might categorize as "clueless" in The Gervais Principle.

> Facebook's owner Meta Platforms says DAUs fell to 1.929bn in the three months to the end of December [2021], compared to 1.930bn in the previous quarter.

https://www.bbc.com/news/business-60238565

All globals should be configurable (most codebases I've seen have a ton of hidden globals).

All side effects should be isolated.

"Break any of these rules sooner than say anything outright barbarous."

I am currently fighting with our security team because they refuse to allow developers to do this, and instead require my team to file tickets with their team, wait hours for that ticket to be picked up, explain why a thing is a false positive to a person who doesn't understand the codebase they're working on, and hope that person feels that the finding should be ignored.

I do not work at a large company.

This is greatly exacerbated by the fact that Snyk - like all package scanners - primarily flags false positives. When you start digging in to what it flags you'll find that a lot of the vulnerabilities aren't reasonably exploitable, or the impact is questionable, or you can't repro the issue. Those that do legitimately affect the underlying library often don't affect your usage of that library. I'd estimate our false positive rate is >90%. So when we get a finding our options are to go through that costly and disruptive process I mentioned above, or just upgrade the dependency (which carries associated risk of breaking shit in production).

These tools emphasize the quantity of findings they produce, and quietly ignore the quality. As soon as you have any divergence in motivations or incentives between the people running the scanner and the people being blocked by the scanner those low quality findings become incredibly costly.

It makes sense that these productivity entertainment books include the simplest, least controversial ideas only. Anything else would reduce the size of their TAM.

The article contradicts this.