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.
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?
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.
I agree there's a range, but if you have to abandon an analogy to describe another end of the range, then it's time to find a new analogy. I think one trap in the article's logic is thinking that all structural engineering is at the scale of bay-spanning bridges or skyscrapers. Structural engineering can range from structures that withstand earthquakes down to a shack to stash your garden tools--just because one end of the continuum requires more rigor than the other doesn't make them unrelated.
In software engineering there are still rigorous requirements in fields that run software on other planets or in medical systems, but there's software with looser requirements as well.
The best metaphor I've encountered for the wide variety of software engineering was a talk that covered the book "How Buildings Learn" http://www.amazon.com/How-Buildings-Learn/dp/0140139966 -- there are structures that favor adaptability, and others that favor rigor, but that doesn't mean that structural engineering doesn't happen on one end of the continuum compared to the other.
(To be fair, there are rigorous forms of writing, too, but I think restricting the analogy to only novels is too narrow to be effective.)
San Francisco, CA; New York City, NY; Mumbai, India
At Flurry we're elbows-deep in the backstage of the smartphone industry, mixing metaphors like nobody's business.
Business is booming at Flurry, so we're hiring for a wide range of engineering positions: iOS and Android software, operations, backend software, analytics, and if you're looking for a data scientist opportunity, Flurry is looking for you!
Flurry needs engineers to help build our burgeoning mobile analytics platform--hiring for server-side software engineers, mobile client programming, operations engineers, a data scientist and more. Also looking for some non-engineering roles if that's your specialty.
More at http://www.flurry.com/jobs -- if you think Flurry is perfect for you but don't see an exact fit in any of the roles, don't hesitate to let us know how you could help us grow!