I think it's a drivers market. When the ridesharing apps cannot afford to fire drivers in fear of losing market share, that allows the drivers to pull of scummy behaviour for maxing profit. I heard uber drivers go out of their way for 5 star reviews in America. Sounds like the balance of power is on the plaforms side over there and in some specific markets in Europe.
There is a reason to go the extra mile for juniors. They eventually learn and become seniors. With AI I'd rather just do it myself and be done with it.
But you can just do it once with AI. It’s just a script process that you would set up for any project. It’s just an on boarding process.
And I’ll know by when I say do it once I mean, obviously processes have to be it on to get exactly what you want out of them, but that’s just how process works . Once it’s working the way you want to just reuse it.
unless your goal is to give yourself a fat income and sell your useless company for a bunch of money to some other speculator, pretty soon you’re a “serial entrepreneur with multiple successful exits” and ready to be a CEO
Browse some job postings if you haven't for a while. Its even worse among job ads where just about everything posted out there is on working on some LLM project. It is so lopsided I wouldn't be surprised if the numbers were a lot more than 1/5 for job postings in tech.
How do you define an AI doomer? I’m wondering if I’m one too.
My position is that I think AI is an amazing tool, but that’s it. It’s like any other tool we humans have developed before – we use it to create more quickly, with less effort.
Personally, I don’t think we’re anywhere close to achieving AGI, and I find the tech bros’ AGI fantasies appalling.
That would already be great progress. For context Ubisofts the Crew shutdown only after 3 months of stopping sales.
It could also work as a deterrent on making dedicated servers only architecture. If you can disable dedicated servers instantly(instead of 2 years) but enable private servers that might be more cost efficient.
Why not apply it to Saas? If you sold lifetime licenses and you don't want to run it anymore, just let your customers self host it. Even better if you can open source it.
You shouldn't blame consumers that you failed to negotioate proper terms for your licenses. Maybe having legislation to point at will help you out to get more reasonable terms.
It depends on the domain. Any complex long lived mutable state, precise memory management or visual rendering probably benefits from debuggers.
Most people who work on crud services do not see any benefit from it, as there is practically nothing going on. Observing input, outputs and databases is usually enough, and when it's not a well placed log will suffice. Debuggers will also not help you in distributed environments, which are quite common with microservices.
Is there a name for an approach to debugging that requires neither debuggers nor print calls? It works like this:
1. When you get a stack trace from a failure, without knowing anything else find the right level and make sure it has sensible error handling and reporting.
1a. If the bug is reproduced but the program experiences no failure & associated stack trace, change the logic such that if this bug occurs then there is a failure and a stack trace.
1b. If the failure is already appropriately handled but too high up or relevant details are missing, fix that by adding handling at a lower level, etc.
That is the first step, you make the program fail politely to the user and allow through some debug option recover/report enough state to explain what happened (likely with a combination of logging, stack trace, possibly app-specific state).
Often it can also be the last step, because you can now dogfood that very error handling to solve this issue along with any other future issue that may bubble up to that level.
If it is not enough you may have to resort to debugging anyway, but the goal is to make changes that long-term make the use of either debuggers or print statements unnecessary in the first place, ideally even before the actual fix.
Debuggers absolutely help in distributed environments, in the exact same way that they help with multithreaded debugging of a single process. It is certainly requires a little bit more setup, but there isn't some essential aspect of a distributed environment that precludes the techniques of a debugger.
The only real issue in debugging a distributed/multithreaded environment is that frequently there is a timeout somewhere that is going to kill one of the threads that you may have wanted to continue stepping through after debugging a different thread.
A different domain where debuggers are less useful: audio/video applications that sit in a tight, hardware driven loop.
In my case (a digital audio workstation), a debugger can be handy for figuring out stuff in the GUI code, but the "backend" code is essentially a single calltree that is executed up to a thousands times a second. The debugger just isn't much use there; debug print statements tend to be more valuable, especially if a problem would require two breakpoints to understand. For audio stuff, the first breakpoint will often break your connection to the hardware because of the time delay.
Being able to print stacktraces from inside the code is also immensely valuable, and when I am debugging, I use this a lot.
Really depends on the region and any pre-existing constraints at the time of electrification. A better distinction is probably rapid transit (metro, subway, the Tube, MTR/MRT) vs commuter rail.
Apparently in the US there are trains that use dual rail and overhead power, one for subway and another for overground portions.
I suppose a subway train with rail only supply that goes overground sometimes is more dangerous because it is easier to accidentally step on a rail and rail is powered?
Not in Tokyo. All but the first two of Tokyo’s subway lines run on overhead wires. In fact they had to build most of the subway lines to suburban rail standards because they planned on operating through services in the beginning.
