Hacker Newsnew | past | comments | ask | show | jobs | submit | shriek's commentslogin

to build what you don't understand is to suffer in future


Yep, did the same thing too. It's nice that you just need one tool to unscrew, screw things and everything is labelled well that you don't need to go dig to multiple websites on how to do repair/replace parts. But of all things, replacing keyboard was the most tedious one in framework with so many screws, haha.


Yep. They've made a decision to pay premium price for your service so you know you're worth more now.


It never occurred to me to lookup the creator of the tool[1] that I used to use so often. It's so easy to overlook that there are actually humans with their own story (tragic or not) behind the tools that we use. I should learn to appreciate people behind the code more. And, I'm so sorry what you had to and are going through, Mr. Meyer.

[1]. https://meyerweb.com/eric/tools/dencoder/


Or maybe calling a cab and telling the cab driver each direction to get to the destination instead of the cab driver just taking you there.


Wait till they come with auto review/merge agents, or maybe there already is. gulp


Because they have a common goal. The challenge for atheists is to find group of people with the same goal as theirs.


And the reason they suck is the feedback loop is just too high as compared to running it locally. You have to jump through hoops to debug/troubleshoot your code or any issues that you come across between your code and output of your code. And it's almost impossible to work on things when you have spotty internet. I haven't worked on extremely sensitive data but for PII data from prod to dev, scrubbing is a good practice to follow. This will vary based on the project/team you're on of course.


Aka 'if a developer knew beforehand everything they needed, it wouldn't be development'


That's the least important problem.

The developers also lack knowledge about the environment; can't evolve the environment; can't test the environment for bugs; and invariably interfere with each other because it's never isolated well. And also, yes, it adds lag.

Anyway, yes, working locally on false data that little resemblance to production still beats remote environments.


Most of the time the entire apps are just a timer app or something simple. Never a complex app with tons of logic in them. And if you're having to write paragraphs of texts to write something complex then might as well just write that in a programming language, I mean isn't that what high-level programming language was built for? (heh). Also, you're not the only one who's had the thought that someone is vested in someway to overhype this.


You can write the high level structure yourself and let it complete the boilerplate code within the functions, where it's less critical/complicated. Can save you time.


Oh for sure. I use it as smart(ish) autocomplete to avoid typing everything out/looking up in docs everytime but the thought of prompt engineering to make an app is just bizarre to me. It almost feels like it has more friction than actually writing the damn thing yourself.


Yeah, I'm curious how others are using too. For boilerplate code and configs, they're great in a sense that I don't have to open docs for reference but other than that I feel like maybe I'm not fully using it to its full potential like others are mentioning.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: