æon 
software is too hard to compile
this is bad for the ecosystem of software and also culture as a whole
this might sound like a weird claim if you've a) never tried to pull a large software project off a website and build it from scratch, or b) do that all the time. but
it's a problem because it kind of undermines the concept of open source in a pretty basic way. for a lot of software, grabbing the thing and making it do what you want involves an indefinite amount of overcomplicated bullshit as you try to install the right versions of a bunch of dependencies you've never heard of and decipher output from an idiosyncratic build system. you can't just get in there and experiment
which pushes people away from contributing, especially if they have skillsets outside core programmer stuff
i think typically most projects don't see this as an issue, because nobody on the team has a problem with it, and if it gets brought up there are always historical reasons for why it's this way, and it's not THAT complicated, just follow the instructions dumbass,
tech? no! man, see...@aeonofdiscord tbh I see this kind of "blindness to the perspective of the newbie" as both very difficult to avoid, but also a red flag if the project leadership clearly doesn't even make a basic effort.
@technomancy yeah def, i think this is such a widespread problem that it's not even anyone's fault as such. like there are clearly bigger factors causing this (bad tooling, for one)
@technomancy you can work around it and provide a good new-user experience out of the box but it takes effort and in most cases i don't think people see a compelling case for it
@aeonofdiscord there are so many examples of these cases where the experience for the newbie is just unbearably tedious in ways that it's literally nearly impossible for the project maintainers to even comprehend, because there are so many things that they just take for granted because they've been doing it so long they don't even realize they're doing it any more.
Ben S.@technomancy @aeonofdiscord maybe we should normalize blowing away your development environment every few months and recreating it from scratch by carefully following your own project documentation lol
@HunterZ @technomancy unironically endorse this
@HunterZ @technomancy actually i think companies should do this for internal software as well to cut down on onboarding bullshit
@aeonofdiscord @technomancy having just gone through a weeks-long onboarding process for a new project (most of which just went out the window due to funding shifts lmao) I heartily agree.
On a previous project, I got things to the point where you just clone a build repo via git and invoke CMake in a standard way, and it clones the rest of the codebase for you and pulls down the dependencies from Artifactory via Conan. That's pretty much my ideal.
The Doctor
Csepp 🌢@HunterZ @technomancy @aeonofdiscord Not sure if it's a joke, but tools like Chaos Monkey kind of do that and it looks like the companies that use it have pretty reliably working services, especially given how complex they are.
I've also see Drew DeVault recommend something similar for testing backups. Pull the plug on a machine and see if the crew can restore it.
ArneBab@HunterZ At work we actually do that, because we create a new build environment for every release branch (otherwise switching branches can corrupt the caches in IntelliJ — bad reason, I know (well, cache invalidation is hard), but good side-effect ☺ ). @technomancy @aeonofdiscord
13 barn owls in a trenchcoat@HunterZ @technomancy @aeonofdiscord I have to do this when writing docs and tutorials (my main work things ATM) to make sure I get dependences listed correctly, and can be surprisingly hard to work out exactly which bits of toolchain from my 'has everything installed so stuff just builds' workstation is actually required in some cases.
A freshly installed Raspberry Pi 4 (if your software is buildable on ARM) is extremely useful to see what the dependency hell situation looks like IRL.
@HunterZ On second thought: Do you mean I should re-create my Emacs setup every few months? 😱 — my documentation is not yet up for that … @technomancy @aeonofdiscord
@ArneBab @technomancy @aeonofdiscord yes, if that's a requirement for being able to develop in your codebase(s). I would recommend trying to be IDE/editor agnostic though, because different people prefer different IDEs.
Griffith@HunterZ @ArneBab @technomancy @aeonofdiscord
It's amazing how useless / out of date most build sections of a readme are. For projects that have continuous deployment they should just point you to their build YAML file. They have to keep that up to date or their tests fall apart.
@alexjgriffith @ArneBab @technomancy @aeonofdiscord yeah it seems like in a just world, CI/CD build solutions ought to support building for development and manual test too.
@HunterZ CI/CD does a lot more stuff than what you need for development. @alexjgriffith @technomancy @aeonofdiscord
@ArneBab @alexjgriffith @technomancy @aeonofdiscord right. The point is that if you already have a CI/CD solution that automates setting up a build environment as part of its process, then there's little excuse for making developers do those same things manually in order to be able to build the same codebase.
@HunterZ It would be great if the CI would just execute what’s needed for development. What I find strange is how often README’s do not say how to call maven or gradle (what’s the actual "build be" argument?) @alexjgriffith @technomancy @aeonofdiscord