sdiupIGPWEfh

Personally, I think I'd rather be unemployed at that point.

Please pardon my cynicism for a moment. No doubt AI will be able to replace a majority of software engineers at some unspecified point in the future. However, I suspect an embarrassingly large number of companies will jump the gun and attempt to pivot to AI generated code prematurely. The results will crash and burn, possibly literally, and some market segments will be hit with lawsuits so hard that they'll effectively be barred from using AI to write code for several decades. Meanwhile, the less critical industries will crank out buggy AI crap that works 90% of the time because it will still be more profitable than hiring engineers. And everything will suck until the AI overlords are finally advanced enough to completely take over.

It amuses me that this would be not unlike teaching an LLM with picture books.

That has me wondering now.

It's absolutely true that children learn (and even generate) language grammar from a ridiculously small number of samples compared to LLMs.

But could the availability of a world model, in the form of other sensory inputs, contribute to that capacity? Younger children who haven't fully mastered correct grammar are still able to communicate more sensibly than earlier LLMs, whereas the earlier LLMs tend toward more grammatically correct gibberish. What if the missing secret sauce to better LLM training is figuring out how to wire, say, image recognition into the training process?

Furthermore on the matter of being irreplaceable, having been there at times, I've found it to be incredibly stressful bearing such responsibility and knowing it confers no actual job security makes it feel even worse.

It's arguable. No one is so valuable that they could never be let go, laid off, or fired, regardless of circumstance. That much is true, sure. But I have certainly seen projects veer off course, wither and die, or else crash and burn due to a coworker's involuntary departure. They were irreplaceable. Not that it saved their skin. Projects with a bus factor of roughly 1 happen from time to time, so the person who happens to equal that factor is de facto irreplaceable. The organization will move on as if everything's fine, but the loss of certain individuals may be far more expensive than anyone in charge is willing to acknowledge.

Would it be anywhere near as contentious if folks weren't either constantly misinterpreting the scale of the original study involved or else going No True Scotsman to death on the definition? Would anyone care as much if the job interview process in our industry wasn't also infamously infuriating? Or if enough of us weren't familiar with egotistic assholes whose productivity wasn't necessarily the result of any particular innate skill? There are a lot of confounding factors for any given anecdote.

Whether there's any fundamental truth doesn't much matter, everyone wants to bend the idea to fit their own agenda.

Competent management would know the language of those they're managing. Given incompetent management, you're already playing a losing game.

"What is the Matrix?"

On a good day, I'd say we do it because it can be fun and rewarding. It's an escape from the regular daily grind; something beyond the drudgery of say React, CRUD, the frequent silliness of business logic requirements, or whatever the mundane might be at your own workplace. It can also earn us the respect of those peers whom we ourselves respect the most. A knowing smile and a nod between us is priceless. Maybe we each count ourselves lucky that at least we were spared the other's tribulations.

My own efforts don't quite earn me "the big bucks" that I read about at companies I'll actually never work for. Just a respectable east coast income that I shouldn't complain too much about. Don't know that I'd be happier anywhere else anyway. The bills get paid while I'm making the world a better place.

On a bad day, I'd say we do it because we're suckers for punishment. It's in our nature.

> A side observation here is that usually the original author (sometimes long-departed or departing) understands very well the limitations/flaws of the original system/implementation, but can be excluded from the design of the replacement for any number of misguided reasons.

I relate to this so much. I'd offer an open letter to some poor anonymous soul who inherits one of my dumpster fires. Because I'll certainly never be given the chance to revisit anything.

Yep, my shit's broken. It was written long ago, under different constraints, for a different audience. I made the best trade-offs I could. I documented them! Though you'll probably never find my writings, and if you do trip over them, you won't understand them yet. Today, I'd scrap most of it if given the opportunity. But to whomever is now taking on the rewrite, you know that little nugget at the core which perplexes you so? The one that doesn't fit your mental model of any type of programming you've touched in your career? That there is the core value proposition that makes it all possible, and if you throw that out, you've doomed yourself to learning my wisdom the hard way. If you're at all up to the task, then the next few years of your life and the remainder of your days at this company will be spent fixing the same problems by reading the same papers and obtaining the same obscure domain knowledge. No, it can't be abstracted away. Yes, it's fundamental. No, no one else will really understand it either when you try to explain it, because no one else without the accountability you now have will sink enough of their time into building the mental model you've had to construct. Good luck.

Yes, the term "Mixed Reality" had some academic use going back that far, but I'd interpret that article and its citations quite differently.

These early MR references use the term to mean a spectrum from "Augmented Reality" to "Augmented Virtuality". The AV term never really caught on, and the Wikipedia link for AV [1] actually just redirects to their page for MR [2]. I can't think of many notable examples of AV at the moment, though something like "Mario Kart Live: Home_Circuit" [3], as mentioned on the Wikipedia page for MR [2], might fit the bill, in the sense that reality is being used to augment the game. Uses of haptic feedback in VR might also count as AV.

This usage of MR has nothing to do with how Microsoft began using the term. It's almost as if they embraced an academic term for the sake of marketing, extended the meaning, and successfully extinguished the original academic definition.

[1] https://en.wikipedia.org/wiki/Augmented_virtuality

[2] https://en.wikipedia.org/wiki/Mixed_reality#Augmented_virtua...

[3] https://en.wikipedia.org/wiki/Mario_Kart_Live:_Home_Circuit

Personally, I actively reject this distinction between AR & MR. For as long as I've been aware of the concept, the term "Augmented Reality" covered both use cases, including virtual objects embedded into the real world. The distinction never struck me as interesting or useful; virtual objects embedded into the real world being the most useful way to interact with augmentations to the real world.

Moreover, "Mixed Reality" strikes me as marketing-speak. Compare the search trends for AR [1] vs MR [2]. While both terms have been in use for a long time, AR was always more prevalent, with a notable rise in interest around 2009. My first encounter with the term MR was in marketing materials for Microsoft's HoloLens circa 2015. Now compare the search trends for MR [2] with HoloLens [3]. Searches for MR don't begin to trend upward until after the introduction of HoloLens, where Microsoft's marketing materials tried to make a big deal of said distinction and the rest of the world started to run with it. As a supporting argument for the original broader usage of the term AR, I'll cite discussions of a 2007 anime series, Dennō Coil [4], which explored various examples of fantastical AR usage. Probably just a coincidence, but the search trends for Dennō Coil [4] do precede the search trends for AR [1] rather closely.

Naturally, all the usual caveats about word meanings changing over time apply, but this one is a pet peeve of mine.

[1] https://trends.google.com/trends/explore?date=all&geo=US&q=%...

[2] https://trends.google.com/trends/explore?date=all&geo=US&q=%...

[3] https://trends.google.com/trends/explore?date=all&geo=US&q=H...

[4] https://trends.google.com/trends/explore?date=all&geo=US&q=%...

> It tests for that generic and general ability to estimate anything, and to break down any problem.

Ability to BS and multiply, more or less. Feels like a waste of a question even for the one asking it!

> Yet some people get flabbergasted . . . since they think too much about specifics of each of the numbers they use and how wrong they might be. Basically, they have a hard time of letting go of the inaccuracies :)

Having a hard time letting go of inaccuracies seems justified if you're in a more technical profession. Too often there's good engineering reasons for not wanting to excuse loose reasoning with bad guesses. On the software dev side, there are also too many cases where those kinds of fudged numbers are inevitably used against us.

I usually find myself being accused of making things over-complicated while I'm explicitly trying to simplify an already over-complicated system. Quite often there's some elegant unifying concept, one capable of expressing all the desired complexity, that's been overlooked while everyone's kept busy piling on new feature requests. But solving the root problem, no matter how simple compared to the existing pile of unmanageable code, is always more complex than just adding the next shiny button, so no one ever wants to do it, even if means never having to manually add another shiny button ever again.

More specifically, certain works featuring Mickey Mouse may actually be hitting the public domain. Mickey Mouse himself is trademarked, and there's no limited duration on trademarks.

> I don't think there's anything inconsistent about this.

It amounts to saying that anything that benefits me is good and anything to my detriment is bad. Sure, there's a consistency to that. However, if that's the foundation of one's positions, it leads to all manner of other logical inconsistencies and hypocrisies.

Communities that generate and/or profit off of "intellectual property" ought to have a rudimentary understanding of the laws involved. Doubly so if they're protesting what they see as violations of those laws. It honestly does not take a lawyer to understand the distinctions at play here.

> Would you mind if AI starts creating art like yours?

The law isn't there to protect my feelings, so whether I mind or not is irrelevant. Artists have had to deal with shifting art markets for as long as art has been a profession.

> What if your clients tell you they bought the AI generated art instead of yours?

I'd be sad and out of a source of income. Much the same way I would be if my clients hired another similar but cheaper artist. The law doesn't guarantee me a livelihood.

So they're protesting alleged copyright violations in the form of AI copying artistic styles (presuming an artistic style alone rises to the level of copyright protection) by committing trademark violations? Yeah, I don't get it.

I can appreciate that there are all kinds of potential "intellectual property" issues with the current glut of AI models, but the level of misunderstanding in some affected communities is concerning.

Does anyone have examples of "good" OKRs for a developer / individual contributor worth sharing? Typical guidance I've seen is either generic to the point of uselessness or else involves numbers that are just completely outside the control of anyone in my role. The alternatives amount to one for one copies of Jira epics, which are too susceptible to the whims of product management or else personal growth stuff which is the first thing dropped when crunch time comes knocking. The obligation to write individual OKRs feels like providing a list of reasons to deny promotions when plans inevitably change over the course of an evaluation period. It's as if it were all smoke and mirrors for management to justify whatever it is they already wanted to do with you.

They're fine enough for aligning the work of few related teams, but OKRs suck when forced on individuals as the focus for regularly scheduled performance evaluations.

My experience matches yours, and I wanted to call that out with more than just an up-vote. The ticketing system is where rework goes to die.

In an engineer-led environment without a project management class calling the shots, maybe I'd feel different, but whoever is ordering the backlog is always going to prioritize features and fires, because that's what drives their own career advancement.

Unless you're in a Scrum team and "The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering." is taken to mean that the PO has the final say on what's prioritized. If your PO has a project manager title, as most do, and they see their career advancement is tied to shipping features on or ahead of schedule, then indeed, that ticket will be forever ignored.

No one's trying to hide anything. The target users of project management systems, product owners and anyone with with a project manager title, typically neither care about nor understand the value of rework. In their view, the dev teams should be creating maximum value at all times, which they understand as either adding features or putting out fires. Rework tickets do not get prioritized until they're identified as the cause of lost value.

The inevitable question is "well why wasn't it written correctly to begin with?" even if the reason, as is typical, was pressure from product managers in the first place.

> instead track work on a ticket

Where it will never be picked up, because rework tickets never get prioritized over feature work until something breaks.

And when some future engineer comes along and asks themselves why the hell this code is the way it is, they'll have to git-blame, dig through commits, find PRs for commits, hopefully find referenced ticket numbers, read those, and play archeologist to try to reconstruct whether there's good reason for the existing code's being from those indirect signals. Whereas a simple "TODO" could just tell said future engineer what they ought to know.

I sincerely appreciate a well-written TODO, and I make every effort to write good TODOs for others.

Really wanted a 2nd set of Robot Inventor, and now it's both discontinued and sold out everywhere. Ugh.

It gets tiring playing word games to avoid the suggestion that certain natural pressures have personal agency.

Water "wants" to flow downhill. Gasses "want" to expand to fill their container. Genes "wanting" to replicate drive animals literally wanting to reproduce, and the incidental awareness of that drive in some species comes down to a certain molecular arrangement brought about by said genes. The genes are data, the minds are data, and the natural pressure is that that data which succeeds in reproducing will tend to keep reproducing. So in the original sense of the notion of memes as proposed by Dawkins, yes, information "wants" to be free, as that is its tendency. The only other option is that said data ultimately dies out.

We'll just call what the construction workers are already doing a "stand-up" and have them estimate work while they're standing there. Then we'll ask them to report on progress every morning, while holding them to the original estimate. All we need to do is write a manifesto, design a bunch of indecipherable workflow charts, name our system after some sports term or silly acronym, sell ourselves out as agile construction coaches, and watch the sweet consulting money roll in.

Granted, I suppose "orangutans in suits" would have made for a more accurately-inaccurate analogy. Though perhaps to drive it home further, if you squint, orangutans are just fuzzier people who don't reproduce uncontrollably and spread environmental disasters so much.