301–310 of 658 posts
Earlier quoted context omitted.
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.
And sometimes the destination is the destination and the journey is a slog.
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).
> But I would steer away from starting them. I find just the opposite. Before, starting from nothing was a huge impediment. Now you can have a working prototype and start iterating right away. If you figur e out that you've gone down the wrong path, there's little remorse in tossing it out and starting over.
Earlier quoted context omitted.
Anything that can be done in 2 days now with an LLM was low hanging fruit to begin with.
I really wonder what long term software engineering projects will become.
Earlier quoted context omitted.
Surely searching "centre a div" takes less time than prompting and waiting for a response...
Search “centre a div” in Google Wade through ads Skim a treatise on the history of centering content Skim over the “this question is off topic / duplicate” noise if Stack Overflow Find some code on the page Try to map how that code will work in the context of your other layout Realize it’s plain CSS and you’re looking for Tailwind Keep searching Try some stuff until it works Or… Ask LLM. Wait 20-30 seconds. Move on t…
Earlier quoted context omitted.
They're not moving back into development. They're adopting a new approach of producing software, which has nothing to do with the work that software developers do. It's likely that they "left" the field because they were more interested in other roles, which is fine. So now that we have tools that promise to offload the work a software developer does, there are more people interested in simply producing software, and…
That IKEA analogy is pretty good, because plenty of people use IKEA furniture to solve the "I need a bookshelf" problem - and often enjoy the process - without feeling like they should call themselves a carpenter. I bet there are professional carpenters out there who occasionally assemble an IKEA bookshelf because they need something quick and don't want to spend hours building one themselves from scratch.
What I'm pushing back on is the idea that these are equivalent to carpentry and programming. I think we need new terminology to describe this new process. "Vibe coding" is at the extreme end of it, and "LLM-assisted software development" is a mouthful.
Although, the IKEA analogy could be more accurate: the assembly instructions can be wrong; some screws may be missing; you ordered an office chair and got a dining chair; a desk may have five legs; etc. Also, the thing you built is made out of hollow MDF, and will collapse under moderate levels of stress. And if you don't have prior experience building furniture, you end up with no usable skills to modify the end result beyond the manufacturer's original specifications.
So, sure, the seemingly quick and easy process might be convenient when it works. Though I've found that it often requires more time and effort to produce what I want, and I end up with a lackluster product, and no learned skills to show for it. Thus learning the difficult process is a more rewarding long-term investment if you plan to continue building software or furniture in the future. :)
Earlier quoted context omitted.
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…
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…
Is it necessary to pay $200/mo to actually ship things or will $20/mo do it? Obviously I could just try it myself and see how far I get bit I'm curious to hear from someone a bit further down the path.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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…
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…
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.
Earlier quoted context omitted.
I was very anti AI (mainly because I am scared that I'll take my job). I did a side project that would have took me weeks in just two days. I deployed it. It's there, waiting for customers now. I felt in love with the process to be honest. I complained my wife yesterday: "my only problem now is that I don't have enough time and money to pay all the servers", because it opened to me the opportunities to develop and de…
Aren't you afraid it's gonna be a race to the bottom ? the software industry is now whoever pays gemini to deploy something prompted in a few days. Everybody can, so the market will be inundated by a lot of people, and usually this makes for a bad market (a few shiny one gets 90% of the share while the rest fight for breadcrumbs) I'm personally more afraid that stupid sales oriented will take my job instead of losing…
Earlier quoted context omitted.
Couldn't you just static render the parts that you're using SSR for? I am not trying to be dismissive, but a common strict requirement is static hosting from a CDN, embedded environments, etc.
If you static render, it won't be an interactive application. With React SSR you get the best of both: stream static HTML chunks immediately, and rehydrate with JS later, prioritizing components the user interacts with. It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for…