301–310 of 316 posts
Earlier quoted context omitted.
I’ve seen loads of very bad/wrong code written by humans
> I’ve seen loads of very bad/wrong code written by humans Have you seen any pink elephants?
Earlier quoted context omitted.
> When you want to build a bridge you finalize all the blueprints and then someone goes and actually pours concrete Construction has plans "as designed" and "as built".
Fair enough, but “as built” is usually not the original intent
Earlier quoted context omitted.
> It's not supposed to be a bible that implementation can't deviate from. It's a plan, not law. It's okay for the plan to be adjusted in contact with reality. My point is that without writing, you can't surface the type of problems you usually surface. The AI isn't going to surface those problems for you. It's rare when reviewing that you think "Oh shit, this approach is totally wrong, we need to throw it away", whil…
> It's rare when reviewing that you think "Oh shit, this approach is totally wrong, we need to throw it away", while it's common when writing code to have that reaction. That's not my experience. It is actually very common for specifications and design to be reviewed and improved.
I think there may be crossed wires here - specs and designs are reviewed, but I've never seen a code review result in a spec+design review, while I always see spec+desiogn review happen during the "writing code" phase.
In short, reading code does not result in a spec+design review, writing code does. If you are not writing code and only reading it is unlikely you will trigger a spec+design review.
Earlier quoted context omitted.
The traditional name for this spec is ‘source code’ — a canonical source of truth for the behaviour of a system that is as human-readable as we know how to make it, that will be processed by automated tools into a less-readable derived artefact for a computer to execute. Checking the compiled artefact into the codebase without checking in its source code has always been a risky move!
A specification, whether formal or less formal, is very different from the source code.
Earlier quoted context omitted.
> Why is the vibecoding crowd still holding onto the idea that markdown (or here yml) is a better spec then code? From your comments it sounds like you are oblivious to the whole problem domain. The whole point of these tools and frameworks is to provide a high level description of not only what features are already implemented in a project but also and more importantly what features you want to implement. To put it…
Oh I've researched it and did two projects entirely like that, both scaled to 150k loc and I believe 90k loc last summer to fall. That approach just doesn't scale unless you don't care about your product whatsoever, hence my comment I've successfully been working on various personal projects with highly stable functionality since I stopped that approach and instead focused more into leveraging my codebase to become t…
At this point, why not just write the code yourself? Defining exactly what the product is supposed to do is the hard part, writing code is the easy part. Write your specs as code and you have your product - why let your LLM do the fun part?
Just because I am capable of "writing all that code", doesn't make the option preferable to defining a vast majority of spec up front and having an LLM generate an implementation. I am already going to spend the brain power on reviewing the code. I am already going to spend the brain power on pontificating edge cases, external module interactions, and next steps. Why not fast forward to that point and save 80% of the…
is it possible that you might be in a job that’s not right for you?
it sounds like you want to cut out 80% of your job. if you want to cut out 80% of your job, maybe you’re doing the wrong job? y’know?
like, i read this comment and my mind goes to project/product manager who has real experience of coding. going from a spec (tickets / design docs / customer feedback notes / epics / stories / whatever) to a working implementation (team of engineers build it and you don’t have to use brain power). it sounds like you’re describing turning your job into the job of a PM.
we need more PMs like that in the industry. good PMs are few and far between, good PMs who know what’s it’s like to code — even fewer. so maybe have a think about why you’re working this way? i don’t really care if you do or don’t, but future you might be glad if you took some to think about it.
Author here, if you don't want to read all that, I'll post one excerpt that I think sums it up nicely: > My point is, the spec must live somewhere, even if you don’t write it down. The spec is what you want the software to be. It often exists only in your head or in conversations. You and your team and your business will always care what the spec says, and that’s never going to change. So you’re better off writing it…
The traditional name for this spec is ‘source code’ — a canonical source of truth for the behaviour of a system that is as human-readable as we know how to make it, that will be processed by automated tools into a less-readable derived artefact for a computer to execute. Checking the compiled artefact into the codebase without checking in its source code has always been a risky move!
Why is the vibecoding crowd still holding onto the idea that markdown (or here yml) is a better spec then code ? Seriously, it's just not Write your code like it's your spec and your software will be more stable, maintainable clearer to read. Code is not transient, it is your friggin spec itself And if your code isn't structured like it's a spec, then your code is garbage from the perspective of LLM driven developmen…
Most 'programmers' cannot read or write code very well (or reason about structure or architecture) and so they want to 'program in english'.
Earlier quoted context omitted.
The traditional name for this spec is ‘source code’ — a canonical source of truth for the behaviour of a system that is as human-readable as we know how to make it, that will be processed by automated tools into a less-readable derived artefact for a computer to execute. Checking the compiled artefact into the codebase without checking in its source code has always been a risky move!
The source code is not the specification, the source code is an implementation of the specification. The specification tells you what happens, the source code tells you how it happens. Ideally you also have some additional documentation for the why.
Grindmaxxing, a long form blog post that is actually just an advertisement for his website.
A tried and true content marketing strategy. The 100+ upvotes suggest he's doing something right.