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.