25 years ago I had a colleague who had grown up in the PRC. He had a forest of newspaper clippings pinned on the wall of his cubicle with stories about school boards in the US banning the teaching of evolution, discussion of sexual health, and stuff like that. When I asked him about it, he pointed and said, "Every one of those is an engineering job moving to China." I've been thinking about that a lot over the past week…
There are two other versions of the story. In one, Charlie Brown knows Lucy will pull the ball away but keeps trying to kick it because he has internalized everything have said about him and believes repeated disappointment is all he deserves. In the other, he's waiting for Lucy to grow bored and ask, "Why do you keep trying?" so he can say, "Because I love you, and am here to help you get past this." Schultz's point is that from the outside, it's hard to tell these stories apart.
I believe it should be possible to distribute Python packages as Rust crates. If you have actually done this and can point me at an open source proof of concept, I would be very grateful for a link.
On the one hand, I am genuinely excited by this book. On the other, it will cost over CAD$300 per copy for the digital edition and even more for print, which greatly reduces the number of people who will have a chance to be excited by it. Academic publishing makes me very sad.
Zhang et al 2022: "Corporate Dominance in Open Source Ecosystems: A Case Study of OpenStack" http://dx.doi.org/10.1145/3540250.3549117 "We find evidence of company domination in >73% of the repositories in OpenStack…We identify five patterns of corporate dominance: Early incubation, Full-time hosting, Growing domination, Occasional domination, and Last remaining. We find that domination has a significantly negative relationship with the survival probability of OSS projects." #nwit
1. Have students who are safe and well nourished, not victims of systemic discrimination, and live in supportive home environments.
2. Work in an educational system that has stable long-term funding and is administered by people who respect your professional expertise.
3. Ignore posts that put all the responsibility for being a great teacher on you rather than saying that collective action to achieve #1 and #2 are what will actually make a difference.
That feeling when someone's device accidentally bluetooths to the open-air speakers and everyone gets to hear the protagonist of the audiobook they were listening to muse about the taut, muscular ass of one of the other characters.
20 years ago this week I received a grant from the Python Software Foundation to rewrite my notes on software engineering for scientists and publish them under an open license. Those notes later became Software Carpentry.
@janeadams one of my mistakes when I started Software Carpentry was thinking that knowledge only needed to flow one way. In retrospect, for every lesson on version control for mathematicians and biologists, there should have been a lesson on math or biology for programmers who were going to work with scientists. And one of the many things that makes me angry about how science is funded is that there isn't a National Education Foundation alongside the NSF to support work like @j2kun 's book …
Barba Roque et al 2024: "Unveiling the Energy Vampires: A Methodology for Debugging Software Energy Consumption" https://arxiv.org/abs/2412.10063 Presents an energy debugging methodology for identifying and isolating energy consumption hotspots in software systems. One finding: Redis uses 20% more power on Alpine than Ubuntu in some cases because of a difference in different C library implementations of memcpy. #nwit
Arya et al 2024: "The Software Documentor Mindset" https://arxiv.org/abs/2412.09422 Explores why people voluntarily create documentation for open source software projects, how they pick topics, and other related factors; none of the findings are particularly surprising in retrospect, but that's not the same as saying I could have predicted them. #nwit
Nourry et al 2024: "Myth: The loss of core developers is a critical issue for OSS communities" https://arxiv.org/abs/2412.00313 "89% of studied projects have lost their core development team at least once…in 70% of cases, this happened in the first three years of the project… most projects rely on a single core developer [and] only 27% of projects that were abandoned were able to attract at least one new [core] developer." actually makes it sound like loss of core devs *is* an issue, not a myth… #nwit
I will pay cash up front for @grimalkina and colleagues to write a paper called "Ten Signs That the Software Engineering Paper You're Reading is a Plate of Raw Hamburger Paired with Rat Shit in a Back Alley Next to a Dumper" that calls out specific things they've seen in SE papers that are so wrongheaded and uninformed that their presence is a sign a printed copy is fit only for lining a bird cage (and a digital copy fit only for training LLMs you're going to give to people you dislike).
I program, write, and teach. Co-founder of Software Carpentry and It Will Never Work in Theory; co-editor of The Architecture of Open Source Applications.