It brings me peace to see other people thinking this way. You should be an active participant on the highway, making decisions to maximize flow. Leaving space so people can merge, controlling speed to smooth slowdowns, anticipating traffic patterns, etc.
All of the people tailgating are contributing to the congestion.
99% of vscode themes are like the one he showed. IMO, the best themes do typically have minimal/functional highlights, which results in more text that is the base color.
It doesn’t have to be your some purpose; it could be within your normal working hours. It’s basically just choosing a goal to be intentional with at work.
Could be wrong, never used Pydantic. But looking it up it seems like it's used for validation/typing of external data. Sounds like it's mainly going to be doing schema validations. So, your data arrives at your domain layer and you have guarantees based on Pydantic's validations. At this point, your validations are going to semantic in nature based on your domain; what value is Pydantic bringing?
Often you want your domain models to be structured differently than API models, to make them as convenient/understandable to work with as possible for your use case. If you already have different models, why would you want Pydantic in the domain? Even if they start out the same, this would allow them to more easily evolve to be different. I'm not a python expert, so I could be missing the point on Pydantic, but it seems like its value is at the edges of your application.
The article is written for those who want to apply DDD/onion architecture to Python apps using Pydantic. Those concepts explain the motivation and the article assumes the reading knows about them. As others are writing, it may not be worth it to apply this to simple apps, but as an app grows in complexity it will help make it more extensible, maintainable, etc.
I'm not a Python expert, but looking into it briefly it seems like Pydantic's role is at application boundaries for bringing validation/typing to external data sources. If you are not working with external data, there is no reason to use it. So, if you separate out a domain layer, it brings no benefit there. Creating a domain layer where you handle business logic separately from how you interact with external data means those layers can evolve independently. An API could change and you only need to update your API models/mapping.
I overall agree. The one thing I will say is that what you call code organization (anything pre-compilation) also includes structuring the code to improve maintainability, extensibility, and testability. I would therefore disagree that code organization is only basic hygiene, not part of design, and not a large part of the “craft” (use of that word is something I’ve changed my opinion on—while it feels good to think of it that way, it leads to exactly the thing we’re discussing; putting too much emphasis on unimportant things).
Code style though, I do agree isn’t worth stressing about. I do think you may as well decide on a linter/style, just so it’s decided and you can give it minimal energy moving forward.
He has been on shows where he’s an ass and shows where he is not. Watching both, it seems like the former is purposely done for the drama and latter is closer to what he’s actually like. Who knows what he’s like with no cameras in an actual kitchen, and maybe it’s just because he’s older now, but it seems to me that the majority of content he’s in he seems really nice.