What requirements don't you have?
20 points by nolan
20 points by nolan
This post resonated with me because it matches my experience with AI code review and what I call "epicycles". If you give too much credence to AI code review, you'll waste time on bizarre corner cases like "What if it's 2am at Daylight Savings Time and it's a leap year and…" Whereas if you don't give enough credence, you'll miss obvious bugs or fail to notice when your whole design is off and the number of Criticals and Highs should alert you to that. It's a weird sort of balance to decide when enough bugs are enough.
A good chunk of my time is spent doing performance work, especially in customer facing applications. There is one engineer I’ve worked with where I definitely know more about code performance in the abstract, but he’s been helpful because he has a very good knack for seeing the case where we shouldn’t even try to optimize, we should just work with the product team/customer to say “let’s not do this” or “let’s change your workflow.” I’ve learned a lot from that collaboration—it’s really easy to have your first instinct be “let’s make it faster without making users change what they’re doing.”
I’ve also seen this happen in reverse, where the product manager desperately tries to convince an engineer that some level of stale data is acceptable, while the engineer digs their heels in and insists on the “perfect” system.
I'm in this footnote and I don't like it.
The talk about simplifying one's requirements reminds me of some stuff I've read about Forth. It has a reputation for very compact code, and I think part of it is technological. But as far as I can tell, a large part is also cultural: the way of Forth is to identify your actual goal and to aggressively simplify everything else that stands in the way.
solo developers or startups […] can make design tradeoffs that would be impossible for a large company, enabling them to build systems that are far more elegant and powerful.
I don't want to idolize Chuck Moore, but doesn't that at least echo the legends around his accomplishments? You too can write your own semiconductor CAD software, solo—you just have to be so laser-focused that even infix notation seems like a distraction.
Sean Goetze has been on a tear for a few weeks with several good posts about the intersection between developing with AI and 'corppolitik':
It's a great blog!
Separately from constraints on future design, when I was responsible for a moderately complicated system it was very useful to sit down with internal users making feature requests — to discuss what are the true real requirements.
Often the outcome was to configure together something existing and already un-deprecatable, while slightly adjusting the planned workflow!
(On a less optimistic note, «what balls can we mostly-safely drop given the deadlines» was a recurring discussion, too)
So even for a given overall design it can just consolidate the code and reduce waiting-for-implementation issues…