‹ BackHN Continuity

Thread

Born Against, or why hobby programming communities are against LLM usage

391 points · 454 comments · lladnar

  1. alkonaut · · focus · HN ↗
    Programming has five phases effectively:

    1) You figure out what problem to solve.

    2) You figure out HOW to solve the problem.

    3) You actually implement the solution.

    4) You see the solution work, for yourself.

    5) You ship/deploy/publish the program. This means you see people be happy users and/or you get paid for it and so on.

    If you're an entrepreneur type, you probably enjoy the first and last steps most, and you see steps 2-4 as mostly a chore. If you're a tinkerer, you don't care much for 1 and 5, and you see 2-4 as the whole point of programming. I'm a tinkerer. I'd be happy to just write code and throw it away. Coding is like solving sudokus. I could skip steps 1 and 5 forever. I don't ever need to show any code to anyone. In fact, most of the time when programming I do steps 2 and 3 and even skip 4. I don't even finish! I work weeks on something until I lose interest, and I know that in order to even run it, it would be several more weeks. A PoC is enough. Or just a half one. It's just code-to-structure-thoughts, not to create anything finished.

    The 5 phases look kind of symmetric. The outermost layer (1 and 5) are the entrepreneurial steps. If you're a product owner or CEO, you might work strictly at steps 1,5. Then steps 2-4 are the managerial/architectural steps. If you're a very senior IC at a large company, you might work at this level, without actually doing much coding. Only the inner most step (3) is the manual creation of source code. Even though it's 5 different phases, it's just "3 layers" of programming.

    The problem as I see it is that I enjoy step 3. And LLMs are good at step 3 almost exclusively. So they just pick the best bit of this dish, and leave me with the rest.

    If you're an entrepreneurial type, the LLM appears to take the _worst_ bit of the work from you. Great.

    1. easyThrowaway · · focus · HN ↗
      The type of problem also makes a massive difference.

      - Writing my tiny hobby gameboy emulator? Heck, Why I'd let Claude take away the fun part of implementing new features and then see Super Mario Land start and run step by step?

      - Debugging why a legacy Wordpress store with more than 50 active plugins is returning an error 500 just to some random customers? Claude can 100% take the wheel, I'm good.

      1. alkonaut · · focus · HN ↗
        Here's where the important difference is: unless you actually finished the wordpress thing, or ever had active users etc, it would never have become a maintenance burden. If it's not fun to maintain, I burn it.

        For me, the reason I don't have that is because I never ship anything. I never want to maintain that. I never cared about solving an _actual_ business problem, making a dollar, or pleasing a user. As a tinkerer I must be extremely careful not to end up completing or delivering anything. Only pain lies down that path...

        1. darkwater · · focus · HN ↗
          It's your vision and you are completely free to have it, obviously, but you should not project it on every tinkerer out there - like you did in your initial message. Yours is actually an extreme position that's probably exacerbated by the digital and immaterial world, where you can accumulate cruft and unfinished projects easily. But many tinkerers, especially in the physical world, do projects to use them personally and not only for the sake of tinkering.

          Many tinkerer projects in the physical world are actually maintenance work of physical appliances that are not working anymore as expected or can be extended to do more or better things.

          1. SoftTalker · · focus · HN ↗
            Lots of physical world tinkerers also have a garage or workshop full of uncompleted projects that went from being fun and interesting to boring and abandoned.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.