Comments URL: https://news.ycombinator.com/item?id=46433246

Points: 1

# Comments: 0

Not only that but while driving you might have to react very fast if something happens and you need to divert to avoid a crash, if you need to grip harder in the middle that are precious milliseconds that you could have saved. At least if you at high speed.

This is really interesting. This is the opposite I do when writing for myself and what I would probably do if publishing a blog. I really like adding nuance when taking notes as it helps me when reading them later. But now I'll pay attention to not adding them when publishing.

Comments URL: https://news.ycombinator.com/item?id=46081628

Points: 15

# Comments: 1

And the pmos wiki is severely lacking IMHO.

As with many other things, each strategy will take you at some point (just playing matches), and to get beyond, you many need very different strategies (learn from other players, get coaching, etc).

Comments URL: https://news.ycombinator.com/item?id=45186011

Points: 150

# Comments: 121

To convert the comic to :̶.̶|̶:̶;̶ is a very very distance, to remove the strikethrough is nothing.

> This may be stored as a boolean column, is_confirmed, in the database. It makes a lot of sense. But, you're throwing away data: when the confirmation happened. You can instead store when the user confirmed their email in a nullable column.

When I'm looking at a database schema and I see a boolean is_confirmed I can be 99% sure what it means. Now if I see a datetime confirmed column, can I be sure that if I want to know if it was confirmed this will not be null? I'm definitely not 99% sure anymore and I would be scared of making this assumption in my code. Obviously I would still think I can use, but going from 99% sure to 80% sure is a recipe to making brittle code.

But even if the intended solution seemed simpler, it could be much harder to discover it.

> Over time, patterns emerged, either by others pointing them out to me, or them occurring to myself. The patterns became higher and higher level, and I had more and more power and agency to fill in my gaps, and those in turn made my problems smaller, manageable. Challenges, even.

Could you give some examples of those patterns?

1) you dont need AI to generate code because you dont need any code at all? If you dont need any code then this discussion is useless.

2) AI generates more and worse code. Well, if you start with this assumption of course the conclusion is dont use AI. But then this is a big assumption to make, you dont back it up with anything and you dont even mention this at all.

Lets consider other things:

1) AI will generate less and better code that you would. Shouldnt you use it?

2) AI will generate code the same quality as you would but in 50% less time. Shouldnt you use it too?

I've tried journaling before but I would rarely read it for anything. This is something I want try again.