© 2024 Reid D. McKenzie, all rights reserved.
At Twitter we have regular employee training courses on a number of subjects. These are my notes from our class on writing technical documentation for developers.
Volker Armin Hemmann wrote:
if we are talking about people who are only able to install gentoo because of an automated, graphical installer, then we will get: a lot more ‘bug reports’ that are not ones. a lot more really really stupid questions (I wait for the day, someone asks, where he can find the gentoo-homepage), and no new developers (but a lot more work for the existing ones).
One might also imagine we’d get less questions on actually installing Gentoo and more on doing stuff with it. There I go again with my tricky logic.
All successful and useful projects get new people. It’s a fact of life and frankly if you aren’t, you’re doing something wrong. That holds true from the Gentoo project to the Roman Empire. If you can not integrate new people successfully into your organization, it will fail.
Gentoo has in fact from the very start been about making things easier. Easier to pick the packages you want, easier to upgrade, easier to custom build packages, easier to update etc files, etc. Gentoo has even gone out of its way to make better how-tos and is known in the Linux community at large for having just about the most useful and friendly forums.
Gentoo can either continue extending the infrastructure to support the people being attracted to a damn useful distro. Or clowns like you can attempt to keep Gentoo all to yourself with Jim Crow style exclusionary tactics.
kashani
So Daniel Compton (@danielwithmusic) is a good bloke. We’ve been co-conspirators on a number of projects at this point, and I just wanted to share a quick vignette before I pack it in for the night.
Let’s talk about another concept that’s as old as the hills - code review.
In software, there is an ever present tempation to declare that something is finished. To look upon an artifact, to pronounce it perfect, and to believe that it will persist unchanged for all time. This is the model of “martian computing” which begat the Urbit project. And it’s wrong.
Let’s talk about Stanislav, probably best known for his blog loper-os. He’s interesting in that I’m indebted to him for his writing, which was very personally influential, and yet I consider him useless.
For the last couple of years I’ve been working with Clojure, a lisp which runs on top of the JVM. My reservations with Clojure itself, and Clojure’s maintainership are at this point fairly well established. However I’d be lying if I said that after thinking long and hard about the way I want to develop software I’ve come up with anything incrementally achievable and better. Clojure’s syntax is convenient. Its datastructures are clever. Its immutable defaults are sane with respect to any other language. Its integration with the JVM while fatal to its own semantics ensure unmatched leverage. In short, I don’t know if it’s possible to do better atop the JVM.
Ferd T-H was kind enough to perfectly voice one of my long standing frustrations with Clojure and it feels like many small programming communities and I couldn’t resist sharing.
As with some of my other posts, this was originally an email which turned into enough of a screed I thought it would be of general interest and worth posting. Some op/ed material has been removed, but the technical details are unaltered if not clarified.