Born Against, or why hobby programming communities are against LLM usage
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Born Against, or why hobby programming communities are against LLM usage
Unofficial Hacker News client; not affiliated with Y Combinator.
alkonaut · · focus · HN ↗
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.
aleph_minus_one · · focus · HN ↗
Even if you deeply into tinkering, 1 can be an insanely exciting and rewarding step: for example "how could an abstraction look like in which 2-4 become trivial special cases for many classes of programming problems?".
In my opinion the difference between "entrepreneur type" and "programmer type" (and yes: it can happen that both of these types work in the reciprocal job) is rather:
- People of the programmer type see solving problems as their primary goal. Satisfying customers just serves the purpose that these people pay money so that they can continue working on solving problems.
- People of the entrepreneur see satisfying customers as their primary goal. Programming is just a means to an end.
ACS_Solver · · focus · HN ↗
Yes, but I think there's really two different definitions of point 1. It's "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve".
As the tinkering type, I also find 1 very rewarding but using the latter definition. Exploring a sizable code base and finding the part that, if simplified, cascades to a lot more simplification, that's very exciting. Figuring out what problem some companies or people have that could be solved? Very hard, very unexciting, not rewarding.
aleph_minus_one · · focus · HN ↗
In my opinion these variants are not very different:
For example keep in mind that physics is basically a descipription of the software that runs reality, which automatically gives you are huge portfolio of potential problems. :-)
For mechanical engineering, observe that the advances in 3D printing and home CNC milling mean that a lot of problems that were previously in the domain of mechanical engineering now become partly software problems.
Or for more "human" problems: If you are very trained in mathematics, you start to see mathematical structures in a lot of "more human" problems (or areas that are not associated with "software") basically all the time. If you find these mathematical structures that you see interesting, it is often possible to turn them into software.
Thus, "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve" is rather a litle bit like "in mathematics: do you prefer analysis or algebra?" - yes, they (often) represent a different style of thinking and many mathematicians do have their preferences, but in the end both analysis and algebra is mathematics.
--
So, I disagree with your point:
> Figuring out what problem some companies or people have that could be solved? Very hard, very unexciting, not rewarding.
In my opinion the boring part is not finding or solving problems that companies or people have. As I wrote: after some time, you often start to see highly interesting, often very novel mathematical patterns in these problems (of course not always, but it is not an uncommon situation). Why are these patterns often so novel and interesting? A heuristic answer in my opinion is: if they weren't, someone would typically already have implemented them in software. :-)
The really annoying part is rather convincing the people/company of your solution (which can be considered to be part of step "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.").