http://www.sage.org/lists/sage-members-archive/2005/msg02937...

If they just want you to add user accounts, that's weird. But SRE style jobs are where a lot of guys who write famous open source systems software end up.

from the google groups post: "Yes, sysadmin skills are essential here, however we also require a very strong skillset in development, automation, high-level systems architecture, networking, statistics and general problem-solving."

sounds like a description of zed!

In that respect, the job description is pretty accurate. You do need a strong skillset in development, automation, high-level systems architecture, networking, statistics, and problem-solving to perform well as an SRE. You need to be able to think on your feet and evaluate the suggestions that engineers are throwing at you before somebody does something stupid, as well as the ability to figure out how to avoid having problems recur.

On the contrary, some of the code I've seen written by SREs has been among the most delicate, finely tuned, and "hard core" (by my definition) I've seen.

It's not required, but that pedantic nature seems to help make a good sysadmin.

Same thing with programming. If you are given enough freedom to do the job right, and you can find a way to motivate yourself, there are no bad programming jobs.

Zed Shaw himself has bragged about a system he wrote which does the kind of business logic you mention -- except by his description it's a meta-programming system that can add rules almost as fast as they can think them up. That sounds like some sort of constraint solver, which is among the fanciest kind of programming around.

I liked OmniTI's description of a role akin to SRE and the progression through the web operations career path they identify: http://omniti.com/seeds/what-is-web-operations .

"This role is in no way fitting for failed developers, it is for developers/engineers that have outpaced their career path. One that has a deep understanding of how things work: a complete systemic view of general site architecture."

The original post I commented on: "Maybe because you write software used by sysadmins?"

Even after posting the original message, I really don't get your comment on it.

Either that, or getting a Ph.D. in Education.

If you think you've been a poor fit at some companies, you ain't seen nothing yet.

Education departments attract some of the very worst students, people pathologically stricken with know-nothingness. The graduate schools then take the more craven among them, the ones that realize that their school-system contracts give them huge automatic raises for getting higher degrees, often paid for too. They often come out as worse teachers after having had the recently recycled fad pedagogies pumped through them, which they then regurgitate in a game of telephone onto their students.

If you want to work on some stellar CS education stuff, try to talk your way into Kay's VPRI. Stay the hell away from Ed schools, they'd make your blood boil.

The rest is far, far worse.

Say what you like about the tenets of Constructivism, Zed, at least it's an ethos. I'm surprised that you'd have beef with it — you don't even like Papert's Constructionism?

As easily misinterpreted and misapplied as liberation pedagogy can be, at least it gives the non-subject-matter-experts something to apply themselves at, something they could actually help children with even if they're as dumb as a bag of rocks. It's definitely not a good fit for you, but it's far from worthless.

DI does have it's merits — it does keep bright assholes like us from dominating the classroom as students in a mixed setting. You can also get through the material a lot faster without getting mired in repetitive interactivity, but the script has to be perfect, or you can skip past a crucial facet without noticing, and there's very little opportunity to get back on the rails, especially because from the lecturer's perspective the resulting complaints are difficult to distinguish from the usual whining.

Part of the problem with curriculum design is that trials generally only occur with either uniformly high-achieving or uniformly delinquent students, both of whom can abide nearly any method if it's intentionally delivered.

Is this a Heinlein reference?

Operations guy: Mongrel2 is a ops wet dream. Totally automatable and you can use it to easily carve your infrastructure up as needed to scale and deal with all the random crap programmers throw at you.

Programmers: Mongrel2 is future proof and gives you want you need with low friction. Wanna do sockets? Got it. Use any language? Got it. Change up the request flow to work around a bug? Got it. Drop Scala for Rails? Got it.

Or something like that.

> "killer apps" are for mongrel2

You just said it. Bypassing any connection limitations on the browser.

I'm not even sure what that would produce. Maybe a post-post-modern _why.

I'm not that jazzed about the idea of reminiscing about a Smalltalk. How about instead of making esoteric references, you just say what's on your mind?

This is a thread, not a bibliography.

> This is a thread, not a bibliography.

What is that supposed to mean?

Sorry for the long rant here, but I would like to see a healthy atmosphere for developers producing quality AGPL projects and the community accepting that they need to pay up reasonable fees for non-AGPL use.

The interesting thing is, other people have had the same sentiment about the AGPL. It seems they actually prefer it plus some small commercial license option. I hadn't really thought people would like the AGPL for servers, but it seems that's what people are liking.

At this point I have no idea which direction it'll go, but I'll make a decision once it's more stable and actually runs stuff.