Your question was whether there are any physical activities where women can compete with men. You were given one example where women outperform men in a physical activity.
Here are more details of women who had less training than men managed to outperform those men in physical activity.
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.
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.
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:
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.
> 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?
Unfortunately, it's true in most field, it's extremely rare to find an ads that doesn't ask for a diploma and job experience (it didn't ask for experience, but I saw an ads where they asked for a diploma in a call center position...)
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?
I put this site together, glad it's useful for you. The graphs are my take on climatographs.
The data is from the National Oceanic and Atmospheric Administration National Climatic Data Center, see http://www.ncdc.noaa.gov/. The dataset has good coverage of the US, but as people have pointed out, there are gaps in many places, such as the UK. The comparison is based on the monthly average max and min temperatures.
If you create a file in your home directory that you give permission to anyone to read or write to, having a+x on your home directory will actually allow them to read/write the file if they know the full path to it.
This behavior is useful on subdirs, too; for example, a shell account I used in the past had http://server.example.com/~username/ mapped to /home/username/public_html, and since the webserver ran under a user that didn't have root permissions, making /home/username a+x allowed the webserver user to access the files that I wanted to share over the web (assuming I had public_html chmodded properly, of course).
So it's less about cd and more about direct file and/or directory access for purposes of widely-accessible files.
