I used to think like that. But then, doing web development myself on the side I've realized no, they don't. Languages and frameworks these days pretty well abstract the underlying technology. Developers end up writing some pretty amazing stuff. It's up to the sysadmin to weigh in on what changes are necessary to make it work well enough to succeed. A seasoned developer will know more, because they've been through the wringer a few times. The new guys, not so much.
Remember, your developer spends their time making it work on a dev box, or even their own laptop. Performance testing and such is an art that if they had time to learn it... well I guess they'd be a sysadmin.
I am that new-guy web developer (or I was a year ago, anyway, I graduated college in 2010). I am the developer working on a dev box, and I do do performance testing. I knew it then, because it's important. Web frameworks do not meaningfully abstract the underlying workings of a web server; hell, the inability to do so is why C# 5 has the await keyword (to allow for better asynchronous IO) and why Servlet 3 has its own async stuff (not to mention Play Framework, which does all manner of shenanigans under-the-hood!).
If you actually give a shit about web development beyond a paycheck, this is stuff you just gotta know. If you don't understand the system, your assumptions and assertions are so much more likely to be untenable that it becomes dangerous.
The below questions wouldn't fly at my current employer due to a lot of legacy concerns, but my own list of interview questions would include a number of stack questions in addition to programming questions:
-Explain asynchronous I/O to me.
-How do you have to structure your code to leverage asynchronous I/O? (Alternately phrased: what happens if you write code that depends on synchronous I/O operations within an asynchronous I/O web framework?)
-You've got 9 memcached servers with a cache hit rate of 80% resulting in a database load of 80%. What happens if you naively add another memcached server to your cluster? (a question our VP of engineering actually does ask, and I stole it 'cause it's great)
You don't have to be a hardcore nginx source code diver to understand your stack. You just have to understand the principles behind it well enough to make good decisions. A sysadmin's job isn't to audit your code for your terrible understanding of the model on which your stack is predicated.
I think you may have taken my comment in a harsher context than intended.
First, I don't think it's good for a developer to have all the crap in their head that I do in mine. They'd be spending way more time pre-optmizing code than they would just getting stuff done.
A good developer will write a well thought out TDO that infrastructure and business units can provide feedback to.
Your questions about asynchronous i/o and memcached are great, and if memcached was a requirement for a sysadmin at a position it would be a good question to make sure they understand the software.
As a sysadmin though, you're also balancing
- Can the new system exist on an existing server/chroot/virtual machine
- What monitoring is necessary for the application afterwards
- Does the application meet all the standard requirements for database access
... out PFC is over 100 steps, this is just some of the bigger ones
- Can the sysadmin support the system after go live? The developers job is to create it, the sysadmins job is to keep it running long term.
Also, you are correct. The sysadmin shouldn't be auditing your code. The sysadmin should have a stack in place that they know works, and be able to help you do one of 2 things:
- Give advice on how your system can best fit in that stack
- Help you change the stack to best fit your application
Which direction you go on those two choices depends on the nature of the application, how mission critical is, required timelines for launch, budget and more.
Again--I am that developer, and I find that keeping "all that crap" in my head is extremely easy and makes me write better code. It wasn't straightforward to learn, but it made me better at doing my job. A question about memcached isn't a "sysadmin" question, it's a developer question to demonstrate that they understand what memcached (or whatever) does, its limitations, and its knock-on effects. These are things that I am entirely and without reservation convinced that a developer must know, and know intuitively, to be worth trusting with code. We have to write the code that uses these things--we'd better know how it works! That a sysadmin should know it as well is of course true--but a sysadmin should be a developer, too, to be able to make correct decisions in everything you've said above.
I don't say this stuff just for show--I've been there and done that, and it's stuff I've done to become what I consider an acceptable developer. I can, and have, set up a three-tier fully-enterprise-up-the-ass application infrastructure on my own (I have a couple machines on a VLAN at home as a VM farm) in order to learn this stuff. A developer who can't work the stack is a developer I don't want touching my code, because they're a developer that doesn't understand what they're doing actually does. Abstractions are great, but every abstraction leaks--they should be treated as productivity enhancers, not as insulation from knowing what you're doing.
Nobody can know everything about everything (there's a guy here at my current job who has forgotten more about the JVM than I've ever learned), but you gotta at least be able to talk about it. If a developer can't explain to me high-level concepts like how your web server handles threading, I don't even know what to say. This stuff is just so integral it's not even funny. You just gotta know it. Specialization is for insects.
.
EDIT: I think you and I are coming at this with very different philosophies. At my current employer, we don't have a PFC. We don't have TDOs. We have two live-site guys and a few operations engineers who are able to jump into our codebase (one is probably the most knowledgeable developers at the company who wanted a change). We have developers who can be trusted to make good decisions, and we have senior devs and managers who are very well equipped to analyze the plans and ideas that come from junior devs to say "hey, that won't work." But to be able to trust developers, they've got to understand how stuff works. (We don't ensure full-stack knowledge as well as I'd personally like, but we do a pretty good job of it--at the least, there are no "front-end engineers" who can't sling Java and no Java guys who can't write HTML/CSS/JS if a project comes along that requires it.)
Remember, your developer spends their time making it work on a dev box, or even their own laptop. Performance testing and such is an art that if they had time to learn it... well I guess they'd be a sysadmin.