bignose

@cube_drone@mastodon.social

I'm a grown-ass adult

This simple statement is strong justification for not using TikTok

My guess is the bosses are keeping an eye on the total personnel cost, not merely the salary. And they probably also factor in features like “LLMs don't think about collective bargaining”, and “LLMs are far less likely to say an idea is unethical or stupid”. But even that threshold will, I guess, be exceeded too by the mounting costs, pretty soon. @benno@eigenmagic.net

They also don't know how much to pay the armed guards to ensure the guards won't just ignore their orders and take over the bunker. @Hex@kolektiva.social

An #LLM, as provided today, no. They are all trained on data for which they do not respect copyright; they all use gargantuan scarce resources in training and inference; they are proprietary and centralised and any dependency on them is begging to be exploited. It's never okay to take part in that. But AI existed long before LLMs, and will continue long after the LLM bubble pops. It's fine to use an AI (e.g. spell check) that doesn't have those problems, to analyse documents for errors. @evan@cosocial.ca

No, but it's fine to share a *link to* the post, and a representative *text quotation* from the post. Screenshots of a mostly text medium are less accessible, less useful, and much more annoying, than directly quoting the text and linking to the post. @evan

@evan

I don't think he likes it that much. […] it's also a huge pain in the ass.

Both of those were manifestly true throughout his first term. Yet here we are again.

If those were reason enough to convince him to walk away from it, I very much doubt he'd have squealed so much at leaving the first time, nor come back for a second round.

@mkb

Put your hand into the box @evacide

And thinking a thing through, before doing it, is high cognitive effort. Much higher than diving in and flailing about to get a result, any result.

Which is not to say that exploratory coding ("dive in and get a result, any result", and learn iteratively from that) is bad! It's often a very good way to learn more.

What it isn't though, is good design. Experimental code that does something is far too often deployed, without acknowledging that no deliberate design ever happened.

@emilybache@sw-development-is.social

@emilybache@sw-development-is.social

why is [TDD] hard to learn?

An optimistic explanation for this is:

Because in order to prevent wasting time on bad code, bad design, and bad requirements understanding, TDD mandates to think through what you're going to do, in detail, and think of how you'll verify you're right, before writing any more application code.

And thinking a thing through, before doing it, is high cognitive effort. Much higher than diving in and flailing about to get a result, any result.

@emilybache@sw-development-is.social

why is [TDD] hard to learn?

There can be various reasons for this. Two that come to mind:

• Many people learning to program have lots to take in. They frequently don't learn writing tests until much later. Habits have then calcified and it's difficult to un-learn the code-first process.

• Many people are coding in institutions that have "just get something deployed, now!" as a driving imperative, often unspoken but it's what gets rewarded. TDD deliberately interrupts that.

@emilybache@sw-development-is.social

"TDD is actually easier than writing the tests afterwards"

My hope is that this expresses a wise position: That completing the problem will entail figuring out all the APIs and internal dependencies anyway. So to do each of those up front (with a failing test) before writing the code, exposes many mistakes without the effort of writing the code. Hence, easier overall.

A lot less time and effort overall, yes; I don't think I would express that as "easier", though.