ericedge

Then it's different than then?

The hardest thing to believe in NEW YORK 2140 is that the stats language R is still in active use 120 years in the future.

Women seem especially well-adapted to the trauma spaceflight inflicts, and have better caloric efficiency, at least according to this NASA study:

https://www.nasa.gov/content/men-women-spaceflight-adaptatio...

Monitorama hosted a great talk by Pete Cheslock about the Vasa warship project. Available on Vimeo here: http://vimeo.com/95284690

Given your description, I wonder if perhaps you're burning out due to over-committing to your work. Caring about the work one does is laudable, but if it's the only thing one cares about, it will never completely satisfy, and a passion-then-quit cycle like you describe seems to be a familiar result.

There are plenty of suggestions online for ways to avoid burnout, but it seems like it's even harder to diagnose than prevent, and usually involves a lot of soul searching. I unfortunately don't have any good recommendations for either diagnosis or prevention, but it might be worth considering as a possibility.

If you're not familiar with the patterns of burnout, I found this article to be a good introduction: http://nymag.com/news/features/24757/

I'm unclear on why this recommends setting up a user account for every committer. I'm a big fan of simply adding each committer's ssh key to a single "git" user account to avoid the overhead of managing multiple user accounts--you have to make sure each ssh key line is identified by the user submitting it in case it needs removal in the future, but it's much easier to manage adding and removing users.

There are some additional configuration steps for that single user, but most are covered in the manual at http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-...

Is there some advantage to separate user accounts that I'm missing?

To some extent I wonder if the difference between the two environments is the acceptance of more junior engineers into the ranks. Even the original link suggests that female coders need to have the same skills as the male coders in order to succeed in the field, whereas one of the main bullet points for Carnegie Mellon's success was specifically encouraging students with no prior experience to join the program:

http://blog.play-i.com/carnegie-mellon-study-on-gender-and-c...

But how often in web engineering do you see postings for junior employees? Everyone wants someone who already has experience, the more senior the better. How do we get more people of any diversity to work at our companies if there are no entry-level positions in the field?

I think some of this might arise from the fact that web engineering is still a relatively new field. People making staffing decisions feel like they're taking on enough risk as-is, and don't want to take on the additional burden of training up junior engineers.

But if we don't train them, gaining diversity will be much more difficult, and we may some day find ourselves with a quickly-dwindling pool of experienced engineers to draw from.

I'm not sure we're there yet, but when we reach that point, already having a solid training program in place at a company will be an incredible market advantage. So we might be shooting ourselves in the foot by not starting those training programs now.

Agreed that it's challenging to determine from an interview how someone will respond to a site outage, but site reliability engineering involves more than just being oncall--it's about the decisions you make in setting up interoperating services and the infrastructure you put in place to allow for straightforward scaling.

In general I'm a big fan of this sort of interviewing because the work the person did on the server can give you great insights into what sort of systems administrator they are--do they give you a good insight into how the system has been altered from the default install? Do they document the "why" of any changes they made? Were they able to craft a readable shell/python/ruby/whatever script to cover any automated processes they had to hack together?

I don't know what Google SRE technical interviews are like, but I can't imagine a one-on-one giving as many useful insights for an entire team as the artifacts left behind by someone setting up an entire server from scratch.

Not to mention the ability to weed out people who don't have the basics in place--when someone can't even figure out how to ssh to the server, you know pretty readily that they're probably not suited to the work.

I must confess I didn't expect the number of curt "the search is inadequate" responses; I posted this because it solved a particular problem I've been curious about for some time, and does a great job of displaying the data in a way that's useful to me. I found the graph display quite handy--using the same scaling on all pages allows me to easily compare different locations in different browser tabs, but the data is displayed simply enough that I'm not overwhelmed with sparklines like I am at other climate sites.

That said, I'd love to see more details about the underlying dataset; given the way the search works it appears to be a SQL database, so I assume it's public data from somewhere?