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).
I recently had a discussion with a coworker about commit messages. And I wonder what guidelines developers prefer.
Past tense example (Django):
https://docs.djangoproject.com/en/5.1/internals/contributing/committing-code/#committing-guidelines
Imperative example:
https://github.com/RomuloOliveira/commit-messages-guide/blob/master/README.md#good-practices
Conventional/Semantic:
https://www.conventionalcommits.org/en/v1.0.0/
and
https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
Maybe other styles?
#programming #git #gitlab #github #codeberg #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)