I'm a big believer in this workflow and generally agree with all the guidelines about when to do and not do this.
Code review has value, but I don't think we are always honest about the costs. At most places I've worked, there has been an informal understanding that code should be reviewed within 24 hours or so, but there is a world of difference between getting a review within 2 hours and 23 hours.
If you have to go back and forth a second time, it's so much more likely that the approval comes much later due to straddling end-of-day in someone's timezone.
Tangentially, if you are designing policies for code review at your org, try to think both about minimum requirements (e.g. PRs should get a first look within 24 hours) and typical requirements (e.g. most PRs should get reviewed within 2-3 hours). What typically happens is what determines overall velocity for your org, so it's much more important than whatever strict SLA policy you have. These are also fixable problems if you have targeted conversations with people. E.g. "I noticed X, Y, Z times, you had unreviewed PRs at the end of the day. Can you set aside some time to review code before EOD? Or try installing PR reminder?"
For Americans, 120 kph is ~75mph and 140kph is ~85mph. I think there is a single road in the US with an 85 speed limit, and only some states use 75-80.
I’ve definitely driven 85mph on the I10 in texas. The roads are flat and straight, so it almost makes sense - but you have basically zero margin for error at those speeds. If I recall, the road fatality numbers for texas aren’t exactly good.
I have noticed LLMs have a propensity to create full single page web applications instead of simpler programs that just print results to the terminal.
I've also struggled with getting LLMs to keep spec.md files succinct. They seem incapable of simplifing documents while doing another task (e.g. "update this doc with xyz and simply the surrounding content") and really need to be specifically tasked at simplifying/summarizing. If you want something human readable, you probably just need to write it yourself. Editing LLM output is so painful, and it also helps to keep yourself in the loop if you actually write and understand something.
If you need to type in a password to unlock your keychain (e.g. default behavior for gpg-agent), then signing commits one at a time constantly is annoying.
Does "own" try to sign working copy snapshot commits too? That would greatly increase the number and frequency of signatures.
ZFS has similar configurations possible (e.g. copies).
You can end up in this state with btrfs if you start with a single device (defaults to data=single,metadata=dup), and then add additional devices without changing the data/metadata profiles. Or you can choose this config explicitly.
I really wish the btrfs-progs had a --this-config-is-bad-but-continue-anyway flag since there are so many bad configurations possible (raid5/raid6, raid0/single/dup). The rescue tools are also bad and are about as likely to make the problem worse as fix it.
Yes it's not UB, but the consequences are not limited to a EINVAL/EBADF/EBADFD. Calling close twice is essentially the same problem as calling free twice, so you get all the use-after-free problems on your file descriptors.
Epic's 2019 P&L was published as part of Epic v. Apple. According to that:
* Fortnight revenue was $5.5B in 2018 and $3.8B in 2019
* Employee counts in those years: 1063 and 1932
* Average "People" cost per employee: $141K, $142K (CPI adjusted is $182K in 2026).
* Average "Production & Hosting" cost per employee: $189K, $150K (CPI $248K, $194K)
* Platform royalty expenses were 25% of total game revenue
* Slightly under half their Operating Expenses were people
* Fortnight was >90% of revenue
I have a strong guess that "People" costs doesn't include all salaries, and that many employees are categorized under "Production & Hosting", although I expect that also includes other costs. I'll guess 75% is people, which makes total CPI adjusted average cost per employee somewhere around $320K-$370K, but I'll say $320K.
This means 5000 employees cost around $1.6B and cutting 1000 saved around $320M/year in addition to $500M of other costs.
Most estimates of Fortnight revenue claim it's roughly flat or falling between 2020 and 2025 fluctuating between $3B and $6B.
Unless Unreal Engine or EGS revenue took off, it's kind of weird to quadruple headcount while keeping revenue basically flat or falling. If fortnight only makes $2B next year, then they would be underwater on just royalties and salaries.
FYI 11M IOPS in terms of AWS EBS is 138 gp3 volumes (80K IOPS each), which costs about $56K/month or about $1.3M over 2 years. If anyone was considering using EBS for high-IOPS workloads, don't.
I think your test had 10 980 Pros, which were probably around $120 each at the time (~$1200 total). SSDs are wildly more expensive now, but even if you spend $500 each, it's nowhere close to EBS.
It's apples vs oranges, but sometimes you just want fruit.
I used to work at Clockwise and am (was?) a common shareholder. I'm happy that many employees got to get a job at Salesforce. I'm sure it was tough to swallow some pride and recommend Reclaim, who was our strongest competitor in the space (or at least the one we talked about the most). Reclaim was acquired by Dropbox a while ago, although Dropbox wanted them to continue to run and develop the product there.
I also applaud them for not selling the data (as promised in the ToS). There was always a strong commitment to that from day 1, but I'm glad to see that wasn't an option when times got harder. Calendar data sometimes has really sensitive stuff in it, and it would have been a massive betrayal to do anything but delete it after a shutdown.
If you are interested in a more detailed piece about a company struggling in this space, I recommend Rise's shutdown announcement last year. We read this at Clockwise and unfortunately felt it in our bones. There is an ironic Clockwise callout in the piece if you can spot it.
I'm obviously not part of the decision, but I'm sorry the shutoff for users is so soon. Also, please don't revoke your Clockwise app authorization before the shutoff, since that will prevent Clockwise from cleaning up your calendar. If you want to cleanly turn off Clockwise before the shutoff, you can go through the normal deactivation process at https://www.getclockwise.com/uninstall.
It's a huge bummer for me too to have worked on something for years and then to have it suddenly vanish one day.
If you are looking to start a new company in this space, I'll gladly offer my services to talk you out of it. If any die-hard users want to make a self-hosted tool, I'm happy to give some tips from my experience. I know at least one large company has an internal tool like Clockwise's autopilot/flexible meetings.
Hey, Rise founder here and the one that wrote the sunsetting post–thanks for mentioning it. We obviously followed Clockwise closely and I actually had a great chat with Matt post-shutdown. Can only have respect for how long Clockwise managed to exist and for the way they now handle the shutdown (indeed not handing over that data is a classy move).
I am not sure what clockwise is doing, but since calendar was mentionned, basically you need to break into M365, and for most entreprises, why acquiring another tool to manage calendars.
I happened to work for such companies, and the "application owner", and I am really not convinced by the ROI.
The real reason, VIPs didn't want to bother with a computer to manage their calendar, and they (well their assistants) had to organize meetings with 3rd parties.
Code review has value, but I don't think we are always honest about the costs. At most places I've worked, there has been an informal understanding that code should be reviewed within 24 hours or so, but there is a world of difference between getting a review within 2 hours and 23 hours.
If you have to go back and forth a second time, it's so much more likely that the approval comes much later due to straddling end-of-day in someone's timezone.
Tangentially, if you are designing policies for code review at your org, try to think both about minimum requirements (e.g. PRs should get a first look within 24 hours) and typical requirements (e.g. most PRs should get reviewed within 2-3 hours). What typically happens is what determines overall velocity for your org, so it's much more important than whatever strict SLA policy you have. These are also fixable problems if you have targeted conversations with people. E.g. "I noticed X, Y, Z times, you had unreviewed PRs at the end of the day. Can you set aside some time to review code before EOD? Or try installing PR reminder?"
reply