I suspect that my normal workflows might just have evolved to route around the pain that package management can be in python (or any other ecosystem really).

In what situations are uv most useful? Is it once you install machine learning packages and it pulls in more native stuff - ie is it more popular in some circles? Is there a killer feature that I'm missing?

If you have hundreds of different Python projects on your machine (as I do) the speed and developer experience improvements of uv make a big difference.

I love being able to cd into any folder and run "uv run pytest" without even having to think about virtual environments or package versions.

Do you run those projects on the host system as your normal user without any isolation?

Yes, which makes me very vulnerable to supply chain attacks.

Yikes! I had a scare once, and since then I only run sandboxed code or scripts I've written with minimal 3rd party deps.

I assume you have other mitigations in place?

Not really. I have good backups and I try to stick with dependencies I trust.

I do a lot of my development work using Claude Code for web which means stuff runs in containers on Anthropic's servers, but I run things on my laptop most days as well.

Imo, uv scripts with the dependencies in the header.

https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...

I guess that could be useful. I don't have many standalone python scripts, and those that I do have are very basic. It would be really nice if that header could include sandboxing!

So much this! I've been bugging Astral about addressing the sandboxing challenge for a while, I wonder if that might take more priority now they're at OpenAI?

UV is most useful because it is so much faster than everything else. All the other features I could do without.

Yep, the speed is nice, I can't argue with that!

At least in space there is lots of space and no heat /s - I'd love for Next to exist in a vacuum

While the license is important, it's the community that plays the key role for me. VC funder open source is not the same as community developed open source. The first can very quickly disappear because of something like a aquihire, the second has more resilience and tends to either survive and evolve, or peter out as the context changes.

I'm careful to not rely too heavily on VC funded open source whenever I can avoid it.

I like your interface for switching between the backgrounds and having a small panel to tweak the parameters. I played around with procedural patterns using SVG/canvas/webgl a while back and this makes me feel like re-packaging the way it's represented.

Thanks, I've designed a few UIs for manipulating graphics and spent a few tries iterating and improving this one in particular. There was a need to show as much background as possible, sometimes the limitations lead to some creative choices. I'm quite pleased how it came out myself.

It's probably vibe coded, but also, it's next.js

I can't remember the exact phrasing, but I read somewhere long ago that what you read now, you become in 5 years from now. As in, right after reading something, you think and deliberate about it, but in 5 years from now that becomes part of your subconscious and you can't activity filter it.

Not 100% sure this isn't sarcasm, but I'll bite.

For me (a non-early career dev) these projects terrify me. People build stuff that just seem like enormous liabilities relying on tools mostly controlled and gate kept by someone else. My intuition tells me something is off. I could be wrong about it all, but one thing I've learned over the years is that ignoring my intuition typically doesn't end well!

Yes, you should have a website if you have a business or you wish to maintain any public footprint on the internet.

But it is both simple and complicated to setup a website these days.

For a technical audience there are great tools/options to choose from. You can build a rock solid website serving tons of traffic using 3rd party hosting for cheap. But, there are lots of options and as a geek it's easy to get rabbit-holed in the process.

For non-technical users it's similar, many solutions that require minimal technical knowledge. But the technical knowledge is very leaky and most providers border on landlords seeking to extract their rent while holding users hostage.

I'm working on something small in a specific niche aimed at non-technical users. I worry a lot that I don't fully understand what keeps people from building their own site?

Are your coworkers producing the code using LLMs? And what level of trust do you place in them?

For half my coworkers, their LLM code is better than their code.

That’s depressing. For 80% of my coworkers their LLM code is horrible. Only the seniors seem to use it well and not just spit out garbage

I think that goes back to whether they are programmers vs engineers.

Engineers will focus on professionalism of the end product, even if they used AI to generate most of the product.

And I'm not going by "title", but by mindset. Most of my fellow engineers are not - they are just programmers - as in, they don't care about the non-coding part of the job at all.

I have a theory that when you have 2 developers working in synergy, you're at something like 1.8x what 1 person can do. As you add more people you approach 2x until some point after which you start to decrease productive. I don't think that point is far beyond 5.

This is very close to the thesis, or at least theme, of the essays in The Mythical Man-Month, Fred Brooks. Some elements are dated (1975), but many feel timeless.

Brooks law “Adding manpower to a late software project makes it later” is just the surface of some of the metaphorical language that has most stuck with me: large systems and teams quickening entanglement in tar pits through their struggle against coordination scaling pains, conceptual integrity in design akin to preserving architectural unity of Reims cathedral, roles and limitations attempting to expand surgical teams, etc.

Love a good metaphor, even when its foundation is overextended or out of date. Highly recommend.

My experience of pair programming is the opposite. In a pair I get maybe 4x as much done as when working alone.

Mostly it's because when we hit a point where one person would get stuck, the other usually knows what to do, and we sail through almost anything with little friction.

Maybe the multiplier is 4x and by the time you have a team of ten you're back down to 2x? My theory is a bit of a hyperbole and I don't know what the multipliers would be? But I know that many times you can move quick when you're small.

And to your point, a single person can easily get stuck, I know that applies to me many times.