On the company: We've built a real-time content measurement layer for the entire web.
Our analytics platform helps digital storytellers at some of the web's best sites, such as Arstechnica, New Yorker, Mashable, The Next Web, and many more. In total, our analytics backend system needs to handle over 50 billion monthly events from over 475 million monthly unique visitors.
Our distributed team is best-in-class and we happily skip commutes by working out of our ergonomic home offices. Here's a photograph of mine running two full-screen Parse.ly dashboards on my monitors: https://flic.kr/p/v1NZ73
To see an example of how we work, check out the blog post, "Whatever It Takes": http://blog.parsely.com/post/46
Apply now by sending a CV/website, github link (if available), and 1 paragraph intro to firstname.lastname@example.org. Let us know what part of the position interests you, or point us toward an interesting project or piece of code you wrote. Also, mention the HN Who's Hiring thread.
p.s. we are also looking for folks interested in intersection of product and marketing, such as hybrid product designer/developers.
I run a 20-person fully distributed product / engineering team at Parse.ly, and this post is a great summary of why we do it. It's not about hating on offices, it's about loving on quality of life.
Work-life balance and harmony is enabled by remote work. I don't have kids, but many of my colleagues do, and they really appreciate the flexibility.
I don't think all roles can work perfectly remotely, but software engineering certainly can. Github (any day but today :)), Trello, Flowdock/Slack/IRC, AWS, GHangout, GDocs -- these are the tools you would use anyway in a good company. And you can trade the money spent on offices for plane tickets to do team retreats and hackathons from time to time.
It's a fair point, but the style guide is meant to be illustrative.
The former example is indented the way longer lines might very well be e.g. if your filter clause were a 2-part bool, you might not be able to fit it in a one-liner. The indentation also clarifies the difference between it and the imperative example above it.
The latter example is a rewrite of code written with 2 nested if statements, so the indentation serves to show that now the two nested statements were incorporated into the bool evaluation. If I made it a one-liner, someone might make the argument that the nested version is "more readable", but as written all you can say is that the single-if version is "less nested", which is the point I was trying to get across.
I'm "this guy" who "got a bunch of things wrong" :)
Style guides are opinionated, and not everyone will agree. I intentionally made the style guide part of a Github repository so I could consider feedback from the community, and I've already incoporated plenty. As I mention below in the thread, I think you have a good point about "args" vs "cards" for your shuffle example.
Re: "The preferred place to break around a binary operator is after the operator, not before it", I think you mis-read this PEP8 suggestion. A binary operator is something like "and" or "+", not the "for" keyword inside a listcomp.
Re: your other disagreements, they amount to style choices of their own. When a style guide picks between two ways of doing things, there will inevitably be detractors, and I am OK with that.
I'd gladly accept a PR on the issue raised re: "args" vs "cards" for the shuffle function. When I wrote the guideline on using the names "args" and "kwargs", I was thinking more about cases where you have to proxy both, e.g.
def __init__(self, *args, **kwargs):
# some logic
super(SomeClass, self).__init__(*args, **kwargs)
I was once asked to help a friend debug his server. Its mysql state was not loading properly, so I wrote an rsync line to back up all the mysql data as a safety step before debugging. A few seconds later, I realized I put a forward slash and a space in the wrong place and had managed to delete the entire directory.
I felt like such an idiot. At least I haven't messed up an rsync command since!