While the downsides of this are obvious, I wonder if in the long run this would push our cities towards better designs, by encouraging the mixing of residential and office buildings, and by encouraging improvements to implementing public transit that can quickly and efficiently move a dense population between their homes and their jobs. It probably wouldn't work, but I can dream.
That sounds great, and I care enough about this that I moved somewhere with well-designed transit, but I still think it's a problematic policy. Some people might want to live in a bigger place further out, and if they're willing to make the long commute (and pay for its negative externalities, which most aren't) then I don't see why they can't.
I actually prefer to bike to work, but I doubt any employer would be willing to give me my hourly rate for that...
Have you ever tried to hire developers? I have, many times. It's shocking how incapable most people with a history of working as senior developers for 10+ years are at basic programming questions. I'm talking about stuff at the level of Fizz Buzz, or barely more difficult, being solved in a language of their choice with ample time.
Through all of the technical interviews I've run on behalf of multiple companies, I've become convinced that our industry is full of imposters. A terrifying number of people who are employed as developers cannot code, beyond making tiny edits to existing code, or slinging StackOverflow answers and AI generated content around. They cannot think for themselves. They rely heavily on their coworkers to make any substantial progress. If anything, modern AIs have made these people more difficult to spot. I've found these imposters within the companies I've worked for too, and if it's not possible to move them to a non-technical role where they can be productive, then it's best to fire them. If that isn't possible, then keep them out of the way of any critical work, but know that they'll continue to be a drag on their team, and will decrease the moral of those on their team who have to keep covering for them.
Once I even worked on a team (as a junior) where only 3 members out of ~16 even knew the language that was exclusively used for the job. The remaining team members accomplished nothing every day. Those stand-up meetings were painful. Drawn out to 45+ minutes of standing in a circle while the unproductive team members found new ways to explain why they haven't made progress. Then I'd see them return to their desks, and not even open their IDEs for weeks at a time. They seemed to keep their jobs because their boss didn't want to fire them, and it cost him nothing personally to keep them around, offering them a sort of corporate welfare. Perhaps having such a large team even helped him politically, but it's unclear if he cared about that since he also spent almost all of his time slacking off, playing games in the break room, while the 3 productive team members carried the rest of the team.
That sounds like a really challenging situation, and I can see how it would be disheartening to work in an environment like that. It makes me wonder if part of the problem lies in how companies approach technical growth and team dynamics. For example, instead of just identifying unproductive team members, do you think those people could have benefitted from structured mentorship or training programs? Or maybe clearer performance metrics that highlight where they’re struggling?
It’s also interesting to think about how managers could be supported better. If your old boss had been more engaged, perhaps they could’ve restructured the team or helped those who were falling behind find roles that suited their strengths better. Have you ever seen a company handle this type of situation well, or is this kind of dysfunction just too common?
I have seen team members fall below expectations, or burnout, or otherwise become unproductive, but then recover. In every case, their manager was a key part of the solution (and sometimes a key part of the original problem). If a person is really stuck on their current work, it can be demoralizing to have it taken away and assigned to others, but it can also be a relief. One thing that I've seen help is to let devs be more self-directed. Try to nudge them towards things that are important for the business, but focus on doing that by really convincing them of the value of that work. If they don't want to do that work, try to understand why, and consider changing plans based off of that.
When they suggest you pin your dependencies, they don't just mean your direct dependencies, but rather all transitive dependencies. You can take this further by having a lock file that account for different Python versions, operating systems, and CPI architectures – for instance , by using UV or Poetry – but a simple `pip freeze` is often sufficient.
That works for your project, but then nobody can include you as a library without conflicts.
But having that lock file will allow somebody to reconstruct your particular moment in time in the future. Its just that those lock files do not exist for 99.9% of Python projects in time.
That works for your project, but then nobody can include you as a library without conflicts.
I think this is the core to much misunderstandings and arguments around this question. Some people are writing code that only they will run, on a python they've installed, on hardware they control. Others are writing code that has to work on lots of different versions of python, on lots of different hardware, and when being run in all kinds of strange scenarios. These two groups have quite different needs and don't always understand each other and the problems they face.
A lib can still lock its dependencies and have version ranges declared at the same time. The lock file is an artifact than is used to reproducibly build the lib, while the version ranges are used to see, whether some other project can use the lib.
It is only a matter of tooling. Locking ones dependencies remains the right thing to do, even for a lib.
This is of course the right answer. But unfortunately it has only recently become supported by packaging tooling, and is extremely uncommon to encounter in the wild.
I've migrated a couple moderately large projects from pyenv & poetry to uv, and it has been great. The switch was easier than I expected. I uninstalled pyenv after a few weeks, as I realized that uv makes it irrelevant. I've also replaced pipx (which manages Python tools/programs each with their own virtual environment) with uv's tool feature. I used uv for every new Python project. The only thing it's missing that's important for me is support by Dependabot on GitHub. Once Dependabot can update its lock files, I'll be able to uninstall poetry.
I had some trouble migrating from Poetry to uv because the dependency constraints are different. With Poetry, you can use caret ^ and tilde ~ version constraints. Apparently this is outside the PEP spec so uv doesn't implement it. Understandable, but it does make the migration a bit troublesome at times.
> Are we going to start filing lawsuits against sugar manufacturers for all of the health issues they caused?
Like with the fossil fuel industry, the sugar industry also invested heavily into misleading the public about how damaging their product is. With that in mind, it seems at least somewhat reasonable for governments to file lawsuits against them to punish them, and to recoup some of the lost value due to their negative externalities.
Celery workers default to acknowledging messages messages as soon as they've been recieved, leading to them failing to be processed if the worker crashes. Dramatiq, by contrast, will only acknowledge a message once a worker has finished processing it. As a result each message may be processed multiple times (if the previous worker handling it crashes), but there's a guarantee that each message will be processed to completion at least once.
They also call more attention in their docs to how to make the broker confirm message delivery than Celery does. Overall Dramatiq seems more concerned with robustness and reliability than most other Python task queue frameworks.
