It would be cool if it included sample OBJ files to entice me to find my own later. Otherwise I feel like I just hit a wall immediately in the app will probably not try it again.

My point was more that I've seen product demos where parts of a product were presented as having been pored over painstakingly when in reality it was decided on day one that it would work that way. However, because it's a prominent feature, it feels cheap to show the reality, so I get that for demos there's a bit of storytelling that goes into it so the audience feels like it was a revelation.

For UX that I've designed myself, I have definitely found that a lot of the great ones required a ton of iteration and almost "courage" to go against my initial bright ideas and look at things from a different perspective. It often required taking away elements that I thought were absolutely required at first but later realized made more sense to go without. If someone were to look at the final result, they would definitely think "Well, obviously that's how it should work." But more likely they'd have go through a similar journey that I did to come up with it if they hadn't seen the solution.

In a way it's like finding out how a magic trick worked. It's only obvious in retrospect.

I've been to a lot of meetups and it's definitely hit or miss and obviously depends on the sociability of the people that show up. The better ones I've attended are generally ones where people aren't trying to network for work purposes and are there literally to just socialize. The networking ones I find very dull as it's people just talking shop and career and if you've nothing to offer them on the career front, they move on quickly.

I used to use TheDraw for doing ANSI art, but I also ended up making my own ANSI drawing tool back then. It's stupid to think of now, but one reason I made it was because I had a monochrome monitor, so I couldn't "see" color. I wanted a feature where I could put the cursor over a character and it would tell me the color there when I was drawing so I could still use color in the work.

I wasn't prolific, but did do a handful of ANSI art pieces for local BBS SysOps who liked them well enough. Only later on I realized when I got an actual color monitor that I had a few color mistakes in them and they never told me. lol

We also had algorithms to detect finger shape to detect location of the pointer and when you were touching the screen. I saw way too many videos of fingers touching screens back then, so it's funny to see similar video clips here.

I think of it differently. Speed is great because it means you can change direction very easily, and being wrong isn't as costly. As long as you're tracking where you're going, if you end up in the wrong place, but you got there quickly and noticed it, you can quickly move in a different direction to get to the right place.

Sometimes we take time mostly because it's expensive to be wrong. If being wrong doesn't cost anything, going fast and being wrong a lot may actually be better as it lets you explore lots of options. For this strategy to work, however, you need good judgment to recognize when you've reached a wrong position.

> This isn't just a Digg problem. It's an internet problem. But it hit us harder because trust is the product.

The statement this is making is presumably the crux of the problem (Digg cannot survive without trust!) but it's worded so poorly that it's hard to imagine someone sat down and figured these three sentences were the best way to make the point.

A lot of developers' identities is tied to their ability to create quality solutions as well as having control over the means of production (for lack of a better term). An employer mandating that they start using AI more and change their quality standards is naturally going to lead to a sense of injustice about it all.

I think there are multiple dimensions that people fall on regarding the issue and it's leading to a divide based on where everyone falls on those dimensions.

Quality and standards are probably in there but I think risk-tolerance/aversion could be behind some how you look at quality and standards. If you're high on risk-taking, you might be more likely to forego verifying all LLM-generated code, whereas if you're very risk-averse, you're going to want to go over every line of code to make sure it works just right for fear of anything blowing up.

Desire for control is probably related, too. If you desire more control in how something is achieved, you probably aren't going to like a machine doing a lot of the thinking for you.

I also was using an Intel MacBook Pro with 16GB at the time. Doing the same thing there was much smoother and snappier. On the whole, it actually made me want to just the laptop instead since it "felt" nicer. (This isn't measuring build times or anything like that, just snappiness of the OS.)

As I rewrote it, I started pulling in more "nice to haves" or else opening up the design for the potential to support more and more future features. I eventually got to a point where it became unwieldy as it had too many open-ended architectural decisions and a lot of bloat.

I ended up scrapping this v2 before releasing it and worked on a v3 but with a more focused architecture, having some things open-ended but choosing not to pursue them yet as I knew that would just introduce unneeded bloat.

I was quite aware of the second-system effect when doing all this, but I still succumbed to it. Thankfully, the v3 rewrite didn't take as long since I was able to incorporate a lot of the v2 design decisions but scaled some of them back.