spicemonger

Most of the content was delivered as a 30min to 1hr lecture and then 3ish hour time to implement what was covered. So that portion was basically heads down, though I guess you could have connected with someone to chat while you were working.

But there were some small group breakouts to discuss the topic and get to know one another. And David would try check in with each person one-on-one every day to answer questions, give tips, and say hi.

So generally, I'd say this is not a high interactivity course like a group project or something. Everyone is working on a separate implementation.

Though, I took the courses online. And, it looks like that's how he's offering them now. But around the time I took the 2 courses, he had just switched to doing that because of COVID. Presumably, the in person courses offered a lot more time to socialize and go out for a drink in the evening.

I've taken 2 of David Beazley's courses.[1] And, I highly recommend them. If you haven't seen some of his talks, he's very good at explaining things by building them from nothing.

I took 2 courses: "Rafting Trip" and "Write a Compiler". Both were awesome. The Rafting Trip took us through implementing the Raft consensus algorithm from scratch. And the "Write a Compiler" course had us build a small language using LLVM.

Both courses (but especially the Rafting trip one) were definitely for experienced programmers. In the courses I took, people generally had at least 5 years of professional work. And even still, there were a few people that really struggled to stay on pace in the course.

But at the end, most people had a (kinda) working Raft library or compiler!

[1] https://dabeaz.com/

I am sympathetic to Drew's view that packages require establishing a longer term trust relationships. That's literally what is happening when you use someone's package. You are trusting them.

So, I want the situation to change.However, there are some problems I see:

1. Developers are used to using their language of choice's solution for virtual environments (ex. go modules, node_modules, python venv, etc)

2. Instead of 1 relationship with the language package manager, you need N (where N is each platform you "officially" support)

3. Younger/newer packages aren't in native package managers yet.

4. Different apps want to use conflicting versions of libraries

For #1, VM's/Vagrant and Docker are a good answer. But many dev's only know their language's ecosystem and don't know shell well enough.

Personally, I think every dev needs to know their system well enough to be able to manage their environment and do things on the shell. But after working with more juniors, this is going to be a huge stumbling block.

For #2 seems unavoidable unless someone automates submitting to a bunch of package managers. And worse, many package managers do a lot of patching. Again I'm sympathetic to patches b/c many devs have a lot of bad practices. But this is a huge problem for devs, because it bogs down support channels with bugs tedious to track down and reproduce.

There's a kind of catch 22 in younger packages too, where they aren't in the repo's so no-one uses them. But no-one uses them, so it's not worth the effort to get into the repos.

For #4, this seems to be the perennial static vs. dynamic linking debate. Where newer languages and systems seem to be falling on the static side.

TL;DR: I live native package managers but there's too many problems to ignore. Until the dev experience is better, people are going to continue using language package managers.