llm/5888b8dc-b96e-4444-9c3c-465dde409e92/topic-1-b0143cde-08ab-48f4-af5c-021a4465083a-input.json
You are a comment summarizer. Given a topic and a list of comments tagged with that topic, write a single paragraph summarizing the key points and perspectives expressed in the comments. TOPIC: Joy of programming vs shipping products COMMENTS: 1. I don't know but to me this all sounds like the antithesis of what makes programming fun. You don't have productivity goals for hobby coding where you'd have to make the most of your half an hour -- that sounds too much like paid work to be fun. If you have a half an hour, you tinker for a half an hour and enjoy it. Then you continue when you have another half an hour again. (Or push into night because you can't make yourself stop.) 2. What you consider fun isn't universal. Some folks don't want to just tinker for half an hour, some folks enjoy getting a particular result that meets specific goals. Some folks don't find the mechanics of putting lines of code together as fun as what the code does when it runs. That might sound like paid work to you, but it can be gratifying for not-you. 3. I feel like we are just covering whataboutism tropes now. You can absolutely learn from an LLM. Sometimes.documentation sucks and the LLM has learned how to put stuff together feom examples found in unusual places, and it works, and shows what the documentation failed to demonstrate. And with the people above, I agree - sometimes the fun is in the end process, and sometimes it is just filling in the complexity we do not have time or capacity to grab. I for one just cannot keep up with front end development. Its an insurmountable nightmare of epic proportions. Im pretty skilled at my back end deep dive data and connecting APIs, however. So - AI to help put together a coherent interface over my connectors, and off we go for my side project. It doesnt need to be SOC2 compliant and OWASP proof, nor does it need ISO27001 compliance testing, because after all this is just for fun, for me. 4. It's not gibberish. More than that, LLMs frequently write comments (some are fluff but some explain the reasoning quite well), variables are frequently named better than cdx, hgv, ti, stuff like that, plus looking at the reasoning while it's happening provides more clues. Also, it's actually fun watching LLMs debug. Since they're reasonably similar to devs while investigating, but they have a data bank the size of the internet so they can pull hints that sometimes surprise even experienced devs. I think hard earned knowledge coming from actual coding is still useful to stay sharp but it might turn out the balance is something like 25% handmade - 75% LLM made. 5. The difference is whether or not you find computers interesting and enjoy understanding how they work. For the people who just want to solve some problem unrelated to computers but require a computer for some part of the task, yes AI would be more “fun”. 6. I don’t find this to be true. I enjoy computers quite a bit. I enjoy the hardware, scaling problems, theory behind things, operating systems, networking, etc. Most of all I find what computers allow humanity to achieve extremely interesting and motivating. I call them the worlds most complicated robot. I don’t find coding overly fun in itself. What I find fun is the results I get when I program something that has the result I desire. Maybe that’s creating a service for friends to use, maybe it’s a personal IT project, maybe it’s having commercial quality WiFi at home everyone is amazed at when they visit, etc. Sometimes - even often - it’s the understanding that leads to pride in craftsmanship. But programming itself is just a chore for me to get done in service of whatever final outcome I’m attempting to achieve. Could be delivering bits on the internet for work, or automating OS installs to look at the 50 racks of servers humming away with cable porn level work done in the cabinets. I never enjoyed messing around with HTML at that much in the 90s. But I was motivated to learn it just enough to achieve the cool ideas I could come up with as a teenager and share them with my friends. I can appreciate clean maintainable code, which is the only real reason LLMs don’t scratch the itch as much as you’d expect for someone like me. 7. What I really enjoy in programming is algorithms and bit-twiddling and stuff that might be in Knuth or HAKMEM or whatever. That’s fun. I like writing Lisp especially, and doing cool, elegant functional programs. I don’t enjoy boilerplate. I don’t necessarily enjoy all of the error checking and polishing and minutia in turning algorithms into shippable products. I find AI can be immensely helpful in making real things for people to use, but I still enjoy doing what I find fun by hand. 8. See, I do though. I enjoy the act, the craft of programming. It's intrinsically fun for me, and has been for the 25 years I've been doing it at this point, and it still hasn't stopped being fun! Different strokes I guess 9. Oh I totally agree! I have a lot of fun chatting with friends/coworkers who are super into programming as an art and/or passion. I just was pushing back on the “you aren’t into computers if you don’t get intrinsic joy out of programming itself” bit. 10. > The difference is whether or not you find computers interesting and enjoy understanding how they work. I'm a stereotypical nerd, into learning for its own sake. I can explain computers from the quantum mechanics of band gaps in semiconductors up to fudging objects into C and the basics of operating systems with pre-emptive multitasking, virtual memory, and copy-on-write as they were c. 2004. Further up the stack it gets fuzzy (not that even these foundations are not; "basics" of OSes, I couldn't write one); e.g. SwiftUI is basically a magic box, and I find it a pain to work with as a result. LLM output is easier to understand than SwiftUI, even if the LLM itself has much weirder things going on inside. 11. I think a lot of us just discovered that the actual programming isn't the fun part for us. It turns out I don't like writing code as much as I thought. I like solving my problems. The activation energy for a lot of things was much higher than it is now. Now it's pretty low. That's great for me. Baby's sleeping, 3d printer is rolling, and I get to make a little bit of progress on something super quick. It's fantastic. 12. This 1000x! I had a bit of an identity crisis with AI first landed and started producing good code. “If I’m not the man who can type quickly, accurately, and build working programs… WHO AM I?” But as you pointed out, I quickly realized I was never that guy. I was the guy who made problems go away, usually with code. Now I can make so many problems go away, it feels like cheating. As it turns out, writing code isn’t super useful. It’s the application of the code, the judgement of which problems to solve and how to solve them, that truly mattered. And that sparks a LOT of joy. 13. > Fewer things sound less interesting to me than that. To each their own! I think the market for folks who understand their own problems is exploding! It’s free money. 14. This. Busy-beavering is why the desktop Linux is where it is - rewriting stuff, making it "elegant" while breaking backwards compatibility - instead of focusing on the outcome. 15. It's just fun in a different way now. I've long had dozens of ideas for things I wanted to build, and never enough time to really even build one of them. Over the last few months, I've been able to crank out several of these projects to satisfactory results. The code is not a beautiful work of art like I would prefer it to be, and the fun part is no longer the actual code and working in the code base like it used to be. The fun part now is being able to have an app or tool that gets the job I needed done. These are rarely important jobs, just things that I want as a personal user. Some of them have been good enough that I shipped them for other users, but the vast majority are just things I use personally. Just yesterday for example, I used AI to build a GTK app that has a bunch of sports team related sound effects built into them. I could have coded this by hand in 45 minutes, but it only took 10 minutes with AI. That's not the best part though. The best part is that I was able to use AI to get it building into an app image in a container so I can distribute it to myself as a single static file that I can execute on any system I want. Dicking with builds and distribution was always the painful part and something that I never enjoyed, but without it, usage is a pain. I've even gone back to projects I built a decade ago or more and got them building against modern libraries and distributed as RPMs or app images that I can trivially install on all of my systems. The joy is now in the results rather than the process, but it is joy nonetheless. 16. I think, for a lot of people, solving the problem was always the fun part. There is immense pleasure in a nice piece of code - something that is elegant, clever and simple at the same time. Grinding out code to get something finished - less fun… 17. It depends. Sometimes they joy is in discovering what problem you are solving, by exploring the space of possibilities on features and workflows on a domain. For that, having elegant and simple software is not needed; getting features fast to try out how they work is the basis of the pleasure, so having to write every detail by hand reduces the fun. 18. Sounds like someone who enjoys listening to music but not composing or performing music. 19. Or someone who enjoys playing music but not building their own instrument from scratch. 20. Or maybe someone DJing instead of creating music from scratch. 21. I think this is showing the difference between people who like to /make/ things and those that like to make /things/. People that write software because they see a solution for a problem that can be fixed with software seem to benefit the most of LLM technology. It's almost the inverse for the people that write software because they like the process of writing software. 22. Surely there has to be some level of "getting stuff done"/"achieving a goal" when /making/ things, otherwise you'd be foregoing for-loops because writing each iteration manually is more fun. 23. I think you misunderstand the perspective of someone who likes writing code. It's not the pressing of keys on the keyboard. It's figuring out which keys to press. Setting aside for the moment that most loops have a dynamic iteration count, typing out the second loop body is not fun if it's the same as the first. I do code golf for fun. My favorite kind of code to write is code I'll never have to support. LLMs are not sparking joy. I wish I was old enough to retire. 24. I have a 10-year-old side project that I've dumped tens of thousands of hours into. "Ship the game" was an explicit non -goal of the project for the vast majority of that time. Sometimes, the journey is the destination. 25. And sometimes the destination is the destination and the journey is a slog. 26. I mean, sure. I was just pointing out to the commentor that sometimes "getting stuff done" isn't the point. 27. Sure, but, in the real world, for the software to deliver a solution, it doesn't really matter if something is modelled in beautiful objects and concise packages, or if it's written in one big method. So for those that are more on the making /things/ side of the spectrum, I guess they wouldn't care if the LLM outputs code that has each iteration written separately. It's just that if you really like to work on your craftsmanship, you spend most of the time rewriting/remodelling because that's where the fun is if you're more on the /making/ things side of the spectrum, and LLMs don't really assist in that part (yet?). Maybe LLMs could be used to discuss ways to model a problem space? 28. I like both the process and the product, and I like using LLMs. You can use LLMs in whatever way works for you. Objections like the ones in this thread seem to assume that the LLM determines the process, but that’s not true at present. Perhaps they’re worrying about what might happen in future, but more likely they’re just resisting change in the usual way of inventing objections against something they haven’t seriously tried. These objections serve more as emotional justifications to avoid changing, than rational positions. 29. As I've gotten more experience I've tended to find more fun in tinkering with architectures than tinkering with code. I'm currently working on making a secure zero-trust bare metal kubernetes deployment that relies on an immutable UKI and TPM remote attestation. I'm making heavy use of LLMs for the different implementation details as I experiment with the architecture. As far as I know, to the extent I'm doing anything novel, it's because it's not a reasonable approach for engineering reasons even if it technically works, but I'm learning a lot about how TPMs work and the boot process and the kernel. I still enjoy writing code as well, but I see them as separate hobbies. LLMs can take my hand-optimized assembly drag racing or the joy of writing a well-crafted library from my cold dead hands, but that's not always what I'm trying to do and I'll gladly have an LLM write my OCI layout directory to CPIO helper or my Bazel rule for putting together a configuration file and building the kernel so that I can spend my time thinking about how the big pieces fit together and how I want to handle trust roots and cold starts. 30. Something happened to me a few years ago. I used to write code professionally and contribute to open source a lot. I was freelancing on other people's projects and contributing to mature projects so I was doing hard work, mostly at a low level (I mean algorithms, performance fixes, small new features, rather than high level project architecture). I was working on an open source contribution for a few days. Something that I struggled with, but I enjoyed the challenge and learned a lot from it. As it happened someone else submitted a PR fixing the same issue around the same time. I wasn't bothered if mine got picked or not, it happens. But I remember looking at how similar both of our contributions were and feeling like we were using our brains as computers, just crunching algorithms and pumping in knowledge to create some technical code that was (at the time) impossible for a computer to create. This stayed with me for a while and I decided that doing this technical algorithm crunching wasn't the best use of my human brain. I was making myself interchangeable with all the other human (and now AI) code crunchers. I should move on to a higher level, either architectural or management. This was a big deal for me because I did love (and still do) deeply understanding algorithms and mathematics. I was extremely fortunate with timing as it was just around one year before AI coding became mainstream but early enough that it wasn't a factor in this shift. Now an AI could probably churn out a decent version of that algorithm in a few minutes. I did move on to open my own business with my partner and haven't written much code in a few years. And when I do now I appreciate that I can focus on the high level stuff and create something that my business needs in a few hours without exhausting myself on low level algorithm crunching. This isn't meant to put down the enjoyment of writing code for code's sake. I still do appreciate well written code and the craft that goes into it. I'm just documenting my personal shift and noting that enjoyment can be found on both sides. 31. There are many people who enjoy spending an afternoon working on a classic car. There are also many people who enjoy spending an afternoon driving a classic car. Sometimes there are people who enjoy both. Sometimes there are people that really like driving but not the tinkering and some who are the opposite. 32. Neat summary of Zen and the Art of Motorcycle Riding! 33. LLMs are really showing how different programmers are from one another i am in your camp, i get 0 satisfaction out of seeing something appear on the screen which i don't deeply understand i want to feel the computer as i type, i've recently been toying with turning off syntax highlighting and LSPs (not for everyone), and i am surprised at the lack of distractions and feeling of craft and joy it brings me 34. I yearn for the mindset where I actively choose to accomplish comparatively little in the brief spells I have to myself, and remain motivated. Part of what makes programming fun for me is actually achieving something. Which is not to say you have to use AI to be productive, or that you aren't achieving anything, but this is not the antithesis of what makes programming fun, only what makes it fun for you. 35. If you only get one or two half-hours a week it's probably more fun to use those to build working software than it is to inch forward on a project that won't do anything interesting for several more months. 36. I find it interesting how you take your experience and generalize it by saying "you" instead of "I". This is how I read your post: > I don't know but to me this all sounds like the antithesis of what makes programming fun. I don't have productivity goals for hobby coding where I'd have to make the most of your half an hour -- that sounds too much like paid work to be fun. If I have a half an hour, I tinker for a half an hour and enjoy it. Then I continue when I have another half an hour again. (Or push into night because I can't make myself stop.) Reading it like this makes it obvious to me that what you find fun is not necessarily what other people find fun. Which shouldn't come as a surprise. Describing your experience and preferences as something more is where the water starts getting muddy. 37. For me it automates a lot of the boilerplate that usually bogs me down on side projects. I cal spin up all of the stuff I hate doing quickly and then fiddle with the interesting parts inside of a working scaffold of code. I recently did this with an elixir wrapper around some Erlang OTP code o wanted to use. Figuring out how to clue together all of the parts that touched the Erlang and tracing all of the arguments through old OTP code would have absolutely stopped me from bothering with this in the past. Instead I’m having fun playing with the interface of my tool in ways that matter for my use case. 38. I enjoy coding for the ability to turn ideas into software. Seeing more rapid feature development, and also more rapid code cleanup and project architecture cleanup is what makes AI assisted coding enjoyable to me 39. Is the manual coding part of programming still fun or not? We have a lot of opinions on either side here. I think the classic division of problems being solved might, for most people, solve this seeming contradiction. For every problem, X% is solving the necessary complexity of the problem. Taming the original problem, in relation to what computers are capable of doing. With the potential of some relevant well implemented libraries or API’s helping to close that gap. Work in that scenario rarely feels like wasted time. But in reality, there is almost always another problem we have to solve, the Y%=(1-X) of the work required for an actual solution that involves wrangling with mismatches in available tools from the problem being solved. This can be relatively benign, just introducing some extra cute little puzzles, that make our brains feel smart as we successfully win wack-a-mole. A side game that can even be refreshing. Or, the stack of tools, and their quirks, that we need to use can be an unbounded (even compounding) generative system of pervasive mismatches and pernicious non-obvious, not immediately recognizable, trenches we must a 1000 little bridges, and maybe a few historic bridges, just to create a path back to the original problem. And it is often evident that all this work is an artifact of 1000 less than perfect choices by others. (No judgement, just a fact of tool creation having its own difficulties.) That stuff can become energy draining to say the list. I think high X problems are fun to solve. Most of our work goes into solving the original problem. Even finding out it was more complex than we thought feels like meaningful drama and increase the joy of resolving. High Y problems involve vast amounts of glue code, library wrappers with exception handling, the list in any code base can be significant. Even overwhelm the actual problem solving code. And all those mismatches often hold us back, to where our final solution inevitable has problems in situations we hope never happen, until we can come back for round N+1, for unbounded N. Any help from AI for the latter is a huge win. Those are not “real” problems. As tool stack change, nobody will port Y-type solutions forward. (I tell myself so I can sleep at night). So that’s it. We are all different. But what type of acceleration AI gives us on type-Y problems is most likely to feel great. Enabling. Letting us harder on things that are more important and lasting. And where AI is less of a boost, but still a potentially welcome one, as an assistant. 40. > There are two sorts of projects (or in general, people): artisans, and entrepreneurs. The latter see code as a means to an end, possibly monetized, and the former see code as the end in itself. Me from 9 days ago: https://news.ycombinator.com/item?id=46391392#46398917 41. Some people build because they enjoy the mechanics. Others build because they want to use the end product. That camp will get from A to B much more easily with AI, because for them it was never about the craft. And that's more than OK. 42. I think it just depends on the person or the type of project. If I'm learning something or building a hobby project, I'll usually just use an autocomplete agent and leave Claude Code at work. On the other hand, if I want to build something that I actually need, I may lean on AI assistants more because I'm more interested in the end product. There are certain tasks as well that I just don't need to do by hand, like typing an existing SQL schema into an ORM's DSL. 43. I derive the majority of my hobby satisfaction from getting stuff done, not enjoying the process of crafting software. We probably enjoy quite different aspects of tinkering! LLMs make me have so much more fun. 44. I do have productivity goals! I want to spend the half hour I have on the part I think is fun. Not on machine configuration, boilerplate, dependency resolution, 100 random errors with new frameworks that are maybe resolved with web searches. 45. Which is fine, because those things are what makes programming fun for you. Not for others. 46. I enjoy noodling around with pointers and unsafe code in Rust. Claude wrote all the documentation, to Rust standards, with nice examples for every method. I decided to write an app in Rust with a React UI, and Claude wrote almost all the typescript for me. So I’ve used Claude at both ends of the spectrum. I had way more fun in every situation. AI is, fortunately, very bad at the things I find fun, at least for now, and very good at the things I find booooring (read in Scot Pilgrim voice). 47. I think there can be other equally valid perspectives than your own. Some people have goals of actually finishing a project instead of just "tinkering"... and that's ok. Some say it might even be necessary. 48. You could make the same argument about the printing press. Some people like forming the letters by hand, others enjoy actually writing. 49. Actually, the invention of the printing press in 1450 created a similar disruption, economic panic and institutional fear similar to what we're experiencing now: For centuries, the production of books was the exclusive domain of professional scribes and monks. To them, the printing press was an existential threat. Job Displacement: Scribes in Paris and other major cities reportedly went on strike or petitioned for bans, fearing they would be driven into poverty. The "Purity" Argument: Some critics argued that hand-copying was a spiritual act that instilled discipline, whereas the press was "mechanical" and "soulless." Aesthetic Elitism: Wealthy bibliophiles initially looked down on printed books as "cheap" or "ugly" compared to hand-illuminated manuscripts. Some collectors even refused to allow printed books in their libraries to maintain their prestige. Sound familiar? From "How the Printing Press Reshaped Associations" -- https://smsonline.net.au/blog/how-the-printing-press-reshape... and "How the Printing Press Changed the World" -- https://www.koolchangeprinting.com/post/how-the-printing-pre... 50. I've seen this argument a few times before and I'm never quite convinced by it because, well, all those arguments are correct. It was an existential threat to the scribes and destroyed their jobs, the majority of printed books are considered less aesthetically pleasing than a properly illuminated manuscript, and hand copying is considered a spiritual act by many traditions. I'm not sure if I say it's a correct argument, but considering everyone in this thread is a lot closer to being a scribe than a printing press owner, I'm surprised there's less sympathy. 51. Having AI working with and for me is hugely exciting. My creativity is not something an AI can outmode. It will augment it. Right now ideas are cheap, implementation is expensive. Soon, ideas will be more valuable and implementation will be cheap. The economy is not zero sum nor is creativity. 52. But the world is better of with the scribes unemployed: ideas get to spread, more people can educate themselves through printed books. Maybe the world is better off with fewer coders, as more software ideas can materialize into working software faster? 53. > At that point, the argument over whether they're crap or not is done. Not really, it just transforms into a question of how many of those jobs are meaningful anyway, or more precisely, how much output from them is meaningful. 54. Another anecdote: I built my first Android app in less than a dozen hours over the holiday, tailored for a specific need I have. I do have many years of experience with Java, C# and JS (Angular), but have never coded anything for mobile. Gemini helped me figure out how to set up a Kotlin app with a reasonable architecture (Hilt for dependency injection, etc). It also helped me find Material3 components and set up the UI in a way that looks not too bad, especially considering my lack of design skills. The whole project was a real joy to do, and I have a couple of more ideas that I'm going to implement over the coming months. As a father of three with a busy life, this would've simply been impossible a couple of years ago. 55. Yes! I feel like so many people really fail to appreciate this side of things. Heck, Suno has gotten me to the point where I play so much more piano (the recording -> polished track loop is very rewarding) that not only did I publish an album to Spotify in my favorite genre, of music that I’m really happy with, I’ve also started to produce some polished acoustic recordings with NO AI involvement. That’s just because I’ve been spending so much more time at the piano, because of that reward loop. 56. As long as you get the dish you want when before you couldn’t have it — who cares? 57. Are you even cooking if you did not collect your own ingredients and forge your own tools?? 58. The important difference is the reduction in boilerplate, which allows programs to be written with (often) significantly less code. Hence the time savings (and fun) spoken of in the original article. This isn't really a new phenomenon. Languages have been adding things like arrays and maps as builtins to reduce the boilerplate required around them. The modern languages of which we speak take that same idea to a whole new level, but such is the nature of evolution. 59. Isn't that still considered cooking? If I describe the dish I want, and someone else makes it for me, I was still the catalyst for that dish. It would not have existed without me. So yes, I did cook it. 60. I'm sorry, "upskill"? The roles you mentioned don't require any more advanced skills than those required for software development—just a different set of skills. And an IC is not "left behind" if those roles don't interest them. What a ridiculous thing to say. A systems analyst or product manager is not a natural progression for someone who enjoys software development. 61. I was just getting pretty sick and tired of programming, instead now AI can write the code down while I do the fun things of figuring out how shit works and general device hacking + home projects 62. I remember those times, and it was a lot of fun, but there's really nothing stopping you from running a LAMP stack today, writing PHP without frameworks and with manual SQL queries. In fact, it's a lot more fun for me to approach this today. Modern PHP is a joy. MariaSQL is very much MySQL (and switching to Postgres isn't exactly a bump in complexity). It's way easier to write code that won't get injected. If you want to slice your designs in Photoshop (ehem, the real OGs used Fireworks) go ahead and use Dreamweaver, go ahead. That said, HTML5 makes not having to use tables for layout easy, not more complex and VS Code has all the good parts of Dreamweaver (trust me, you don't need or want the WYSIWG... if you must, just use inspect elements and move the changes over to the HTML file). I guess all this is to say that web dev is simpler, not more complex for solo devs today. There exists more complicated tooling, but if you're solo-dev'ing something for fun, skip it! EDIT: Also, phpMyAdmin was fun to use but also the best way to get your box popped. Today, something like DBeaver suits me just fine. 63. I still write vanilla PHP with SQL queries. And with all the modern PHP features, things have never been faster or more joyful to work with. I honestly feel bad for people who fall victims to complexity. It burns you out when all you need is to keep things simple and fun. Life is too short for anything else. 64. I think it depends what you are doing. I’ve had Claude right the front end of a rust/react app and it was 10x if not x (because I just wouldn’t have attempted it). I’ve also had it write the documentation for a low level crate - work that needs to be done for the crate to be used effectively - but which I would have half-arsed because who like writing documentation? Recently I’ve been using it to write some async rust and it just shits the bed. It regularly codes the select! drop issue or otherwise completely fails to handle waiting on multiple things. My prompts have gotten quite sweary lately. It is probably 1x or worse. However, I am going to try formulating a pattern with examples to stuff in its context and we’ll see. I view the situation as a problem to be overcome, not an insurmountable failure. There may be places where an AI just can’t get it right: I wouldn’t trust it to write the clever bit tricks I’m doing elsewhere. But even there, it writes (most of) the tests and the docs. On the whole, I’m having far more fun with AI, and I am at least 2x as productive, on average. Consider that you might be stuck in a local (very bad) maximum. They certainly exist, as I’ve discovered. Try some side projects, something that has lots of existing examples in the training set. If you wanted to start a Formula 1 team, you’re going to need to know how to design a car, but there’s also a shit ton of logistics - like getting the car to the track - that an AI could just handle for you. Find boring but vital work the AI can do because, in my experience, that’s 90% of the work. 65. There's been so much pressure to use AI at work. My codebase is a zen garden I've been raking for 6 years. I have concerns about what's going to happen after a few months of "we're using AI cause they told us to." 66. That must be so satisfying. I’ve heard the phrase “code farming” before, but I like the zen garden analogy. If the future is indeed AI, and I’m certainly hearing a lot of people using it extensively, then I think there has to be a mindset shift. Our job will change from craft to damage limitation. Our goal will be to manage a manic junior developer who produces a mixture of good code and slop without architectural level reasoning. Code will rot fast and correctness will hinge on testing as much as you can. It seems like a horrible future. However, it does seem to me that given decades we were unable to build good development practices. Our tooling is terrible. Most of our languages are terrible. Our solution was to let inexperienced devs create languages with all the same flaws, repeating the same mistakes. Web dev is a great example of inefficient software dev that has held the world to ransom. Maybe AI slop is payback for software developers. 67. Don't you enjoy the fact that some staff is actually _done_? 68. In the context of "fun again", debugging slop, finding imaginary dependencies, and discovering unimaginably fragile code isn't fun , even if it's not important. But past bad output, I worry for our creative fulfillment. The old timers are right. That feeling of accomplishment, a keystone of happiness is a product of work. Probably beyond the scope of the thread. 69. This isn't supposed to be a slam on LLMs. They're genuinely useful for automating a lot of menial things... It's just there's a point where we end up automating ourselves out of the equation, where we lose opportunity to learn, and earn personal fulfilment. Web dev is a soft target. It is very complex in parts, and what feels like a lot of menial boilerplate worth abstracting, but not understanding messy topics like CSS fundamentals, browser differences, form handling and accessibility means you don't know to ask your LLM for them. You have to know what you don't know before you can consciously tell an LLM to do it for you. LLMs will get better, but does that improve things or just relegated the human experience further and further away from accomplishment? 70. Last paragraph resonated so deeply with me. Especially this: ```It’s also not the typing of code that I really enjoy, nor is it the syntax or structure or boilerplate that’s required to build anything. It’s the fact you get to build something out of nothing, writing code was just how you got there. And with today’s tooling, that saves a ton of time.``` I never really related with folks that code for beauty or are put off by how AI does the actual coding. The beauty is actually creating something, solving real problems, shipping, and (hopfully) winning. It might be cliche, but it is incredibly true for me to say that using AI feels like a superpower. 71. The people who love writing code were the ones who created the languages and frameworks that make it even possible for an LLM to cobble something together for you. There is tons of satsifaction in actually creating nuts and bolts frameworks. After you encounter difficulties in creating a real world product you see the need for tools to solve those problems, so crafting those tools and then using them does feel like winning and shipping and solving real problems. 72. AI makes finishing projects easier. But I would steer away from starting them. In order for me to be comfortable with a code base and consider it mine I need to have written the foundation, not merely reviewed in. Once the pillars are there, LLMs do make further development faster and I can concentrate on fun details (like tinkering with CSS or thinking about some very specific details). 73. Maybe its just me but I enjoy learning how all these systems work. Vibe Coding and LLMs basically take that away from me, so I dont think ill ever be as hyped for AI as other coders 74. Au contraire. Web development has always been fun, unless you add all the crap mentioned in TFA. If you feel you need all that stuff to feel grown up, then I guess LLMs help a lot. But the barometer hasn't changed: make something that people love. 75. No. My point is more nuanced than that. All of the things in the article have value to someone, but their value to you is defined in terms of how much better they make your product. If you spend so much time on the cumulation of product-adjacent activities that you don't make a good product, then their cumulative value to you was negative. But I do, personally, love a good build system. The value is extremely high and it only takes 10 minutes to set one up. 76. I kinda feel the same way, don't get me wrong, I'm a developer at soul level, I absolutely love programming, but I love more getting shit done, automating things, taking the human out of the equation and putting the computer to do it, AI lets me do that. I work in cybersecurity as a WAF admin, my job is 100% that, but I'm also the only developer so anything that needs to be scripted or developed I get to do it. One week I created 4 different scripts with Gemini Canvas to automate some tedious work, it took my I don't know, 3 hours? Instead of 1 or 2 weeks? Yeah sign me in. 77. Agree, I developed a 150K line stock analytics Saas that started with the will to provide my son with some tools to analyse stocks. I enjoyed this experience of CLI coding so much that I developed Market Sentiment parsing 300,000 business articles and news daily, a dividend based strategy with calendar of payouts and AI optimised strategies to extract every drop of interest, an alert system for a strategy you backtested in the playground and its key triggers are tracked automatically so you can react, an ETF risk analysis model with external factors, all quant graphs and then some, time models with Markov, candlestick patterns, Monte Carlo simulation, walk forward and other approaches I had learned over the years. There is much more. I know you don't measure a project in terms of lines of code, but these are optimised, verified, tested, debugged and deployed. There are so much features, because I was having fun and got carried away. I'm semi-retired and this is like having my web agency back again. I used to program in GRASP... I have a data scientist certification, did a lot of Python, Machine Learning, NLP, etc. I really enjoy the prompt based development process as it seems like you are reaching the right resource for your question from a staff of experienced dev. Of course you need to check everything as a junior dev always creeps in when you least expect it. Especially for security. Discuss best practices often and do your research on touchy subjects. Compare various AI on the same topic. GROK has really caught up. OpenAI has slowed down. CLAUDE is simply amazing. This AI thing is work in progress and constantly changing. I have a noticed an amazing progression over the past year. I have a feeling their models are retrained, tweaked on our interactions even if you asked for them not to use the data. The temptation is too high and the payoffs abound in this market for the best AI tools. I'm building a code factory now with agents and key checkpoints for every step. I want to remove human intervention from multiple sub steps that are time consuming so I can be even more productive in 2026... 78. Meanwhile, I've been feeling the fun of development sucked away by LLMs. I recently started doing some coding problems where I intentionally turned off all LLM assistance, and THAT was fun. Although I'll be happy to use LLMs for nightmare stuff like dependency management. So I guess it's about figuring out which part of development you enjoy and which part drains you, and refusing to let it take the former from you. 79. I really agree with this. For me it just feel so much more fun and rewarding to build my weekend projects, especially those projects where I just want to produce and deploy a working mvp out of an idea. If trying out a new framework or whatever I find it quite the opposite though, that AI removes all the fun parts of learning (obviously) 80. I've tried vibe coding and hate it. I guess it's okay for people who are only interested in the result, but for me it takes all the fun out of programming. It doesn't feel like it has anything to do with programming at all. I will continue to "vibe code" out of necessity - saving time and achieving more than I can on my own. But I cannot possibly understand how someone could consider it fun. 81. its also trading one problem for another. when manually coding you understand with little mental effort what you want to achieve, the nuances and constraints, how something interacts with other moving parts, and your problem is implementing the solution when generating a solution, you need to explain in excruciating detail the things that you just know effortlessly. its a different kind of work, but its still work, and its more annoying and less rewarding than just implementing the solution yourself 82. > when generating a solution, you need to explain in excruciating detail the things that you just know effortlessly This is a great way of explaining the issue. 83. AI has increased my productivity in dealing with side tasks in languages/frameworks I'm not familiar with. But it has not made development fun. To the contrary, I enjoy writing code, not reviewing code. 84. This sounds like the opposite of fun to me. 85. it is fun again because we can remove ourselves completely from it? seems like web enthusiast are always the first to drop ship huh. "llms good because I no longer have to interface with this steaming pile of shit that web development has become", not because the web ecosystem has improved by any metric. 86. yeah, I think that too - for me the -Ofun comes from HTMX https://htmx.org and the HARC stack https://harcstack.org so I can server side code in a my preferred programming language hint: not JS (with a helping of LLM on the side) 87. Fun is the way, not the destiny 88. Of course its fun. Making slop _is_ very fun. Its a low-effort dopamine-driven way of producing things. Learning is uncomfortable. Improving things using only your braincells can be very difficult and time consuming. 89. I don't bike for exercise. I bike to get where I'm going with the least amount of friction. Different tools for different jobs. Also: I think we can agree that Ripley was getting a good workout. 90. Web development may be fun again but you aren’t developing. You order and became a customer. Maybe you can distinguish good code from bad code but how long will you check it? Auditing wasn’t the fun part ever. And I bet at some point you will recognize a missing feeling of accomplishment because you didn’t figure out the how, you just ordered the what. We wouldn’t call someone a painter who let AI do the painting. 91. To me it seems like for OP development was a means towards an end. The act to developing software as a craft does not seem to be of importance to him while the output is. His post is full of references to productivity and lacking references of improving his skills (as opposed to using LLMs as a crutch) or getting better at writing software. I bet OP would be equally happy if he had AGI that would write everything for him. For many in HN, programming is an end in itself and they would not be happy giving that up just because it makes you finish quicker. 92. AI is doing the chores while we paint. 93. Except to me it feels more like AI is painting while I have to do the chores 94. It’s because business demand speed and shipping over other concerns. We had to fight hard for proper quality controls in the face of the LLM coding assistance boom where I work. These are great tools but they have limits and can lead to poor engineering hygiene quite quickly. It took a major issue being attributed to having too much trust in these tools before we were able to enforce better hygiene with them 95. Yeah. I love programming. I even love the business side where you solve real problems for people. What I don't love is the constant pressure to just deliver faster and faster. So forcing these chatbots on us fill a need for the CEOs and manager types that just want to DELIVER DELIVER DELIVER, but the benefit for the people that are forced to use them are marginal at best. There are some valid use cases for LLM-based tools, but businesses mostly aren't interested in those because it doesn't make line go up. Streamlining operations? Nah. Shove a Chatbot where it doesn't belong so you can try to get a billion dollar investment? NOW WE ARE COOKING C-suites and managers don't give a shit about quality unless they feel the pain. That's the most important thing I've learned. If you can find a way to push the pain up to the people that make the decisions, the more likely they are incentivised to improve it. It doesn't matter if you see a problem that takes 2 days to fix coming a year away - they do not care until the application crashes because of it. Office politics sucks. 96. Customers don't buy software based on quality first, they buy on features. Until customers in mass, or regulations demand quality, money will be made on deliveries. If your lucky and can program how you want and take the time you need, then you can focus on the attributes you feel best about. 97. If you have customers that will put up with things being slow as molasses and crashing al the time, well….can you send some my way because mine won’t STFU about it. 98. You've made a categorical mistake here... I stated customers don't buy software based on performance. They just bitch about the performance of the flashy software they buy... Then get tired of it, and move on to some other flashy software with suck performance never learning their lesson. 99. I don't get it. What part of the process do you enjoy? Do you also enjoy hiring a taskrabbit to go hiking for you, taking photos along the way? 100. I’m just looking to make pizza not smelt the ore for the oven I’m going to cook it in. 101. Why make pizza when you can order it? As far as I can tell, there's not much enjoyment of making being had. Enjoying having is fine too, but let's at least be honest about it. I enjoy looking at photos people took on hikes, but I don't call it hiking. 102. Is it hiking if I bought my boots on amazon? 103. Not if you sit at home wearing boots and looking at photos of mountains. If you want to have boots, that's cool. But is replacing walking with ordering boots and photos making hiking fun again? Or were you only interested in the photos anyway? What part of the process of hiking do you enjoy? And why is it so hard to hear what part of the process of programming people enjoy? 104. But you’d agree it’s still hiking even if I didn’t tan the leather for the boots myself. 105. Yes, if you go out and walk. The same way I would agree it was programming if you designed the algorithms yourself. 106. This is just obtuse. Some folks have fun building their own pizza oven, curing & slicing their own meat, and mixing their own dough. Some folks like to buy mostly pre-made stuff and just play with a few special ingredients. Some folks want to make 5 different pizzas with different flavors. Some folks just order a pizza. Some folks walk out of their house and start hiking. Some folks drive somewhere and then start walking. Some folks take photos from the car. Some folks take a roadtrip. All of these things ask for different effort & commitment with different experiences & results as the payoff. At least be honest about that. 107. It's interesting that nobody has actually answered what part of the process they enjoy. 108. Like, fine, here's a personal example: I wanted to build a system that posts web links I share to a bot account on the fediverse. That seemed like a fun result to me. I wanted to self-host the links, so I installed Linkding. (I didn't write Linkding.) For the fediverse bot, I installed gotosocial as the service host (I didn't write gotosocial.) From there, a cronjob running a small program using Linkding and gotosocial APIs could do the trick. Decided to do it in golang, because the standalone binaries are easy to deploy. Writing that small program didn't seem like fun - I've already played with those APIs and golang. What I wanted, for my enjoyment, was the completed system. So, I took 10 minutes to write out a quick spec for the program and what I wanted it to do. I loaded that up as context for Claude Code along with some pointers for building CLI apps in golang. I let it rip and, in about 20 minutes, Claude produced a functional tool. It also wrote a decent README based on my original prose. I reviewed the code, did some testing, made some tweaks, called it done. My bookmarks are now regularly posted to a bot account on the fediverse. This is an enjoyable outcome for me - and I didn't have to type every line of code myself. For bonus points, I also had Claude Code gin up some GitHub Actions workflows to lint, test, build, and release multi-platform binaries for this tool. I've done these things before, but they're tedious. More enjoyable to have the resulting automations than to build them. And now I have them: I can make tweaks to this tool and get builds just through the GitHub web UI. I've since repeated this pattern with a handful of other small personal tools. In each case, I wanted the tool and the utility it offered. I didn't care about the process of writing the code. It's working pretty well for me. 109. It's different for everyone, so no one answer would likely satisfy you 110. Having a product that works is what these people enjoy 111. Seeing the output I want when I describe it, and making changes to get to the vision in my mind. I don't have aphantasia so maybe it's different for those who do, but I can literally see the UI of the app I want to build and of course I can build it by writing code manually too, but I can make it exist much faster with an LLM than without. 112. What is fun? Prompting? Write a concise, engaging paragraph (3-5 sentences) that captures the main ideas, notable perspectives, and overall sentiment of these comments regarding the topic. Focus on the most interesting and representative viewpoints. Do not use bullet points or lists - write flowing prose.
Joy of programming vs shipping products
112