236 karma · joined September 2, 2015
[ my public key: https://keybase.io/twitchard; my proof: https://keybase.io/twitchard/sigs/I5UrA9A9raeyLpi3JFePKPI9LW-Ys_gpnfa5xMZz6iE ]
I used it to try and work with my Obsidian and my GitHub but mostly I ran into snags with its permission model, basically there's no way for it to do anything useful here because it gets all weird about credentials.
I did eventually use it to successfully make some purchases but mostly I think it has been more of a time suck than a time saver.
Why don't we visually emphasize the verb in a sentence and deemphasize articles and prepositions, for example?
In prose the author can *bold* or italicize text to emphasize ad-hoc, or make ## headings for scanning. Why can't we do such ad-hoc emphases in code?
This week's encyclical didn't go into this. Last year's "Doctrinal Note" (less authoritative) did though: https://www.vatican.va/roman_curia/congregations/cfaith/docu...
and I did a write-up on it here: https://twitchard.github.io/posts/2025-06-28-the-catholic-ch...
404 This page could not be found.
Clearly they did delete it.
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.
"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.
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.
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"
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.
This is all coming on the heels of Grok 3's voice mode last week.
> ...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.
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.
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).
I am saying you should judge Jenkins disfavorably for being hard to use instead of going "skill issue" when somebody describes the pain points.
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.
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...
- I still read every resume
- I ignored the keywords
- I pretty much valued exactly what the author does.
Based on experiences with the same generator at Stripe that Alex (founder of stainlessapi.com) built.