Anecdotally, I find Google's AI Search results to be genuinely helpful much of the time, and the box isn't so intrusive that it prevents me from digging into literal search results if I am not satisfied with the AI summary.
Brazil has a huge advantage in that they've required full transaction-level transparency for tax authorities -- with clearly defined technical requirements -- for almost 20 years now. One can argue whether it's a pro or a con to share this level of detail with the federal government, but it certainly makes taxation easier and fraud prosecution simpler, too.
I would virtually guarantee that any Chromebooks for Education versions of these new devices would be hobbled by restrictive data sharing policies forcing the disabling of the Gemini Intelligence features.
Also, most schools purchase the most abysmally low quality Chromebooks for students, which cost in the $200-300 range in bulk orders. They're awful.
Absolutely. I also hand-edited HTML (and XHTML and CGI scripts and Java applets) back in those days and the majority of web pages were no more than a few hundred lines of code long. Regular notepad.exe was absolutely fine at home, and I did a lot of editing server-side in vi. It was a simpler time....
One thing I've been doing lately -- and I'm in a business function, not a technical one, although I have an engineering background -- is pitting LLMs against each other. For example, if I'm structuring a proposal or a contract with the assistance of Claude, I'll begin my 360 feedback review first by asking Claude how it would react if it were the counter-party receiving the proposal. After some iterative changes, mostly manual, I will then run the same output document past Gemini and ask it to adopt personas from both sides and provide reactive feedback. The result of this is almost always a stronger proposal that I can also accompany with proactive objection handling and a solid FAQ, as well as clear points of negotiation that will likely be acceptable to both parties.
For this sort of thing, using multiple LLMs is extremely helpful.
It would probably help you to compare what you can do on a phone vs what you can do with desktop software (Lightroom/Photoshop, DxO, Topaz, CaptureOne, etc). It's generally quite good, with the exception of challenging liminal areas (e.g. hair, foliage).
Fwiw, Topaz -- which I have a license for but essentially never use -- has pretty incredible denoising & upsizing features (for both photo & video), but to get the optimal quality output you offload the processing to their cloud infra (and buy credits from them to pay for it). It's roughly the equivalent of a SWE using a local LLM that's good enough" vs a frontier model that's SOTA but requires a consumption-based subscription.
I've got a 61mp camera, and an RX 7900XT. It takes about 15s/picture for DXO to denoise, which is a lot longer than people are willing to wait on a phone to take a photo. Topaz is even slower. A cloud service could be used to do it in post, but someone has to pay for that.
Yet in modern computer games, modern graphics cards denoise a scene in real-time at 60 frames per second using machine learning models [1][2] while doing all the other rendering at the same time. Granted, that's ray tracing, and the resolution is lower, and they technically cheat by using additional information, but it might be that DXO is not optimized very well.
Games will typically un at 4k or less which is about 8mp on the other hand it’s difficult to buy a stills camera with less than 20 mp, and >40mp is common. Most algorithms are n^2 in graphics as well so we wouldn’t expect a linear speed up. I’ve tried dxo, Lightroom, and topaz they all perform about the same so I don’t think it’s particularly unoptimized.
For Android, you can sort of get some of this with Snapseed. I occasionally use it, and it's "ok". I'm more frustrated by the fact that my preferred RAW editor (DxO) doesn't handle Android's DNG files. For me, at least, editing raw images on a phone screen is just not tolerable.
Meetings are one type of forcing function. Anything with concrete, time-bound deliverables is a forcing function, too. In a well-managed organization with trained & competent staff, it should not require meetings to ensure progress.
Some meetings, especially one on one, can be useful. It's very hard to say no to someone you've met, especially when your only other interaction is over the phone, email or chat.
Recurring meetings, especially at the developer level, are a waste of developer time.
I always found it easier to walk around, get personal updates one on one and integrate the information.
That way I wasted only a few minutes of each developer's time, instead of boring them all for an hour per week.
> That way I wasted only a few minutes of each developer's time, instead of boring them all for an hour per week.
I've been in companies where a standup with 6 people takes 45 minutes.
The company I'm in finishes standup with 8 people usually within 10 minutes and often enough within just 5 minutes.
The companies have very different approaches to information sharing. The first wants in-depth information and for everyone to have opportunities to speak up to offer help. A true team effort is what they want. The second wants everything to be as brief as possible, so you can get back to doing what you're paid to do.
I saw a lot more "progress" at the second company. I also saw a lot less collaboration and more "oops we need to fix this now" happening too -- even into production.
The first company definitely did things a bit slower. But that slower generally translated to better quality software: software that generally worked correctly on the first try, or problems were at least caught before reaching production. When an issue did arise in production, it could be safely and quickly handled and rarely with downtime, because rolling back was part of the extensive test suite.
Coming to truly understand the differences between approaches has been eye-opening, and has seriously changed my biases about "how" to go about writing software on a day-to-day and week-to-week basis. Collaboration is good, but you have to have buy-in from the developers for it to work well. That was key and it took a lot of convincing each developer of the benefits.
reply