this is my fear regarding AI - it doesn't have to be as good as humans, it just has to be cheaper and it will get implemented in business processes. overall quality of service will degrade while profit margins increase.
The point was that for many tasks, AI has similar failure rates compared to humans while being significantly cheaper. The ability for human error rates to be reduced by spending even more money just isn't all that relevant.
Even if you had to implement checks and balances for AI systems, you'd still come away having spent way less money.
Given the current lower bound of one passenger in personal vehicles the process for using driverless cars needs to incentivize car pooling to the point that the average occupancy of traveling cars is considerably above 1 to make up for all the cars taking up road space while empty.
There is a possibility of municipalities having many mid to large vans that do routes at higher frequencies because they don't need drivers.
Doesn’t solve the underlying problems that are caused by having car-centric cities. Walkable cities where most people’s needs are meet within walking distance and the mass transit for times you need to further is the real solution.
Agree on walkable, although I really like the idea of personal public transport that would be door-to-door and on-demand. I expect it would distribute cities more, and alleviate the hub-and-spoke model that public transport is sometimes built to, e.g. Dublin, Ireland.
Which would still cause traffic issues, wasting public land on building more roads and wasting energy and resources. Plus propping up the auto industry that caused the problem in the first place.
I am amazed at the number of engineers I've worked with who jump straight into the full implementation. I've done it myself on a few occasions thinking "how hard can this be".
Building the "toy" first is great.
In my experience, about one third of the time the toy is all you need, you can stop there, and what you were going to build fully would be over-engineering. About one third of the time, building the toy tells you you're taking the unworkable approach as you mentioned. And the other third of the time you can extend the toy.
I have a directory on my drive called `sandbox` where I basically throw together small toys for anything with some unknown complexity. Anything from how an ORM might model a specific type of relationship (throw together a basic replica with a Docker compose file) to replicating the deployment model (poking AWS Copilot, for example) to testing out some tooling flow (e.g. local build process change).
The main thing with a toy model is speed. You can build/deploy/test with a smaller scope and progressively scale it up some reasonable scale of the full thing (whatever you're testing for) and you can iterate your testing faster. But many times, the key issues show up quite early in the process of grokking the toy model.
I too have this "sandbox" directory. I use it for what you say. But also for troubleshooting, bugreports or a stackoverflow question.
Just throw up a new project, hack around in it for an hour, and most often the problem/bug in my original code becomes apparent because of the isolation. I'll easily write four such sandbox projects per week.
Nothing wrong with that if the toy meets all of the functional and non-functional requirements.
If you find offense to this, the easiest way to mitigate is with process and practice: sandbox code goes into a dedicated "Sandbox" mono-repo and if it's suitable for production, you rebuild it appropriately in a production repo.
Exactly. That's why I don't build the toy anymore: Too many broken promises of "Yes, we won't put it into production until it's ready", and then my team is left maintaining a system in production that had no business of ever being in production.
> In my experience, about one third of the time the toy is all you need, you can stop there, and what you were going to build fully would be over-engineering.
On the flip side, the cases where the toy ends up being promoted to production service end up being riddles with technical debt, missing features, and buggy behavior that jeopardizes the whole project, also happen.
Survivorship bias is also a major problem. It's easy to presume that the winning bet you took is the right path.
One problem of scale here is that unless a tooling investment has made literally 100% of the work easy, most of a developer's workweek almost by definition winds up spent on the remaining slow and hard problems.
So investing in tooling certainly improves productivity, but whether it can make things "fun" depends on which categories of hard/slow problems a given developer enjoys.
Well, they weren't Google-wide teams, they were teams for specific platforms/areas within Google. So I don't have any experience scaling it to 100k SWEs.
But in many cases it's a question of prioritization and polish. Just as an example, it's very easy to cut corners on API design for internal customers - unless the TL of the devex team is in the room. Or sometimes there are cross-cutting technical issues that no one really owns and no one will prioritize addressing, in part because of the relatively high organizational overhead of doing so and ambiguous ROI...unless the org has specifically staffed a devex team to search out and fix such issues.
Light switches and steering wheels never work properly in my dreams. I have to concentrate really hard to get things to follow the rules. Then I wake up.
Nope, nope, nope. Light switches never work properly in my own dreams either, but I find that testing the lights or just even noticing they aren't working is a guaranteed one-way trip to night terror land, even in adulthood. Not even realizing I'm dreaming is enough to stop it at that point.
That's quite a line-up they have! I have a Elephone S3 pro, two day battery is really great when traveling, no worries. I'll strongly consider an Ulephone next..
The long tail of people buy the long tail of coins.
I bought coins when I first discovered them, driven by curiosity mostly.