AI is an improvement.
72 karma · joined July 2, 2024
AI is an improvement.
I think the message the team lead takes away right now is "oh, this can be done a lot faster, let's do more!" This is exciting for a bit, but I think it comes at the cost of learning -- and being able to communicate --architectural lessons that would stage off systemic issues later.
The wealthy/owner class once again consume all of us -- here through AI -- because we cannot agree to work together.
People -- WANT -- this technology on their home devices and (apparently?) the providers of this tech don't seem to be running a profit so they probably don't want the maintenance tail on their side either.
I think it's a bit different. Inevitable that this becomes a household-run thing? Not likely.
Presumably it's a simple matter to send something back to a server, but I've really never thought about the mechanisms involved.
And the details involved in closing some of the rest of that loop do not seem THAT complicated.
Because my own introduction was through combinatorial game theory, I always get excited to see some hackenbush diagrams and rarely do when the subject is mentioned.
And... Then I remember it's rage bait.
Better to just read a book.
Avoiding tax through various loopholes that Capital gets a seat at the table to help craft, while benefitting from externalizing the costs to taxing labor is just corruption.
IEE754 does a good job explaining the representation, but it doesn't define all the operations and possible error codes as near as I can tell.
Is it just assumed "closest representable number to the real value" always?
What about all the various error codes?
It's one thing of we're talking food production and housing. Completely different if we're talking McDonald's happy meal toys.
Like, does the same argument apply to noise pollution? Are we alright installing a factory next to the symphony hall so long as the factory "owns" their land?
I think as our technology and understanding of the world grows we ought to change with it.
For me: I decided I could just slow down a bit. Standing out isn't worth the stress. I don't want to slack, but I don't feel compelled to cram productivity into every moment.
A few years in and I feel "back on my feet", but it was harder for being older.
"Assembly Theory" is a sort of applying (kolmogorov-esque) complexity theory to physics and other natural sciences. I don't know much else beyond that it's a "real thing".
So with that extra background, I give it a pass. I think it's an interesting idea at least.
Morality isn't a consideration.
The system must be understandable or people wouldn't incorporate and collaborate on extracting an edge. Slack in the system represents a lower price point, which will be corrected by a corresponding purchase order.
An individual has an effect, but it's miniscule compared to the massive forces in play. Unless you have a TRULY novel analysis of a situation, you are going to have a very low probability, success rate and out competing the market.
My understanding is the notion is about getting an application to "work" without any underlying theory of operation or evaluation of the imported context.
Becoming expert at a tool like git involves building familiarity with the concepts involved. While it's not entirely hidden in the --help and manual pages, the descriptions provided there do not consistently use higher levels semantic descriptions of the transformations. You are REQUIRED to look elsewhere to understand or worse -- develop a privately held theory of what's actually happening.
Culturally, a lot of engineers have a basic ethos of "getting things done". Getting the job of the moment done is a "win". There are tons of how do do XYZ articles that are separated from "why" and unmarried from useful additional context.
Like, one should be proud of learning a new tool, but it shouldn't be a personal endeavor to conquer Everest. I think it would do a LOT of good for tools -- especially collaboration tools -- to have completely standard introductions that the community enforced in collaboration. "Oh you don't know XYZ? You probably haven't read the standard introduction."
I think the reality is less like a switch and more like there are just certain jobs that get easier and you just need fewer people overall.
And you DO see companies laying off people in large numbers fairly regularly.
If you're an engineer focused on shipping product, probably not. It's not TERRIBLY useful for most day to day coding tasks.
I would argue some understanding of theory is absolutely necessary if you want to make any significant tide change in CS. It's just that most people won't (myself included).
I am aware of being able use hardware counters for profiling systems, but the more fine-grained exposure of what's happening at a lower level seems to be just hidden... Or I haven't found the right reference resource yet.
It would be interesting to collect a roadmap for optimizing software at scale -- where is there low hanging fruit? What are the prime "offenders"?
Call it a power saving initiative and get environmentally-minded folks involved.
Incentivize the behavior... somehow... and hope for the best.
I missed out on so much because I never pushed back on management who asked me to do X, Y, or Z. "Oh, that's the priority" I'd tell myself. Nope, that was their ass getting promoted by managing a bigger team.
Repeatedly hearing "we don't do X, Y, or Z" when I saw an opportunity to innovate. Nope, that was just an uncreative bored person who didn't want to play along.
I simultaneously feel so lucky to be where I am and so absolutely frustrated at how poorly run and disorganized EVERYTHING seems to be.
I've decided in the next phase of life to kind of do like you suggest. Focus on "the doing" of something I like.
I may even have that opportunity, but my area is facing a lot of instability lately, so I hope it works out.
But, oh boy: we have trouble with simple plurality voting. How would you explain the outcome to people if it was implemented broadly?