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.
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.
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.
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.
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.