author here - a few things:
1) code review was always a lossy verification system
2) to eliminate the need for code reviews, we should build systems that can blend predictive execution with deterministic verification
3) if we cannot build bug-free systems, we have to resilient ones
4) a core value of code reviews is knowledge sharing - this we must still preserve through specs reviews
Yeh, Attention Set is a game changer. We (Aviator) also took inspiration (ahem.. copied) attention set from Gerrit:
https://docs.aviator.co/attentionset
If you are looking for an open source stacked PRs CLI, you can look into av CLI (https://github.com/aviator-co/av). Unfortunately this also only works with GitHub, but it should be possible to add support for any Git-based platform.
Disclaimer: I'm the founder of Aviator who supports the av CLI. It's a free tool to manage stacked PRs.
Background: I've worked on all side of this spectrum, left Google 10 years ago and have been working in startups since then. And now founder of a startup.
I agree that from a financial outcome perspective, the odds of making big in startups may not be in your favor.
"Interesting work" perspective may need a bit more color. No matter if you work in a big tech or startup - majority of the work is very mundane. Even if you are working on the coolest AI big-tech or startup, you are probably not doing "exciting cutting edge" work most of the time!
This is probably also why folks who join a startup looking for exciting work get bored quickly with the day-today mundaneness.
Eventually what matters from the interesting work perspective is to understand what part of the work truly gives you joy - what makes you excited about getting off the bed and do great work - even the mundane one.
The motivation could be - seeing your product being used by millions of users, solving a hard problem, sharing your research with the world, having a great work-life balance, or getting rich. Understanding that can help answer the question on what is right place for you.
One challenge I've found in big-tech is that even if the company is doing amazing work, not everyone gets an opportunity to work on the most exciting projects.
Curious if investors are considered creditors through chapter 11. My understanding is that they will still lose the money, but the FTX users will recover everything.
Yeh, perhaps the big shift for the reincarnation was their ability to get a foothold and grow their enterprise sales business. Their strategy of building the Microsoft software ecosystem paid off very well. Also the reason why Slack could not continue competing with Microsoft teams.
The more interesting question would be whether they will go through the same downward trend again sometime in next few years.
But on earth, we have seen now several instances where teams have moved from polyrepo setup to a monorepo. Although "monorepo vs polyrepo" is always a debated topic, and it's hard to scale a monorepo, large companies like Stripe, Canva, Cruise, Doordash have been able to manage monorepos by building strong tooling and automation to handle the scale.
We're excited to announce "The Hangar", a community created specifically for software engineers working in developer experience space to come together, and learn from each other.
The Hangar already boasts a community of dev-productivity teams/ dev-experience teams from leading companies like Figma, Cruise, Square/Block, Slack, and Netflix. The group features open discussions around best practices, useful tools, relevant industry news and career tips.
At The Hangar, we host monthly “off-the-record” zoom hangouts where you'll find detailed insights on topics such as migrating to a self-hosted CI system or setting up Bazel correctly. This is a space where vetted experienced professionals can exchange ideas, share hard-earned wisdom, troubleshoot issues, and ultimately help each other in their projects and careers.
I've also had terrible experience posting on SO lately. Even though I have been posting on it for several years, they keep flagging my questions. Plus none of the questions these days get answered without a bounty. So, now I have to wait over 2+ days to get an answer.
Dev productivity metrics have come a long way from the time when one use to measure the number of lines of code written or the PRs created. I think Dora metrics is still a step up from that as it focuses on measuring team productivity vs individuals, and provides some indicator of the true bottlenecks for productivity.
For everyone who complains about monorepos, remember some of the most forward thinking engineering companies like Google and FB also use monorepos. All the arguments that people make in favor of polyrepo are making so because of lack of strong tooling for monorepos. That's also why Google and FB would not have scaled if they were using GitHub / GitLab but had to build their own. Also Google's original source control was built on top of perforce!
That's very interesting feedback. We certainly don't have a way to force simulate failure.
A related capability we are working on is to also rerun the identified flaky tests X times so they pass. This depends on the capabilities of the test runner, so it will work with specific ones first (cypress, pytest, etc). That way you still make sure that flaky tests pass instead of supressing.
That is a fair argument. Not all organizations have the bandwidth to measure and manage stability of builds. Some companies build internal tools / dev productivity team for this purpose. There are always right intentions to comment out the flaky test with the mindset of coming back to it, but it is also a very low priority item in most cases when you have to ship new features.
Fixing flaky tests can very commonly take longer than writing new tests.