A major part of my job (and this was true before the "AI boom") is saying no.
No we can't call the CRM from our client side using a static bearer token even though their docs say we can. No we can't simply switch to Postgres even though it supports 99% of the same SQL we currently use. No we can't simply block usernames which are "clearly" profane.
But if we can chat about it, then we can see what the REAL problem is, and then we can come up with a fitting and simple solution.
The problem is that I have an AI colleague who is way more energetic and willing than I am. They love to talk, they seem to ramble on endlessly about any subject. And its the kind of solution oriented talk my PM loves to hear. And indeed my <insert senior role here> talks to them (or really, lets them talk), and draws up a comprehensive and confident plan to do X. I pick up the plan and discover problems with X, let alone the plan to do it.
I feel nervous about raising issues with X or going through the plan again though, because my other human colleagues are already speeding through the work for Y and Z that my AI colleague is aiding with.
And so maybe I'll raise my biggest concerns with X and not sweat the small stuff. Maybe next time I won't raise my neck at all, noting the gleaming axe sitting in the corner.
* The IT crowd season 1 had leetspeak and base64 encoded subtitles (won't spoil what the encoding decodes to).
* Goodfellas has a commentary track with the central criminal and the FBI agent who arrested him.
* The Simpsons (around season 9 if I recall) has a hidden commentary track (not accessable by menus) where two of the writers fairly candidly explain the quality dip that was to follow, and have an impromptu phone call with the illusive John Swartzwelder.
I’m not sure the Simpsons one was hidden. I watched all the commentaries a while back and if I remember correctly the one with the John Swartzwelder call was accessed just through the ordinary menu.
The problem is that there really is limited space in a DVD, and if you care about the actual movie, you want as much bitrate as possible. Some DVDs can look almost HD with enough bitrate.
So no, I don't want animated menus or worthless features. Put a commentary track - that has high extra value to size ratio - but leave it to that.
It depends really on what you actually want to do. I tend to make a few helper funcs for different kinds of things I want to do. For example, a helper funcs to accept anonymous job funcs and collect output. Then you can compose programs out of those higher level blocks.
I know many programmers for whom "developing domain understanding" is an abstract concept (if indeed, it is a concept for them at all). But in the age of big AI, I see more need for this, not less.
At least this is my observation: when my colleagues have been wholesale chucking stuff over to Claude, they've then been confronted with classic XY-Problem shit, poor user experiences, and over-complex solutions (which will mount future problems regardless of whether a person or an agent iterates on that code). Much of this can be solved by actually sitting down and thinking about it, and I mean at a code design level, not just a speccing level.
Many people don't realize that there are more useful outputs to solving a problem than just a mere solution. Obviously if one has a contractor mindset (you don't care about the after effects of a system) then this is of no relevance to you. Some companies promote that mindset, certainly ones that have no broader aspirations then getting acquired soon. That's fine - but many companies actually are about sustainability, and understanding in these places is paramount.
Agree 100%, especially with your second paragraph. The majority of domain experts I've interfaced with in my own domain, along with things I am not an expert in, are typically experts not because of the solutions they build, but because of the things they _don't_ build. It is the cliche "a clever person solves a problem, a wise person avoids it" paraphrase.
But I think what is lost is the value in (a) person(s) who intuitively spots and avoids these problems. My hypothetical example that I have seen play out: The domain expert spots one of these problems and succinctly explains that the problem doesn't need to be solved. Maybe it's a byproduct of bad design elsewhere, or there is a much better solution that avoids it altogether. Once the rest of the team/the lead catches on, either hindsight bias or outcome bias, or a combo, takes over and they don't recognize that all the value all along was in the person being able to spot this situation. They throw that in claude and claude does it's sycophant thing (after expressing that the previous situation was flawless for however long), and they are off to the races right back to automation bias with zero pause for thought...
To me, "domain knowledge" seems to resemble a primitive form of "slop filter" to use the modern parlance. In any field, the majority of possible ideas are slop. This has always been the case. People somehow learn to navigate through the slop, to find things that are worth working on.
Even before the AI era, we were flooded with a veritable DDOS attack of slop, in our in-boxes, meetings, etc. Managers believed that innovation was held back by quantity of ideas, or by the domain experts being "resistant to change." This led to day-long group brainstorming sessions that yielded nothing. Part of the transition from student to junior to senior is learning to filter your own ideas, and to guide others in the search for ideas that are likely to be fruitful.
The criteria for slop filtering have always been subjective, arbitrary, or driven by institutional culture. That's what we've got. Any means of generating ideas produces slop in the absence of filtering.
What will slop filtering look like when the AI can generate tera-proofs per second? What does it look like already for our e-mail inboxes? We are asymptotically trending towards slop filters that look more and more like "ignore everything." I already read none of the business memoranda that I receive. I don't answer my phone. The number of workers needed to read and assess business memoranda is zero.
The slop filter still functions in math. Problems are pre-filtered for being of interest. Somebody expressed enough interest in the Navier-Stokes problem to give it a name and attach a prize to it. There are still plenty of "prize problems." Here are some:
* Quantum gravity
* Improvement of superconductors that don't need helium
> Part of the transition from student to junior to senior is learning to filter your own ideas, and to guide others in the search for ideas that are likely to be fruitful.
I wonder how that'll change over time now. I think it's pretty important to have a few instances of thinking hard to come up with ideas and being totally convinced they are correct, only to have someone else trounce them with one or two succinct thoughts of their own. Those were very big personal development moments for me. And equitable, I still have folks with a lot less exp/time come out of left field with maybe not as formulated, but amazing ideas.
I had an agent (SOTA models, xhigh reasoning, etc.) write and optimize some CUDA code recently. They've gotten a lot better at this stuff. And yet, they couldn't (self-)realize the obvious issue with their code: it was written as if for a typical multicore CPU. What the heck was a (serial) queue doing there? "Work efficiency" as a tradeoff for stalling 20k threads. Its later proposed optimizations were all about "can we get the queue faster" rather than "maybe we should actually parallelize the work for our very-parallel processor".
Funny stuff, as if it were hell-bent on writing a paper rather than actual software.
Sometimes a session just goes bad and is best abandoned or rolled back to before it went off the rails. I've also been using agents to write and optimize CUDA (and the C++ app code) recently and didn't run into anything so braindead. But, I had one session recently where the LLM started making duplicated tool calls and just couldn't stop doing it. Had to generate a handoff and start again in another session and haven't run into that specific problem again. I don't remember specifics at this point but once and I while I have to rollback a session a half dozen turns when its clear the agent had gone completely off the rails.
I have a strong belief (mostly borne out by my years as Java dev) that the larger the possibility space of a language (and its ecosystem) the more room there is for inappropriate use and unclear code. Add time and an assortment of rolling devs of mixed ability level, and crap mounts faster then a "simpler" language.
Let me be clear: Do I think it is possible to write good, clear, performant code in Java? Of course - Java can be used to write great software. The problem is that in Java there exist an extraordinary set of variations of a sufficient implementation, many of which are package protected abstract static horrors shows. And that will manifest over time if you add different individual developers. Else the project must engage in bureaucracy and control, where you have meetings over style conventions or hardline architects who come to constrain the joy of programming in the devs.
Its much better when the language itself constrains you, then everyone can just move on. I feel Go, though certainly not perfect, meets this niche.
Golang tried to be simple, but reality hit and they started adding features (generics, and now generics on method, iterators, fixed loop variable scoping). Yet when you program in it, you can feel so much resistance because it took a naive approach to simplicity.
Also - and this is very subjective - I find developers who have similarly low view of software development and high view of simple languages, to be very good team mates. We can laugh at the realities and move on pragmatically.
I see. I tend to agree in principle. I felt this with julia for example and it put me off a bit even though I was very keen on it at first
In the specific case of java however I don't think this applies much; the vast majority of improvements are aimed at under the hood optimisations rather than syntax. And I feel that any changes in syntax have been quite incremental, intuitive, and reasonable.
AND they stay around as preview features forever, so this may inflate the perception of features entering the language, when in fact it's the same one feature being mildly iterated on.
E.g. the main syntactical change in this version seems to be the use of primitives in switch statements, which was already discussed for a while, and is itself a meaningful change brought about by the introduction of switch expressions.
Honesty does not just mean reporting facts. It also requires having an understanding of the scope of your knowledge and then endeavouring to communicate that scope effectively.
No we can't call the CRM from our client side using a static bearer token even though their docs say we can. No we can't simply switch to Postgres even though it supports 99% of the same SQL we currently use. No we can't simply block usernames which are "clearly" profane.
But if we can chat about it, then we can see what the REAL problem is, and then we can come up with a fitting and simple solution.
The problem is that I have an AI colleague who is way more energetic and willing than I am. They love to talk, they seem to ramble on endlessly about any subject. And its the kind of solution oriented talk my PM loves to hear. And indeed my <insert senior role here> talks to them (or really, lets them talk), and draws up a comprehensive and confident plan to do X. I pick up the plan and discover problems with X, let alone the plan to do it.
I feel nervous about raising issues with X or going through the plan again though, because my other human colleagues are already speeding through the work for Y and Z that my AI colleague is aiding with.
And so maybe I'll raise my biggest concerns with X and not sweat the small stuff. Maybe next time I won't raise my neck at all, noting the gleaming axe sitting in the corner.
reply