ntalbott

I hope it has a lasting impact beyond Spreedly, too. The impact of founding a company shouldn't just be on customers; if we act in an upright manner, hopefully employees, vendors, partners, the families of all of the above, and a cascade of future endeavors will be positively improved.

RE feedback, we try to give it and make it meaningful, so for instance the pre-defined, objective grading criteria we use for work samples lends itself well to us being able to highlight why someone isn't a good match.

There may be a slight possibility that giving clear feedback opens us up to some sort of liability, but (a) a respectful process ends up documenting itself really well as a side effect (how else are you going to keep up with all the details?), (b) a respectful process hopefully leaves even candidates who weren't a fit feeling like they got a fair shot and thus not inclined to come after us for a perceived slight, (c) I think the fear around giving feedback is more about how uncomfortable it makes us feel vs. an actual legal risk, and (d) I hate not getting feedback when I fail and as a founder and executive I have the clout to take some risk and do what's right.

Author here: you're right, nothing revolutionary here in technique. Most/all of our actual process is ripped straight out of http://sockpuppet.org/blog/2015/03/06/the-hiring-post/. But my experience, over the course of Spreedly interacting with 100+ candidates over the past few years, is that just doing pretty standard things well, with attention to detail, is in itself revolutionary. We hear story after story from candidates about other companies they have or are interviewing at that are completely disrespectful in how they're treating candidates. Whether this is cargo culting, lack of time to do things right, or a righteous belief that it's OK to treat candidates poorly, I can't say, but it's pretty disgraceful.

So, I wrote this little thing both since I needed to write it down for my coworkers anyhow - this is how we do things, showing respect for candidates by keeping reciprocity, incrementalism, and relevance in view - but also in the hopes that it's one more brick in a wall of "you're worthy of respect" for candidates.

The post itself wasn't about our actual process, though I did use examples from it; I hope to write about the actual process later. But I will note that my experience of phone screens is apparently very different from yours: I've experience them as a chance to pre-grill and filter candidates, and ours is 100% not that. I ask zero questions, but instead just talk about what we do and answer any and all questions candidates have. You're right that doing an intro call with each candidate isn't scaling, but we're not replacing me with HR, but instead have a live weekly intro call that candidates can join where I talk about the company and they can ask questions via text and I answer them on the spot.

And for what it's worth: "the current market dynamics" in tech hiring SUCK. So long as I have any say, we'll be playing moneyball by ignoring them and instead just continuing to iterate based on what actually works.

Love this: like 99designs for code. Bet you'll get a lot of pushback on this "devaluing coding" just like 99designs has for design, which just means you're on the right track. Of course it doesn't; it just commoditizes basic coding skills, and more importantly makes the accessible to a wider set of people.

I especially liked the example that was scraping data off a bunch of pages and returning a spreadsheet/csv of the results; that's a great example of something a smart business person that thinks algorithmically can identify, but can't/won't implement themselves. I actually wonder if it would work well to target this service specifically at algorithmically minded business folks.

Hope this works well for you - great idea, and looks well executed so far.

Spreedly already supports vaulting bank account information, and while the number of gateways that we support passing bank account info to is still limited, we're growing that rapidly at the moment.

Our gateway support is heavily influenced by customers, so anyone who has a gateway they'd like to pass bank account info to that we don't support today shouldn't hesitate to drop us a line.

Thanks! The name's "test/unit", but I won't hold it against you ;-). It's pretty sweet that people have gotten so much mileage out of code I wrote, and if it's helped us as a profession - even a little bit - to write better code, I'm thrilled.

You forgot to reference the great recursive essay Eric Meyer wrote on exactly this topic:

http://meyerweb.com/eric/comment/chech.html

Which essay I already knew about and chose to willfully ignore when I titled the OP. We could chat over beers sometime as to whether I'm a bad person for doing so :-)

I think a lot of it depends on context. In a private repo I'm right there with you. But when I look at a public repo with a lot of contributors, I want to know what the "logical" history is a lot more than I want to know about the three steps it took to get a feature ready for public consumption.

Well, quoting from that message, "If it's not ready, you send patches around". I think the big difference is that I'm willing to take patches that aren't ready and get them ready, whereas I'm sure Linus usually pushes back on the contributor to clean up their stuff. And I do think merges are super useful in a lot of cases, but Linus added `git am` too, and I like using all the tools at my disposal when they fit.

Most of the contributions I'm merging in are 10 lines, but a lot of them (half?) take two or more (sometimes many more) commits to converge on those 10 lines, and none of those intermediate commits has useful information in them. The other half of contributions are only a single commit already.

If someone contributes a true 1000+ line contribution that I'm even willing to take (yikes!) then you better believe I want that in multiple, logical commits, and it may even be me that ends up doing the splitting.

I'm sure a lot of it just has to do with what types of contributions a given OSS project receives, so YMMV.

Maybe, but... probably not. The thing is, I want to work with the changes locally before they get included. So it can't be a 100% web workflow. That said, there might be ways the web UI could make the transition to the CLI easier, and it would be great if Github promoted the `git am` flow on the PR pages as well.

These quality issues become a problem sooner than I would have thought, and Linux is big enough that they can just demand contributors know their stuff. But I found that in between "hobby project of my own" and "huge project where people beg me to contribute", there's a big space of "big enough that it gets contributions, but small enough that it's not worth turning contributors away for small quality issues". And I love that hub + `git am` lets me take those contributions but still maintain the workflow I want on the project.

FWIW hub is even handy for the "add a remote for the fork, check out the fork branch" flow, since it lets you just `git remote add ntalbott` instead of having to find or derive the full url for the remote.

You may think of commits as literal quotations of the "Author", but it's important to realize that git doesn't. If you want to know who's ultimately responsible for a commit, you always want to look at the "Committer" since that's who actually signed on the dotted line so to speak.

As I understand it `git am` is actually replaying the series of commits on top of the branch you run it in, whereas a merge commit flattens the commits out and applies them in one go (while keeping full history of the commits begin merged). So it's definitely a different strategy, and you can get conflicts where you wouldn't with a merge commit. As you said, though, they're super easy to fix when they happen. Often when I see a conflict like this it's because there are 52 (OK, exaggerating, a little) commits in the contribution and using the `git am` flow is a huge win since I'm now in a good spot to squash the down to one or two commits.

Cool, I'll have to try that! Does it also pull PR's that live on feature branches in forks of the root repo?

Using git remotes and distinct branches per contribution is totally legit, and I still do it sometimes. But, I'm often/usually dealing with contributions that have already been reviewed and don't need a whole feature branch/review within the root repository before inclusion. And for that setup - where it's almost ready - it's so much easier to just `git am` it into master, make necessary tweaks, and push.

In general I'd just encourage maintainers to try the `git am` flow, especially on small to medium complexity contributions where it looks mostly ready to go and you don't want to do another week of ping-pong with the contributor just to get a variable renamed or some whitespace fixed.

As I tell my kids, "Just try one bite of <food I find delicious>. If you don't like it, that's cool, then it's more for me!" :-)

Agreed, editing contributions does add a bit of extra work for contributors post-inclusion, especially if they've been using their own branch in production. That said, since this is a PR flow, the contributor will get an email from Github that their PR has been closed, and they can track directly from that PR to the closing commit.

While I've often wished that Github had a proper mailing list per repository that could be used to discuss changes, I have to say that one awesome thing about PR's is how nice they make reviewing a patch. The diff view is just awesome, so now that I have a `git am` style flow with them it would be hard for me to switch to just passing patches around on a mailing list. That said, a mailing list would still be a welcome adjunct to the PR flow if done right.

So to be clear, every commit in the ActiveMerchant history also points back at the initiating PR via the commit message including the PR number (which gets linked up). So there's no real loss of information in that sense

And I hear your RE adding another tool, as I'm very cautious about that myself. That said, `git am` is "git cannon", and all hub is really adding is the ability for it to slurp Github urls as well as Maildirs.

Neat, related trick: add ".patch" to the end of any PR url on Github and you'll see a formatted patch for the PR. All hub is really doing is slurping that and passing it to git as though it came from a mailing list.

OP author here...

The result is the same, but I've found the `git am` workflow to be much smoother vs. mucking around with remotes. Some of that could be due to the nature of the OSS project I work on - ActiveMerchant - since just in the last month we've had 30+ unique contributors, and most of them have contributed a single change.

My general recommendation is to make sure you try out the `git am` flow for a bit, but then just do what works best for you.

Having people know how to start contributing is not an issue I've had with my OSS projects; that could just be me though.

Keeping straight what stage the Issues in our private repos are in, though - that's a very real problem I deal with every day. I'd love to be able to surface our internal company flow in a simple way like this; it's very kanban-like, and doesn't require us to add another tool or try to keep things in sync since it sits right on top of Github Issues which we already use.

Based on the email at the bottom of the page, looks like this is from the http://rallydev.com folks? I hope they have plans for an internal/private version, because while I'm not sure I'd use this for my open source projects, I'd love to try it for our internal repos.

Good feedback; I think a couple of example backtraces would help to illuminate what's going on. Not sure if I'll edit this post, but I shall take it to heart for future ones. Thanks!

The API has actually been in active use for almost two years, which means it is both battle tested and also showing its age. JSON support is actively planned for v2.

I've been using this extension for awhile, and I can't duplicate your results - clicking on your username with the extension installed is taking me right to your profile page. What happens when you do it?

Today there isn't any integration between our classic Subscriptions product and Core (though we do have some customers using them side by side regardless). It's something we'd very much like to do, but it's not at the top of the list yet.

The data is absolutely transferrable today - we've had multiple customers leverage that transferability to switch (or augment) their gateway with just a configuration change.

Of course, it's not just about data portability; API consistency is a big deal as well. If PayPal (for instance) decides to lock down your account and not let you transact any longer, you don't just have to worry about getting your data out, you are also looking at another whole implementation cycle around a new API. Even if it's just a day of work (and usually it takes longer), that's a day you could've spent on your product instead of mucking around with gateway API's.

There are of course libraries that help make gateway API's more consistent, but as a committer on what is in my opinion one of the best - ActiveMerchant - they only get you so far. For instance, Core gives you transparent redirect on top of any gateway we support. That means lowered PCI compliance requirements and a great experience for your customers, and there isn't a library out there that can do that for you.

Agreed, except... we actually don't have a UI to show. The transparent redirect approach that Core takes means that we'd just be showing you our customers' payment pages, which while spiffy, don't really tell you anything about the integration. Which is kind of the point - our goal is to be invisible.

I started to get wrist pain when I was about twenty, and did some reading on it. One thing I saw recommended at the time was to make sure never to sleep with the wrist bent in (i.e. a "limp wrist" position), but always straight or bent back (as if signaling someone to stop). Over a period of a few weeks I trained myself to always sleep with my wrist bent back by adjusting it to that position whenever I was aware at night, and have slept that way since. I'm now in my mid-thirties, and have had no further trouble with wrist pain.

I certainly do other things to keep my wrists healthy, such as trying to maintain good posture while typing, sitting in a good seat, etc., so I can't attribute sleeping position with all of my continued good health. But I certainly won't go back to sleeping with my wrist bent in; it's an easy thing to maintain and it seems to help a lot.

This makes me chuckle - the funny thing is that we were actually the first "small business" subscription service - Chargify, Recurly, etc., all launched well after us. That said, it also meant we didn't have any point of reference when we initially set pricing. I think we actually did surprisingly well four (4!) years ago, given the lack of information we were working with.

Think businesses would bite? Month-to-month, no minimum, cancel any time is so much in vogue, it's hard to imagine there would be much traction around a multi-year contract, but maybe I'm wrong.