i work for a for-profit owned by a non-profit. This is a weird take. You can shape a product, sure you need to bring in a profit, but there are options of working with your owner (the non-profit) that you just don't have in a publicly traded company.
I am sure people would queue up for the job, fully aware of what it entails.
It is very good and has a succinct coverage of a broad range of topics from Mathematics; just the right understandable level of rigor without being overwhelming.
I think there was a funding campaign once where a developer offered to re-implement the missing Apple APIs, but since they basically put up a standard salary it didn't reach the funding target.
I always wonder at these attributions. Like all windows versions gave you bluescreen and ran Microsoft excel. To me not one stood out particularly bad or good compared to the others maybe after Windows 98 service pack something
Windows 98 was so bad when it came to drivers, lol.
It had the plug and play standard but that only worked half of the time, and if you messed up by doing something like connecting the peripherals before installing the driver you could BSOD while trying to install the drivers and have to rescue the whole OS. Happened to me enough for me to remember it.
And my sister demonstrated how you could delete the recycle bin if you were bad enough at computers, which was fun.
I've also had nearly as many kernel panics on OSX or hangs on Linux as I have had BSODs on Windows (when graphed as a ratio of use over time).
All OSes have flaws and issues, there would never be a perfect operating system with our current understanding of computers, and that's ok.
That being said, my critique does not include OSes that spy on you (for what will be considered a several trillion dollar crime syndicate when this era is written down in history), which is its own entire rant.
Windows Vista got saner permissions support and made the OS survive certain kinds of driver crashes, but on launch a lot of existing software and drivers weren't updated to support those changes so it got a bad reputation. Nobody gave Windows proper credit for these advancements until Windows 7 which had a cleaner launch since most software and drivers were already updated for Vista's changes.
this summarizes pretty well my first thoughts when reading the headline: "How python grew from a language to a community", because the Python community in 2000, the Python community in 2010, these are a different place to "whole world uses Python" in 2025.
Back then it felt like a bit of a club, one that forms around a common hobby. Nowadays it feels more like the "community" of a high-school graduation class. Sure there is community there, but its mostly one of folks randomly thrown together into classrooms.
Folks like Raymond Hettinger would today be totally drowned out in the listicle-style attention seeking times.
> in the web world
I would put that more broadly though, it was web, data-science, there was a point when it became the universal scripting language, and part of me kind of hoped that the crowd would move to nodejs for all of it, so that Python can become more peaceful again. But I guess there is no going back, we went from dinghi to cruise ship, and when the crowd leaves, it will just be a deserted cruise ship.
> I think this is a very lopsided way of looking at pull requests. They are about a lot more than just trust. Reviewing and being reviewed is a great way of learning from colleagues, making common practices gel in a team, and keeping up to date with changes to the codebase. It’s not just a barrier.
I am old enough that my first 2 jobs were subversion-based (repo side, client side git-svn) and both teams didn't care about branching. It might have to do with how awkward subversion branches felt.
Anyway, we would commit (in git lingo pull-rebase & commit) directly and we basically maintained the id of the last reviewed commit and jointly did PR reviews commit-by-commit with the code on the projector in the office.
We had a joint look at code, everyone voiced their feedback ("I don't understand a variable name like `xzc`"), "where is the unit test", "I read in a blog post recently you are supposed to not use classes...". etc. pp. Sometimes fixes would be pushed right in the PR review session so you had the variable renamed 4 commits further.
Anyway, in retrospect it worked surprisingly well at helping the team to develop a joint understanding of values & virtues that the team would like to maintain in their code base. This might of course be nostalgia of a dev looking back into their junior years.
When we finally got pull-requests, we really felt thrown into the future. It was just great. But after a while I started to miss the direct conversations about code with fellow humans.
And honestly I couldn't tell whether PR really improved the quality of the code base in the long run. They lowered the probability of bad code being committed to the code base, but also lowered the probability for a dev to just fix awkward things while they stumbled over them.
I miss that too. There’s so many little micro-improvements that are possible when you’re reading code— clarifying a variable name, expanding a comment, adding a test case, and it’s unfortunate when those things are lost under the inertia of it being a pain in the butt to create PRs and get them reviewed.
At the same time, I expect your PM is delighted that you’re not wasting time getting distracted with all that yak shaving nonsense and are instead working on the next burndown ticket that has been assigned a t-shirt size and the appropriate number of story points.
Same here. At my previous employer, we’d pair regularly, even on PRs. Larger blocks of work would warrant a mini-standup so the team could all review together in real-time (after an async review with comments). It’s an efficient use of time while acknowledging the need for real-time, humane communication.
> When we finally got pull-requests, we really felt thrown into the future. It was just great. But after a while I started to miss the direct conversations about code with fellow humans.
Why is this disjoint though?
Our newer colleagues are currently bringing in their first bigger contributions and changes to the config management. We're using short-ish lived feature branches of a week or two with pull requests.
This is good, because I can spend some time understanding what they are doing and I can prepare some ideas and examples for improvements, before we have a call to talk about these changes.
I'm also entirely willing to move my bigger changes into branches and a PR and spend some afternoon with the team to talk about good practices, like structuring commits, naming, ansible code structure, ... and see if other people enjoy that as well. Management wants more stability and broader understanding of our code bases, so moving slower and reading and discussing more code seems up that alley.
I used to think this way, i.e. assuming a misunderstanding on the product development side.
Nowadays I think its more of a conscious decision many times. Like "We know someone could travel to france as a tourist, but its a small fraction of french IP addresses so screw these people". etc.
Honestly, its infuriating. There are three languages that I speak and understand sufficiently well for consuming youtube videos. I don't ever want these to be translated.
And then, the translation of video titles etc. is often surprisingly bad, because (I think) they don't consider the video context / content while translating, so it almost looks like a translation-by-dictionary-lookup translation.
Most infuriating though is when you watch a video of a channel you watched for years and all of the sudden the audio is auto-translated into your primary language. So cringe.
I am sure people would queue up for the job, fully aware of what it entails.