Meetings can be work, but often they are a waste of time. Often they are only done, because the company has not found a better way to structure itself, which is also accepted by the management lawyer, who often has a profound fear of loss of control and likes to micromanage. If you can zone out for most of the meeting, and not experience negative effects from that, then the meeting was a waste of your time.
Depends what they mean. Generate working code all the time or after going a few iterations of trying and promoting? It can very easily happen, that an LLM generates something that is a straight error, because it hallucinates some keyword argument or something like that, which doesn't actually exist. Only happened to me yesterday. So going from that, no, they are still not able to generate working code all the time. Especially, when the basis is a shoddy-made library itself, that is simply missing something required.
What stops you from doing the same thing in CSS? It is trivial to assign a specific CSS class to an element that is the root node of a "component" and scope rules under that.
If the designer is not aware of the ins and outs of the medium they are supposedly working with, they are not a very well informed and educated designer.
Just like I don't presume to be able to make a great product packaging design, without knowing firstly much more about visual composition and design, but also secondly the material and form and shape I am designing for. Will that be a plastic wrapper, a paper wrapper or some cardboard packaging? Without knowing the limitations and properties of each, how can I expect to create a good design?
Being that uninformed to me seems like not giving a shit about the quality of work one delivers, ergo not giving a shit about ones job, or simply not having the required understanding or skill to be any good at ones job.
> not giving a shit about the quality of work one delivers
I’ve learned in the past decades that people who care about quality is the minority.
Look at any B2B software. They don’t care because their customers are different than who uses their products. They care about their customers only (managers). They pay attention to users as much as minimally possible without loosing customers.
This stuff really shouldn't be done in 2026 any longer.
I mean it's a hobby project, so you are free to do what you want, of course. Just please never do this in a professional environment. This is one reason Python projects catch so much flak from many people. One day it works, next day it doesn't. And surely not 2 years later, when a random person stumbles upon the repository and wants to try things. Please make your projects reproducible. Use pinned versions and lock files containing hashes, so that other people can get the same setup and it doesn't become an "It ran on my machine." project.
> One day it works, next day it doesn't. And surely not 2 years later, when a random person stumbles upon the repository and wants to try things.
I would be very surprised if a project like this were broken by a Numpy or sounddevice update within the next 2 years. sounddevice is too simple (and the code uses it in a localized and very simple way), and Numpy too stable (they're pretty good about semver, and it was 18 years from 1.0 to 2.0.0). Anyway, people qualified to set up Python code locally in "dev mode" following instructions like this, should also be qualified to notice the last-commit dates and do that kind of investigative work. (We also now have installers that can just automatically disregard packages published after a certain date.)
The flip side of this is that having every project pin an exact version increases the chance that different projects needlessly demand different versions. The same version could be hard-linked into multiple environments (even if you aren't brave enough to try to stuff multiple applications into a common "sandbox"), avoiding bloat. And sure, you don't care about a few megs of disk space. But not everyone has a fast Internet connection. And Fastly presumably cares that total PyPI is now in the exabyte range and probably a very large percentage of that is unnecessary.
reply