[marginalia_nu]

Just about every professional coding job I've ever had has had programmers eager to code more, complaining about how much rigmarole there is around making changes, complaining about constant meetings and endless bureaucracy around change management and requirements. Meanwhile business mostly saw programmer velocity and output as a problem and a business risk, as they struggled to keep up with the rate of change and kept stepping on the brakes.

Like realistically even without LLMs I output probably around 10x as much code working alone, self-employed with zero meetings or bureaucracy, than I've ever done as a professional programmer. My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.

[WJW]

> My output sometimes rivals that of entire teams' I've been part of

That's not very hard with many of the teams I've seen, with or without LLMs. Though the old adage of "If you want to go fast, go alone. If you want to go far, go together" still applies.

[KronisLV]

> If you want to go far, go together

Unless you encounter circumstances where it's death by committee (or something similarly bad), but overall I agree! It's just that you don't have the bad environment risk/problem when it's just you.

[skydhash]

> My output sometimes rivals that of entire teams' I've been part of, mostly because I get to just code to my heart's content.

The fact is that often I code less than most of my peers. Because I prefer spending some time to design suitable data structures/algorithms for the problem at hand. I don't aim for perfection, just that it align with the business domain (and/or the interface) so that future works are proportional with the scope of change requests. This has reflected in small commits because the fundamental core of the business domain rarely changes (when they do, we have bigger problems than my writing speed).

So I've never seen the need to increase my writing speed, because there's never any need to do so. What I'd like to increase is the speed the Product team get back to me with answers to my questions. Because that's often the real bottleneck.

[echelon]

> I prefer spending some time to design suitable data structures/algorithms for the problem at hand.

I'm doing this at LLM speed now.

I feel like I'm doing the work of two whole teams and designing rock-solid software.

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

[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?

[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.