twitchard's comments

Coreutils gets updates regularly! https://gitweb.git.savannah.gnu.org/gitweb/?p=coreutils.git

Even `ls` gets news flags from time to time.

I think "stopping" is great for software that people want to be stable (like `ls`) but lots of software (web frameworks, SaaS) people start using specifically because they want a stream of updates and they want their software to get better over time.

Not sure DORA is that much of an indictment. For "Change Failure Rate" for instance these are subject to tradeoffs. Organizations likely have a tolerance level for Change Failure Rate. If changes are failing too often they slow down and invest. If changes aren't failing that much they speed up -- and so saying "change failure rate hasn't decreased, obviously AI must not be working" is a little silly.

"Change Lead Time" I would expect to have sped up although I can tell stories for why AI-assisted coding would have an indeterminate effect here too. Right now at a lot of orgs, the bottle neck is the review process because AI is so good at producing complete draft PRs quickly. Because reviews are scarce (not just reviews but also manual testing passes are scarce) this creates an incentive ironically to group changes into larger batches. So the definition of what a "change" is has grown too.

Re: model Supremacy -- I think there's so much cross-pollination between the AI labs that this is unlikely. Everybody at these labs basically know what everybody at the other labs are doing. *data* can be hard to get but I don't think acquiring good data is positive feedback loop-y where whoever wins just skyrockets away from everybody else.

Model stagnation, I thought stagnation was coming last year, then Opus 4.5 came out. I think maybe the models are slowing at getting *smarter* per se, but they are still getting better at coding. And even if they stopped getting better at coding, if they got as good as they have gotten at coding on other fields of inquiry (like, say, writing) so I think we've got a ways to go yet before the progress in terms of economic usefulness slows down.

I don't think 10 minutes of AI experience is enough to be a master? AI-assisted software engineering is a skill that I want to get better at, just like traditional software engineering is.

Twice as fast, half as costly, too!

Why do you think that the human mind can contain semantics but a machine cannot? This argument needs some sort of dualism, or what Turing called "the objection from continuity" to account for this.

FWIW I don't think that the "triangularity" in my head is the true mathematical concept of "triangularity". When my son e.g. learned about triangles, at first the concept was just a particular triangle in his set of toy shapes. Then eventually I pointed at more things and said "triangle" and now his concept of triangle is larger and includes multiple things he has seen and sentences that people have said about triangles. I don't see any difficulty with semantics being "a matter of image", really.

Why do we believe that semantics can exist in the human mind but cannot exist in the internals of a machine?

Really "semantics"

I had come across this Catholic philosopher: https://edwardfeser.blogspot.com/2019/03/artificial-intellig... who seems to make a similar argument to this; i.e. that it's the humans who give meaning to things, "logical symbols on a piece of paper are just a bunch of meaningless ink marks"

> What Turing was trying to do, is to isolate this "hard problem of consciousness" and separate it from easier problems we can actually answer.

Yes exactly. As a computer scientist this is a great thing to do, science is all about taking mushy concepts like "intelligence" and extracting simplified versions of them that are more tractable in technical settings. The trouble is, Turing doesn't seem to want to stop at merely arguing that forgetting about interior consciousness is useful for technical discussions -- he seems to think that interior consciousness shouldn't be important for philosophical or popular notions of thinking and intelligence, either, and that they should update to use something like his test.

So even if you updated the Turing Test for 2025 the church would probably still be writing "Antiqua et Nova" to remind people that -- yes, interior consciousness exists and is important and robot intelligence really isn't the same as human intelligence without it.

Crazy how many voice AI related updates there were this week. Grok voice mode, Alexa+, Hume OCTAVE, Elevenlabs Scribe SST... big day for Voice AI!

Crazy how many Voice AI announcements there were today: - Octave - Alexa+ - Elevenlabs "Scribe" speech-to-text

This is all coming on the heels of Grok 3's voice mode last week.

A paragraph like

> ...I am clearly worse than almost everyone that emails me along all of these dimensions. I only have a dim understanding of how my 3-4 years of experience coming from a strong background in psychology has rounded to "senior engineer", I've only ever written tests for personal projects because no employer I've ever seen actually had any working tests or interest in getting them, and I wrote the entirety of my Master's thesis code without version control because one of the best universities in the country doesn't teach it. In short, I've never solved a truly hard problem, I'm just out here clicking the "save half a million dollar" button that no one else noticed. I'm a fucking moron.

comes off to me as false modesty in the context of an essay that characterizes the majority of industry colleagues as "drowning sleepwalkers." Take it as a criticism of your writing persona, not a personal insult. You are right that I can't read minds, only the text in front of me.

I am glad you are mentioning specific books about software here in the comments. The essay had a very thoughtful and detailed discussion of books about drawing. If it had kept that energy when it turned to discussing software, instead of retreating into taking potshots at "the average developer", consultants, etc., it would come off to me like a persuasive essay rather than a self-congratulatory smugpiece.

Let me get this straight: you can be better than 90% of people if you just read a book, but wait, not just any book, it has to be the right book -- and also it doesn't have to be a book, it can also just be "lived experience" or technical documentation, that counts too.

At this point, the thesis is more qualification than statement. Mostly what I drew from the article is that the author feels smugly superior to many of his peers, and wants an excuse ("they didn't even read a book") to morally blame them for their (perceived) shortcomings, while serving up a generous helping of false modesty on the side.

What people actually mean by "data" in a phrase like "data-driven" is fungible observations that you can do quantitative analysis with.

Yes in some sense "a podcast I heard once" is data, but nobody means that when they say "data-driven".

And what about emotions? If I (subconsciously) choose not to hire somebody because they have an asymmetrical face or are "ugly", this is 100% a "gut feeling". I suppose you could say that it's based on "data" in the sense that my DNA which gave me my face preferences is "data". But at this point you have stretched the meaning of data too far. You could even say that the Earth is being "data-driven" when it orbits the sun (the data being the initial trajectory of the Earth at the time of its formation).

Congratulations to Alex and team! Had the pleasure of working with Alex on SDK generators back in 2019 and 2020 and it's very exciting to see these ideas and the fruits of this become available to the entire world. Stainless would definitely be where I looked first if I were starting a developer-facing SaaS today.

You are judging Jenkins favorably because it is possible (with a bunch of arcane knowledge) to build good CI on top of it.

I am saying you should judge Jenkins disfavorably for being hard to use instead of going "skill issue" when somebody describes the pain points.

This is "the worst part of Jenkins is that it works".

You shouldn't judge a developer tool by just what is possible to do with the tool. After all, with a little turing-completeness it is possible to do anything with anything -- you should judge the tool by what is easy to do with the tool. A good developer tool shouldn't require knowledge of a bunch of arcana to "configure correctly". A good tool protects you from "rookie mistakes" and makes sane choices the intuitive and obvious path of least resistance. Good tools can have a learning curve, but they assist the learning curve by making their abilities easy to discover and experiment with, they don't require you to dig into source code or do random searches on github to find some random pipeline somewhere that uses the configuration you need, as described in the post.

Yup. I think this is the sort of perspective you get with experience.

Submitter's is a way better title imo

To illustrate "build build steps" with an example: I used to work on a project that had 1000s of Javascript files, that we compiled into a dozen or so webpack bundles to deploy. Not every webpack bundle depended on every file however. We wanted incremental builds, i.e. so that if you changed one Javascript file, you wouldn't always have to rebuild all 12 bundles (which took like half an hour) -- if only one webpack bundle included the file you changed, you should only have to rebuild that one.

You can get webpack to output a list of all the Javascript files that it used in building a particular bundle, but the list wasn't fixed from one build to the next. You could add new files or add import statements to create new dependencies. This is the situation the paper calls "dynamic dependencies".

We used "Make" to run our builds, and the way that we had incremental builds was, we had one main Makefile, and one of the tasks in the Makefile would run webpack, parse webpack's output, and literally write a bunch of sub-Makefiles to disk, describing the dependencies between webpack bundles and javascript source files. These Makefiles would then be imported into the big Makefile when a change was made and the next build was run so that Make had the dependency information and could decide whether a particular webpack bundle was stale or not.

Wanted to describe this, just in case a specific example helps you conceptualize what endgame calls "build step that builds build steps".

Incidentally, Make really sucks and this some of the buggiest, hard-to-debug, code I've ever worked with.

After reading 'Build Systems a la Carte' I decided to try reimplementing our build with Shake to capture the dynamic dependencies. The proof of concept worked like a charm and was an absolute pleasure to write, though I left the team before actually deploying it, for real. I hope the poor folks that came after aren't still wrangling Make...

Any stories to tell about compiler analogies being taken too far in web apps?

Wrong. I've been a hiring manager at a place with >100 engineers and a recruiting team and

- I still read every resume

- I ignored the keywords

- I pretty much valued exactly what the author does.