Comment by aleph_minus_one
2 days ago
> When I ask ChatGPT (for example) for a code solution, I find that it’s usually quite “naive” (pretty prolix). I usually end up rewriting it. That doesn’t mean that’s a bad thing, though. It gives me a useful “starting point,” and can save me several hours of experimenting.
The usual counter-point is that if you (commonly) write code by experimenting, you are doing it wrong. Better think the problem through, and then write decent code (that you finally turn into great code). If the code that you start with is that as "naive" as you describe, in my experience it is nearly always better to throw it away (you can't make gold out of shit) and completely start over, i.e. think the problem through and then write decent code.
BTW: I guess I should be a bit more forthcoming about the way that I work. I know that we are always looking to ding others for not working the way that we do, but I find my way works for me, quite well. I won't tell other people that they are wrong, unless they are working for me. I am constantly learning new techniques and approaches, by staying open to, and observing, how others do things. I learn from the examples set forth by others; even ones that do things in a way that I may initially disapprove of.
"Experimenting" is a vital part of my process. I call it "Evolutionary Design,"[0] and it involves a lot of iteration. I have found that it's vital to UI[1], because I can almost never predict how UI will act, when actually presented to the user. The same goes for a lot of communication workflows. I have to "run it up the flagpole, and see who salutes." I almost always find that my theorized approach has issues, and I need to make changes. The old "Measure twice; cut once" approach to software development has caused me great trouble, over the years, and I have found that I need to adjust to new tools, and new contexts.
For example, right now, I am revamping one of my UI widgets[2]. It started as a minor tweak for iOS26, but I realized that it's a bit "long in the tooth," and that I can make it more robust, simple, and usable. I have been running the test harness all morning, seeing issues, and going back to the code, and tweaking.
[0] https://littlegreenviper.com/evolutionary-design-specificati...
[1] https://littlegreenviper.com/the-road-most-traveled-by/
[2] https://github.com/RiftValleySoftware/RVS_Checkbox
That’s often what I do. It saves me the “blind alleys.”
I find they often cause more trouble than they are worth, because they are completely wrong, and need to be “unlearned.”