Hello. OK. I give. I'm sick of twitter. I'm looking for cool people to follow. Point me at good accounts?
My interests are #design #neuroscience #3dimaging #datascience #softwaredevelopment #research #uiux #hci and #art
Hello. OK. I give. I'm sick of twitter. I'm looking for cool people to follow. Point me at good accounts?
My interests are #design #neuroscience #3dimaging #datascience #softwaredevelopment #research #uiux #hci and #art
#Perl: older than some #programming careers, younger at heart than you think.
It’s evolved a lot since 1999 — modern features, cleaner syntax — yet it still runs code you wrote decades ago.
(And if you’re wondering: #Perl6 was renamed Raku in 2019 — it’s a sister language, not a successor.)
Curious? Returning after a long break? @shiar’s cheat sheet is a perfect quick‑scan: https://sheet.shiar.nl/perl
#coding #SoftwareDevelopment #SoftwareEngineering #RakuLang #Perl5
If you don’t have the resources to write and understand the code yourself, you don’t have the resources to maintain it either.
Any monkey with a keyboard can write code. Writing code has never been hard. People were churning out crappy code en masse way before generative AI and LLMs. I know because I’ve seen it, I’ve had to work with it, and I no doubt wrote (and continue to write) my share of it.
What’s never been easy, and what remains difficult, is figuring out the right problem to solve, solving it elegantly, and doing so in a way that’s maintainable and sustainable given your means.
Code is not an artefact, code is a machine. Code is either a living thing or it is dead and decaying. You don’t just write code and you’re done. It’s a perpetual first draft that you constantly iterate on, and, depending on what it does and how much of that has to do with meeting the evolving needs of the people it serves, it may never be done. With occasional exceptions (perhaps? maybe?) for well-defined and narrowly-scoped tools, done code is dead code.
So much of what we call “writing” code is actually changing, iterating on, investigating issues with, fixing, and improving code. And to do that you must not only understand the problem you’re solving but also how you’re solving it (or how you thought you were solving it) through the code you’ve already written and the code you still have to write.
So it should come as no surprise that one of the hardest things in development is understanding someone else’s code, let alone fixing it when something doesn’t work as it should. Because it’s not about knowing this programming language or that (learning a programming language is the easiest part of coding), or this framework or that, or even knowing this design pattern or that (although all of these are important prerequisites for comprehension) but understanding what was going on in someone else’s head when they wrote the code the way they wrote it to solve a particular problem.
It frankly boggles my mind that some people are advocating for automating the easy part (writing code) by exponentially scaling the difficult part (understanding how exactly someone else – in this case, a junior dev who knows all the hows of things but none of the whys – decided to solve the problem). It is, to borrow a technical term, ass-backwards.
They might as well call vibe coding duct-tape-driven development or technical debt as a service.
🤷♂️
AI is intellectual Viagra
One issue I'm noticing when learning Go is that the idiomatic nature of the language is making the learning process more difficult for me than C++ or C#.
With C++/C# you can focus on how to write code and then how to design code, but there is a very tight coupling of these concepts in Go that is taxing my brain and pretty much forcing me down the tutorial route, which I tend to struggle with compared to the language reference route.
It's nonsense to say that coding will be replaced with "good judgment". There's a presupposition behind that, a worldview, that can't possibly fly. It's sometimes called the theory-free ideal: given enough data, we don't need theory to understand the world. It surfaces in AI/LLM/programming rhetoric in the form that we don't need to code anymore because LLM's can do most of it. Programming is a form of theory-building (and understanding), while LLMs are vast fuzzy data store and retrieval systems, so the theory-free ideal dictates the latter can/should replace the former. But it only takes a moment's reflection to see that nothing, let alone programming, can be theory-free; it's a kind of "view from nowhere" way of thinking, an attempt to resurrect Laplace's demon that ignores everything we've learned in the >200 years since Laplace forwarded that idea. In that respect it's a (neo)reactionary viewpoint, and it's maybe not a coincidence that people with neoreactionary politics tend to hold it. Anyone who needs a more formal argument can read Mel Andrews's The Immortal Science of ML: Machine Learning & the Theory-Free Ideal, or Byung-Chul Han's Psychopolitics (which argues, among other things, that this is a nihilistic).
Well now...
Don't know how much attention any of you pay to #Mastodon #SoftwareDevelopment, but this is very interesting:
Off Github:
Person MJ:
"IMHO community/contributor communication has gotten worse and decreased from an already pretty minimal point in the last few months (with the exception of your engagement on this issue).
There has been basically no progress around the stagnant portions of the backlog.
If the reality is that you do not want external assistance, I would encourage you to just admit that publicly, update the docs to reflect that, close non-team-originated PRs/issues, etc."
Person ES:
"FYI, Andy resigned, so not sure who the point person is for this now"
Person AP:
"Some personal news... after an amazing 3 years working with the Mastodon team, first in developer relations and then as communications lead - it’s time for me to move on (after April 28). It’s been a privilege to work on something as meaningful and important as the Fediverse. 🧵👇🏻 (1/4)"
The most underrated skill isn't knowing how to use every new tool - it's knowing which ones to ignore so you can actually get some work done. #SoftwareDevelopment
Do you want to help testing @badgefed and provision your local test instance?
Easy
docker pull ghcr.io/tryvocalcat/badgefed:latest &&
docker run -v `pwd`/data:/app/data \
-p 8080:8080 \
-e SQLITE_DB_FILENAME=/app/data/badges.db \
-e AdminAuthentication__AdminUsers__0__Id=your-mastodon-username \
-e AdminAuthentication__AdminUsers__0__Type=Mastodon \
-e MastodonConfig__ClientId=your-mastodon-client-id \
-e MastodonConfig__ClientSecret=your-mastodon-client-secret \
-e MastodonConfig__Server=your-mastodon-server \
ghcr.io/tryvocalcat/badgefed
And then open a browser and go to http://localhost:8080 or http://localhost:8080/admin
#docker #badgefed #openbadges #softwaredevelopment #testing #fediverse #activitypub
I am conducting an #survey about EditorConfig for my master's thesis, which is open until the 30th of June 2026. All people with #coding experience can answer it, independent of if they know EditorConfig already or not. The term "coding" refers to writing #code, which can be #programming code or text files for #itAdministration.
Survey link: https://cryptpad.adminforge.de/form/#/2/form/view/lwnCcr15eNcH+zCUMZMEaAed6m5xh37b6+0bdS-XkZE/
Boosts and sharing the link via other channels is welcome.
🧵 (1/2)
Automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer.
I realized that if I was writing a program and it didn't always work, I had a choice: I could either fix it, or call it AI.
Welp. I've been using GitLab for over a decade and have been pretty happy with it. Deployed and maintained several instances, some personal, some for small hobby orgs, some for work.
But it looks like it is time to ditch GitLab for good:
> Software will be built by machines, directed by people. AI is the substrate on which future software gets built. Agents will plan, code, review, deploy, and repair.
https://about.gitlab.com/blog/gitlab-act-2/
Been experimenting with a way to browse post replies right within the main feed as a threaded view. You can click on each post or navigate using A or Z to go up and down.
Feedback would be awesome before I get to far down the rabbit hole on making sure it's all wired up.
#elefeed #mastodonapps #software #mastodon #mastodonclients #feedback #softwaredevelopment
"Organizations aren’t burning millions or hundreds of millions of dollars a year on AI because it’s good, they’re doing it because they are run by people who do not know what the fuck they’re doing.
Generative AI is catnip for hall monitors, snitches, toadies, and any other group that hates work and loves talking down to others. Put another way, it ingratiates losers who believe that learning to do or being good at something is a waste of time, because they deserve to just do what they want without any of that messy “effort.”
While I’m not saying every LLM user is an imbecile, they’re built to convince the mediocre and incurious that they’re remarkable, and it turns out that a great many of them run venture capital firms and Fortune 500 companies.
I also want to be clear that while there are sane and normal people who use these things, they’re mostly drowned out by a crowd of people that oscillate between bootlicking and regurgitating capitalist mythology in a way that makes it hard to trust anybody who spends significant amounts of time using an LLM.
One thing you’ll notice about the most moistened AI boosters is that they lack much degree of pride in their work. Everything they say must, at some point, compliment the mindless, unprofitable, unreliable tool underneath it — how “incredibly powerful” it is, how it’s “only getting better,” how it’s “only the beginning” of something that’s eaten over a trillion dollars and absorbed the majority of venture capital."
https://www.wheresyoured.at/the-revenge-of-the-business-idiot/
#AI #GenerativeAI #LLMs #AIBullshit #AIBubble #AIHype #Programming #SoftwareDevelopment