Rowan Thorpe

It would probably be configured using YAML and require health checks and quorum monitoring. I’m not sure I would want that job, especially on-call shifts. The consequences of downtime would be on a whole other level.

That’s definitely one of Randall’s more wholesome ones. By the way, this is one of my favourite book quotes on that subject:

The best thing for being sad," replied Merlin, beginning to puff and blow, "is to learn something. That’s the only thing that never fails. You may grow old and trembling in your anatomies, you may lie awake at night listening to the disorder of your veins, you may miss your only love, you may see the world about you devastated by evil lunatics, or know your honour trampled in the sewers of baser minds. There is only one thing for it then — to learn. Learn why the world wags and what wags it. That is the only thing which the mind can never exhaust, never alienate, never be tortured by, never fear or distrust, and never dream of regretting. Learning is the only thing for you. Look what a lot of things there are to learn.

T.H. White, The Once and Future King

In terms of the “default instance” suggestion, I have an interesting hybrid suggestion. What about having an “easy on-ramp” instance where you get registered for one month with a hard-exit (auto-migrate to other instance, perhaps using some kind of federated-auth/token system for the migration, and forced password-setup on first use of the new instance). At any point during on-ramp the user could configure destination-instance from a list in the settings (or configure auto-export for manual import to any other “auto-migrate-unsupported” instance), with optional early-migration if the user has decided before the end of the month. Optionally a recommendation engine could iteratively curate a list of suggested instances based on usage during on-ramp (admins of those instances could provide - limited number of - tags of their choosing for the engine to use for matching). That part could be opt-in because probably a lot of users would find it creepy. The UX would need to be very user-friendly “pointy clicky” because that would be the overwhelming target demographic of such an instance. I think “on-boarding and educating” is better than “gatekeeping” (which feels like the “if you need to ask the price you can’t afford it” shopping trope). A nice side-effect is it already painlessly introduces users to the killer-feature “easy migration” between instances due to data-portability.

So where does the PFJ fit in this timeline? :-D https://www.youtube.com/watch?v=WboggjN_G-4

I long ago stopped getting caught up in “that discussion” about recent trends despite a stream of people lobbing leading questions to get the ball rolling. Because I also try to not do so more rudely than necessary, I have developed several diplomatically worded (or at least ambiguous enough to float opaquely off to the side of the offense spectrum) ways of essentially saying the following: The simplest and cheapest way of [A] learning the “computer science” end of software is by becoming proficient in Lisp, [B] learning the “engineering” end of software by becoming proficient in Forth, [C] learning how “busywork” is a dangerous and demoralising thing to confuse with “actual work” by maintaining some Java code, [D] learning how insidious and self-sabotaging “expert beginner syndrome” is by reading a lot of the relevent code-reviews and blogposts when maintaining Javascript & Python projects, [E] learning how mob-mentality and populism can lead to selective blindness and architectural stubbornness by working with large volumes of C & C++ code, [F] learning how it is all really abstraction-layers over something akin to an old-shool phone switchboard by working with Assembler, [G] learning how the only work with longevity is that which stands on the shoulders of giants by using Fortran libraries, [H] learning how the mere act of developing using languages with baked-in discipline can be inherently educational by using DbC/TDD/BDD/dependent-type/formally-verifying/etc based languages (SPARK-Ada, Haskell, Eiffel, ACL2, Rust, etc), and then [I] learning how - after a certain level of experience - the languages, frameworks, and tools become less important than the engineers’s mindset and the work that happens both before and after the fingers hit the keyboard…by finding semi-performant techniques for implementing masochistic things like a VM and a network stack in Bash script (as hobby tasks, not for real use). If they are coming from a more hands-on/hardware background I also recommend [J] how eye-opening it is to maintain your own customized LibreCMC image flashed onto an open router (the older/smaller the HW the better, because you have to be increasingly creative with your kernel & OS configs), and [K] how educational it is getting a RISC-V working on an FPGA. I top it off by saying that [L] despite coding on-and-off since my start with z80 assembler on an Amstrad in the mid-80s I still feel like a beginner with so much to learn, and [M] that fact is by far the part I love most about the field (not just field of “work” but of “mental endeavour”) - far more than status/seniority/raises. I find I don’t get bombarded so much with JS-framework-du-jour zealotry and expert-beginnerism after that.