Chris Wanstrath, GitHub co-founder, writes about programming, Emacs, JavaScript style, Redis, and how GitHub hires.
HN links it for his TextMate-style Emacs mode and his post on hiring the person who wrote a well-known project.
I definitely agree that for a startup team, Github is making CS interview questions extinct. Even github itself claims so: http://ozmm.org/posts/who_we_hire.html - "at GitHub we hire "The Girl or Guy Who Wrote X," where X is an awesome project we all use or admire."
However, it is a different question if you are running a company like Google or Facebook. For instance, recently there was a news that Google received > 75,000 applicants and is looking to grow by more than 5000 employees this year. http://goo.gl/9fpkt
If you want to scale at this level, you won't have time to look at Github or similar sites for every candidate in detail. There will also be great candidates who have never published their code (although they might be the minority). To maintain hiring standards in this kind of situation efficiently, asking very difficult algorithmic questions might be the only way to go - at least you will be able to maintain the same hiring standards for 75,000 applicants.
> Random piece of feedback: it's weird to use data-model_id (instead of data-model-id)
I have thought about this one too in my own applications, and I seem to switch back and forth.
The good thing about using underscore is that the variable name can match on both sides of the expression:
var model_id = $foo.data('model_id');
vs
var model_id = $foo.data('model-id');
Mixing camelCase with dash seems a bit weird for me, because now there is a delimiter delimited, and case delimited convention: `data-modelId`.
I am trying to use camelCase for new code in other parts of the code though, as it seems to be the general convention in JS. [0]
[0] http://ozmm.org/posts/javascript_style.html
"But it's hard to make it pay off." Absolutely. Emacs is already out. Similarly, while Elisp has its flaws (the lack of a good namespace system comes to mind), it's probably good enough. Efforts to rewrite Emacs in Common Lisp or Scheme seem to stall out, even (and the thought of porting all that legacy code is rather off-putting).
I also think it's interesting how the author of the toplevel post has a textmate minor mode (http://ozmm.org/posts/textmate_minor_mode.html) to add TextMate features to Emacs that I'm pretty sure it already has (e.g. go to symbol, find file within vc repo). I know I've re-implemented minor features of outline mode more than once.
Git is distributed and there's no reason you should have to stop working, or committing, just because github is temporarily unavailable. At least for dependencies only on git. Losing access to wikis, pull requests, and issues may be a problem for some teams.
http://ozmm.org/posts/when_github_goes_down.html has a good summary of quick ways to keep using git without github.
My favorite aliases:
st = status -sb (more compact status. Can always use the full word "status" if I want the normal one, but I don't think I've done that once since I set the alias. Not original, I found it online somewhere)
dfc = diff --cached
dfw = diff --word-diff
msg = commit --allow-empty -m (http://ozmm.org/posts/git_msg.html)
He keeps calling him Jonathan all the time, but it's not at all sure that's his real name (see: http://ozmm.org/posts/his_name_is_robert_paulson.html).
And even if it is, it's kind of a dick thing to do, given that we know that _why never wanted to be known as anything but _why.