[skydhash]

> Rust, strong types, enums, fantastic interfaces, brevity.

That's not what suitable data structures/algorithms mean. What you stated are mere helpers and still pertains to the realms of coding, not design.

Coding isn't and never was the issue. It is a tool and not the intent. Think about what would stand universally true whether you use Go, C, JavaScript, Assembly,... The organization of data (information), and the process of transforming it (computation).

Those do not depends on code. We already have basic ones like the list, the map, the stack, the queue, the binary tree, the graphs,... But for any business domain, you can create more specific ones. And like the basic one, they do not depends on code. The code depends on them.

So writing code faster does not make the design better.

[fragmede]

No but it lets you iterate faster. Who hasn't come up wit the most perfect elegant design, only to come up against three reality of implement and an "oh we forgot about that" aspect. Except by then, it's too late to change, so you march on. Writing code faster lets you find the things you didn't think of faster so then you get to design it again but better this time.

[skydhash]

> Who hasn't come up wit the most perfect elegant design, only to come up against three reality of implement and an "oh we forgot about that" aspect

The mistake here is trying to come up with the most elegant design. You solve for what’s needed with the knowledge that you’ve most likely not captured the full situation, and make allowance for future changes.

I don’t want faster code. What I want is flexibility in evolving my design and there’s plenty of good tools and practices for that. From ensuring your code is testable to ensuring there are easy ways to experiment with parts of it.

I’ve never been in a situation that says “We’ve not think of that, we need to get back to the drawing board”, It’s been mostly “We need a new version of this module to support this feature”

[themgt]

> I’ve never been in a situation that says “We’ve not think of that, we need to get back to the drawing board”

And you're somehow able to post on HN from within the time crystal?

[skydhash]

Lol, I just don’t rush into coding when I could talk with the customer/user (or Product). And I shape my codebase into something I can easily experiment upon. Which means I try for it to be modular with suitable abstraction that I can easily tweak.

[marginalia_nu]

That sort of trial and error design seems like a really unprofessional way of working.

[williamcotton]

Why? Trial and error is a pretty important component of creativity.

[disgruntledphd2]

It used to be, before LLMs. It was standard practice though.

If you have a bad design that's had contact with reality for a while, it's much easier to make it actually good, rather than figure stuff out up front (I've rarely made this work, even though I'd love to).

[fragmede]

The waterfall method of software development is well studied and while agile is no panacea, there's a reason the industry has moved away from multi-year waterfall development practices.

[marginalia_nu]

Agile is in now way incompatible with measuring before you cut.