

Vampires (Programmers) versus Werewolves (Sysadmins) - Anon84
http://www.codinghorror.com/blog/2010/08/vampires-programmers-versus-werewolves-sysadmins.html

======
shin_lao
tl;dr

A lot of noise to say "programmers and system administrators have a different
job and they need to learn their differences to work together".

~~~
jasonjei
The problem with this article implies a bureaucratic division of labor when
developers are often the sysadmins. Any upcoming startup can't afford to be
resistant to change--and things will break, but nobody will know more about
the software than the developer. This kind of thinking reminds me of the way
the enterprise software world is run, and they're not exactly renowned for
quality, either.

I've found that great scaling is the result of sending sysadmins to work along
side developers, and having developers work with production/testing to learn
about each's side struggle. It's not R&D vs Operations, they're on the same
team! If you're building a house, you might have architects and builders, and
while the architect draws the blueprints, the actual construction people are
just as important since they have an equally good understanding of the other
side, such as applying the materials in good form.

------
hcayless
The big takeaway here is that if it's really "versus", i.e. the programmers
and sysadmins are having a power struggle, you're screwed. If one side or the
other "wins" you're even more screwed.

If your programmers and syadmins are working at cross-purposes, then you have
a serious problem that needs to be corrected _immediately_.

------
nkassis
So considering I do both am I a Werepire ?

But seriously, on small teams, you can't avoid that you will have a few people
doing both for a while. We have a dedicated a sysadmin but we work with him a
lot considering he has to deploy our code and devs are terrible at helping out
sysadmins. I get in these arguments all the time with other devs about making
sure it's easy for the sysadmin to configure and deploy the app. When they
write code that depends on random libraries, they need to ensure that will be
deployable on production servers running Linux and not OSX etc..

I feel having experience with both is important for sys admins and devs to
understand each other.

~~~
mgrouchy
Chances are when you work on a very small team you probably don't have a
sysadmin at all. At the startup I work at, I do both and the more I work
without a sysadmin the more I appreciate the work they do!

When we do have a dedicated sysadmin, at the very least he will be very
appreciated by me, because I know he will be improving all the stuff I have
done out of sysadmin ignorance.

~~~
sophacles
I think it is extremely important to have at least one developer who has been
a sysadmin in the past. One of my closest colleagues started his career as a
sysadmin. At first I was a bit distrustful because he didn't have a lot of
"real experience" or "education". But as I got to know him, I realized his
sysadmin "spidey sense" was a godsend. He has a knack for knowing when things
that should just work will in fact fall over. He also has a lot of deep OS and
platform knowledge, so frequently when we would want to throw piles of code at
something, he would suggest and OS tweak or similar to get the same end
result.

So yeah, sysadmins on all development teams from the get-go are now a must in
my book.

~~~
mgrouchy
Yeah, I was never a sysadmin, but for 8 months in my university days, I worked
as a systems programmer for the CS Department at my university. I worked on
stuff that automated system deployments, backups, imaging, etc. Its actually
in the process of being open sourced now at <http://www.labnet.ca/> (Its
actually a pretty incredible system I recommend anyone who is interested in
this type of stuff to check it out).

Because of this I worked with some awesome sysadmins and unix/linux gurus so
even though they were a bit rusty, I had enough core systems admin skills to
have a good intuition about how to solve most of the problems I have normally.
When I run into roadblocks I know some awesome sysadmins that I can hit up to
get me over the hump.

------
boredguy8
First, I highly recommend "Deployment is just a part of dev/ops cooperation"
[http://www.kitchensoap.com/2009/12/12/devops-cooperation-
doe...](http://www.kitchensoap.com/2009/12/12/devops-cooperation-doesnt-just-
happen-with-deployment/)

Second, this isn't a question unique to the dev/ops relationship. What about
the dev v. project manager? If you have a good team of developers, why have a
PM? Having worked as a dev, a system engineer, and newly in the PM department,
everything I've done since being a 'code monkey' is motivated by a desire to
make the dev's jobs easier. Maybe that's because of my roots, but I think it
makes the most sense.

Where I work, we have a useful distinction between Sysadmins and System
Engineers. Broadly speaking, admins are the i-dotters and t-crossers and do
things with well-defined processes while engineers are responsible for
everything else. As an engineer, I wanted to make as much information about
the production environment available to the developers as possible. I also
worked to make sure the dev environment would mirror production as closely as
possible given that we only had one dev sandbox (requests for a staging
environment were declined). These two things, combined with being a good
teacher, meant I rarely had requests for CLI access to any of our
environments.

~~~
brazzy
_What about the dev v. project manager?_

Bah! Devs vs. DB admins, that's where the blood stains the rivers red, the
crows feast like kings, and legends are born!

~~~
jeebusroxors
And here I thought it was sysadmin v DB Admin.

I guess no one likes the poor DBA...

~~~
scrame
Right, nobody likes DBAs.

------
ww520
It's simple. Give developers access to production servers but not root
privilege. Deployment and configuration change should go through change
request ticket, whose main purpose is communication to the group and
maintaining a history of changes to the production site. Change tickets can be
as simple as sending an email to a group list or an elaborate system of
reviews and approvals using ticket tracking app.

Implementation of the change ticket can be done by developer, qa, sysadmins,
DBA, or ops, depending on the needs and required privileges. Routine stuffs
should be automated.

It usually takes a few times of site down and screwup before some form of
process to be put in place.

------
dedward
Developers should never have system level access. They should never be able to
meddle with the core infrastructure their code runs on.

This has nothing, however, to do with who should be able to publish new code
to the website (we're talking web apps here, right?) - that is something that
should be handled by documented process, and automated tools to ensure
accountability. Hypothetically, as the senior sysadmin, I'd _like_ to sign off
on every change that's going public, because I'll have to deal with the
fallout if something is wacky. Realistically, I'd also like our senior
developer, or failing that, even a more junior developer to be able to push
code to production in an emergency if the right people are there to approve it
(perhaps not hte proper technical staff, but they can get the okay from the
owner to go-ahead). Accountability, automation, and process are key here. The
deployment system should be accessible to some people who could potentially
get fired for using it wrong, and it should be very clear to them what the
right thing to do is. The deployment system could even warn them of this and
include official signoff, etc.

------
arethuza
I often think that most of the benefit you get for making changes to
production systems is from getting someone else involved when you make that
change - whether it's an incredibly formal process (which can be justified for
some systems) or "want to sanity check me making this change" it all comes
down to getting other people involved so they will say things like "You do
have a backout plan in case this screws things up, don't you?".

~~~
boredguy8
If the only thing your sysadmin is doing is 'looking over the shoulder' at
code they may not (probably don't?) even understand, you need better
sysadmins. You should be sanity checking with peers, whether that be other
devs for a code change or other sysadmins for an environment change.

------
CountHackulus
I find it interesting that he seems to disagree with his co-founder on what
seems like a key issue moving forward.

