4 ms·

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 chang

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.

skydhash 3mo ago
> 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 3mo ago
  > 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 3mo ago
    > 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 3mo ago
      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.
      - marginalia_nu 3mo ago
        That sort of trial and error design seems like a really unprofessional way of working.
        williamcotton 3mo ago
        Why? Trial and error is a pretty important component of creativity.
        fragmede 3mo ago
        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.
WJW 3mo ago
> 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 3mo ago
  > 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 3mo ago

> 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 3mo ago
> 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 3mo ago
  > 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 3mo ago
    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.
    - marginalia_nu 3mo ago
      That sort of trial and error design seems like a really unprofessional way of working.
      - williamcotton 3mo ago
        Why? Trial and error is a pretty important component of creativity.
      - fragmede 3mo ago
        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.

WJW 3mo ago

> 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 3mo ago
> 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.