At the time, they were right; it was as good as society had ever been.
I think they were much like us in many ways. They probably imagined that things could get better (even if they didn't imagine electricity or computers).
I agree that a lot of the noise at the moment is an emotional reaction to LLMs, rather than a dispassionate assessment of how useful they are. It's understandable - they are changing the way we work, and for lots of us (software developers), the reason we chose this career was because we _enjoy_ writing code and solving problems.
As with a lot of issues in today's world, each side is talking past the other. It can simultaneously be true that LLMs make writing code less enjoyable / gratifying, and that LLMs can speed up our work.
A top recommendation along these lines is The Worst Journey in the World by Apsley Cherry-Garard; a member of the Scott expedition to the south pole, which goes into detail of his winter journey (which the title refers to). One of the best historical adventure books I've read
There's a disincentive to actively block PRs if you don't want your coworkers to think you are a bad colleague / not on their side. So you often see suboptimal code making its way to production. This has a worse effect the more terrible engineers there are.
Except in this case it's clearly affecting at minimum the rest of OP's team.
At that point it's not one person being obnoxious and never approving their team members diffs and more of a team effort to do so.
But at minimum if you have a culture of trying to improve your codebase you'll inevitably set up tests, ci/cd with checks, etc. before any code can be deployed. Which should really take any weight of responsibility out of any one member of the team. Whether trying to put out code or reject said code.
It gives you control over the output of your program (and as you mention, the exact error code - which probably should be 1 in this instance).
It's often more user friendly to print a short human-readable message (or nothing) than to dump a huge stack trace. YMMV, if this is an internal dev tool then the opposite might be true!
I really like the short and visually descriptive layout of this article. It clearly conveys the message. I'm not in agreement that toasts are always bad though.
It can be useful to follow an expected pattern; users are likely to understand that a toast gives feedback for an action they have taken. Although other ways exist to accomplish this, they will follow different formats depending on the action (by necessity).
As with lots of design, expected patterns change over time. Although they are non-local, toasts are familiar.
All very good and useful points. One additional thing to mention is that as you are querying across the raw data with a data lake(house), performance is fundamentally worse, even if a lot of the marketing material will tell you otherwise. Usually significantly worse than if your data was in a columnar database in practice.
Depending on your use case this may or may not be a problem. For most companies I'd wager that it is a bigger problem than it first appears.
reply