Hacker News Reader

Comment by mpd | Hacker News Reader

I've always been a bottom-up programmer, so I tend to think more about discrete operations of software rather than the user-facing features (which IME will fall out naturally).

1. Experiment and solidify architecture before adding features. I think this is the hardest step for top-down thinkers.

2. Heavy testing and benchmarking. Prefer to TDD as much as possible. The actual lines for my agent-written codebases are generally ~70+% tests, benchmarks, and experiments.

3. Full mutation test coverage after the code is written. Doing this as a human is miserable IMO, but robots make it reasonable. This step resolves SO MANY subtle bugs.

At that point my main role is ensuring alignment with the actual specs.

View on HN

Yeah I feel like what you say makes sense. Part of my issue comes from the fact that we're a pre-PMF startup, so rapid experimentation and prototyping really matters at the moment with very little room left for deep thought around testing and benchmarking.

The trouble comes later when the "experimental features" actually start getting traction and we discover all the holes in our implementation.

By the time we need to "productionize" our experiment, it has already been patched all over the place to account for bugs.

I get a feeling that this is made worse by the fact that since a lot of what we're doing is rapid prototyping, our repo is cluttered with examples of bad code that the agent picks up on and then goes ahead to copy in its own implementation.

I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle

One of my mantras is 'fast is the best UX'. Users will put up with minor annoyances as long as they're over with quickly. Once you fix the annoyances, you're still fast, which leads to User Delight.

> I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle

Enumerate, then fix-or-nix all known examples of bad code first. If you clear the path first, you will advance more quickly. It can feel frustrating having to do that, but my experience is that paying off tech debt earlier will prevent hitting the wall at an inopportune time.

If you’re pre PMF then don’t worry about code quality. (Seriously)

Pump out features and iterations as fast as you can until customers are buying your product.

Startups fail because they can’t find customers, not because their code quality is low.

Reply on news.ycombinator.com