As a recurse alum (s14 batch 2) I loved reading this. I loved my time at recurse and learned lots.
This highlight from the post really resonates:
“ Real growth happens at the boundary of what you can do and what you can almost do. Used well, LLMs can help you more quickly find or even expand your edge, but they risk creating a gap between the edge of what you can produce and what you can understand.
RC is a place for rigor. You should strive to be more rigorous, not less, when using AI-powered tools to learn, though exactly what you need to be rigorous about is likely different when using them.”
I’m sorry, I believe the topic was dietary guidelines.
But you’re right, of course, if we should consider the environment as well. I haven’t eaten fish in 8 years, personally, partly because so much of it is fished or farmed in an unsustainable way.
Sure. Our numbers are smaller, as our org is much smaller but I think they hold up.
We have under 100 engineers at BuzzFeed, so for us we reduce time spent supporting applications by a single percentage is almost equivalent to having an extra engineer!
On a typical day we'll do 180+ deploys. That'll be roughly 60% stage, 40% production. To deploy outside of continuous deployments (e.g. to push a branch build to a stage environment), is as simple as browsing to our deploy UI, selecting the service you want to deploy, the version, and the cluster to deploy too. It takes an engineer about 40 seconds to do that (time measured from typing URL, to hitting the deploy button)
Continuous deployments means for production deploys for master, that step is automated. So that's a saving (in engineer time) of around 40 seconds per deploy. Over the last month over 1400 deploys were made via continuous deployment.
This means from a developer productivity perspective roughly 2 engineer days per month (1400 deploys * 40 secs per deploy / 3600 to get into hours / 8 hours per day) ) are being saved as a result of this change.
However this is really a side benefit. Our real motivation for making this change was to ensure that all master builds are deployed, and that each of our ~500 micro services is always on latest master.
This is to reduce developer anxiety of deploying over a branch build and thus minimize stress around making change.
The productivity side benefit is pretty nice though!
This is somewhat intentional I think to guide you toward buying Enterprise edition, which since 11G includes plan baselines ( see https://docs.oracle.com/cd/B28359_01/server.111/b28274/optpl... ) - which allows you to lock a SQL queryID to a specific plan.
At the company we're using EE, and I've heard about the plan locking functionality, but I never dared to use it.
Does it survive DB-restarts? Additionally we have a setup of an active/primary cluster that is replicated to a passive/secondary one in our secondary datacenter (which then becomes leading in case of a disaster in the primary datacenter) => I don't think that a locked plan is replicated to the secondary cluster (which, in a case of a disaster would become a 2nd disaster as many SQL all of a sudden would stop working).
We’re looking for engineers who understand how good tools can shape company culture, and who are passionate about creating tools and automation to develop and improve the platform that underpins BuzzFeed.
Email me - andrew.mulholland@buzzfeed.com - with any questions, or apply directly to the job specs above.
Indeed. And considering the hundreds of millions[1] of people who pass through london’s stations each year, that would means hundreds of thousands of false positives.
While I agree with the aspiration, I don’t see how it’s possible to use facial recognition to flag “america’s Most wanted” or to look for missing children without mass surveillance though?
It only works if it scans _everyone_ .
Additionally what happens when the technology isn’t perfect and innocent people get mistakenly flagged as persons of interest?
The other thing is once it’s installed and in operation, what’s to stop it being used for other purposes? - being used to target people peacefully protesting against the government or whatever.
And that’s the argument the grand-parent is making. It’s a tool. It can be used for good or bad. There are other tools like that.
Because of that, there’s unlikely to be universal acceptance or rejection. And without popular opinion, it will be hard to pass any laws that change the status quo.
CCTV cameras are already ubiquitous. That ship has already sailed. And honestly, there was never an expectation of privacy in public in the first place.
CCTV cameras monitored by humans are COMPLETELY different from a facial recognition system recording the identities and movements of all people. There is no comparison.
There absolutely is an expectation of privacy in public. Being seen in public by a series of uncoordinated people is massively different from a PI tailing you and recording your actions. This form of privacy is generally termed "obscurity".
> Being seen in public by a series of uncoordinated people is massively different from a PI tailing you and recording your actions.
That is actually completely legal to do in all circumstances, precisely because there is no expectation of privacy in public.
> CCTV cameras monitored by humans are COMPLETELY different from a facial recognition system recording the identities and movements of all people. There is no comparison.
Which is not necessarily how facial recognition would necessarily work. More likely would be to scan for known suspects and fugitives. But then we’re back to the “how is it used” question.
It is legal for a PI to tail you not because of the lack of expectation of privacy in public, but because it is impractical to have PIs tail everyone all the time in public. People are generally okay with targeted surveillance. Mass surveillance is the issue. Quantity has a quality all of its own, as they say. There has been a court case which addresses this issue[0].
Any technology which searches for fugitives will necessarily scan everyone. There is no such thing as targeted facial recognition, it can only work by mass surveillance.
You're assuming facial recognition would necessarily be the moral equivalent of "[having] PIs tail everyone all the time in public.". But for that to be the case, facial recognition would have to scan every face it sees, store that face, and then cross-reference every other face it sees against every face it has ever stored.
I'm suggesting a far simpler use case: It scans your face and if you don't match any of the fugitives it's looking for, it forgets about you. I think this use case is far more likely because it's a lot simpler and cheaper to pull off. And that's a big difference.
“When the animals are ill, chemically synthesised allopathic veterinary medicinal products including antibiotics may be used where necessary and under strict conditions. This is only allowed when the use of phytotherapeutic, homeopathic and other products is inappropriate.”
My own experience ( North east US) has been somewhat different recently.
Yes routes from Apple maps, may appear longer or more convoluted at first glance. However after using it ( due to CarPlay) for a while on routes I had previously regularly done using google maps, I inferred a reasoning for that.
On the ~90 minute journey to my in-laws, the predicted journey time, is generally advertised as being quicker on google, but in practice the time difference is marginal.
What was different in my experience anyway, is that Apple maps seems to try to minimize left turns where appropriate.
The benefit being a noticeably less stressful journey.
I can’t speak to left turns, but someone attempted a careful evaluation of the turn-by-turn options and Apple’s estimates were generally more conservative, leading to the conclusion that you point out, that Apple looked slower but wasn’t.
As a recurse alum (s14 batch 2) I loved reading this. I loved my time at recurse and learned lots. This highlight from the post really resonates:
“ Real growth happens at the boundary of what you can do and what you can almost do. Used well, LLMs can help you more quickly find or even expand your edge, but they risk creating a gap between the edge of what you can produce and what you can understand.
RC is a place for rigor. You should strive to be more rigorous, not less, when using AI-powered tools to learn, though exactly what you need to be rigorous about is likely different when using them.”