767 karma · joined February 5, 2010
Contact:
https://angel.co/cyranix (AngelList)
http://cyranix.github.io (profile, currently outdated)
Location:
Seattle, WA
Currently:
CTO at Hazel Analytics (Seattle, wA)
Selected history:
Developer at Socrata (Seattle, WA)
Developer at Moveline (Las Vegas, NV)
Developer at MyEdu (Austin, TX)
Rice University (Houston, TX), B.A. in linguistics(N.B. — I may internally share the messages that I receive in order to refine our hiring process, but you won't be signed up for mailing lists or anything gross like that.)
I know, the "Here's an email to confirm that you hate our emails" message isn't anyone's favorite... but if it helps companies improve their unsubscription mechanisms, I can let it slide.
In my limited experience, rapid job changes at the outset of one's career aren't particularly damaging -- providing you can offer an honest and reasonable explanation. I left my longest job because I had to move in support of my wife's career. I left my shortest job because the technical lead was toxic and the work would have led to a dead-end career. I'm leaving my job today for a variety of reasons which I've discussed amicably yet honestly over a period of several months with my manager. In no case was a better salary or some other material gain the primary motivation behind my decision to leave.
There's something to be said for getting exposure to a variety of environments early on. Freelancing, consulting, part-time jobs, summer jobs, and co-op terms can help to maximize exposure without much risk of negative career implications. If you have good priorities -- e.g. eventually ending up in a fulfulling, long-term job with appropriate pay -- a few changes will likely do more good than harm. But if you routinely leave when the technical challenge stops being sexy or if you attempt to get a cushy job with nothing but shortcuts, you can find yourself in trouble.
Grammar... rage... rising...
> one can even, if one jeers loudly enough, send some
worn-out and useless phrase ... into the dustbin,
where it belongs.
Such a fitting sentence on which to end the essay, since "dustbin" is no longer part of the modern English lexicon, as far as I know. [alias]
df = diff --patience --ignore-space-at-eol -b -w --ignore-blank-lines alias refresh-bash="source ~/.bash_profile"I won't claim to know what he thinks exactly -- maybe he's the alum you refer to? -- but I wonder if Samuel Clay (Newsblur, YC S12) would agree with that sentiment, given that he has published https://github.com/samuelclay/NewsBlur for all to see. I haven't committed to my own startup idea yet, but my plan for it does involve open-sourcing the code while keeping a custom corpus and its associated NLP models private.
Awesome that they're not trying to force technology down everyone's throats, which might keep real people at arm's length... and especially impressive that they can scale this approach to 4000+ schools. Best wishes going forward!
(Can anyone speak to this aspect of working with Dagger?)
If not, please remember that different languages are just that -- different, not necessarily better or worse. Personal attitudes towards the differences between languages are totally normal. Bearing this in mind will help the conversation proceed in a more civil manner.
Absolutely! Being under the gun led me, at one point, to have a "longest string in array" method with a statement like
if (i[z].length < qq) { ... }It will help job seekers if you put REMOTE in the first line of the posting.
In case `coffeemug is still checking in here, I'd like to put in a request to update the documentation page on drivers. The listed Elixir driver has been broken for a few months; a working one can be found at azukiapp/elixir-rethinkdb. Overall the page could be organized a bit better: putting the languages in alphabetical order and not duplicating the list (which pushes contributor names below the fold) seem like straightforward improvements. Thanks for all the hard work -- hope to be sharing my project and showing off some RethinkDB swag before too long!
I agree with a lot of what you've said, but that bit struck me as unfair. It's natural for employees to be fired, and for those fired employees to reflect on the past in order to find jobs that make them happier -- what a depressing world it would be if that weren't the case! -- so I'm not sure I'd conclude that their personal growth necessarily implies a systemic problem in the company (especially at n=6). And it's entirely possible that someone might get fired from a different company and end up happier at the OP's company, no?
Ultimately the company will want most, if not all, of the listed skills covered. However, if you can convince decisionmakers that you can successfully start addressing a subset of their needs today, as `patio11 says, then the company may recalibrate their posting to find someone (or multiple someones) to cover the remaining duties or provide training to you (or to existing staff) to shore things up.
The lesson is not to take a job description at face value. Setting aside the fact that some postings are written by people who don't actually understand the role, companies will always try to hire the most talented people for the least amount of money, as they ought to. But if hiring that one mythical ultra-developer is "shooting for the moon", then hiring someone who can effectively make inroads into the company's growth areas is "landing among the stars".
The index is a staging area for your commits. When you use `git add`, changes in the working directory are staged (prepared) for the next commit. If you pass the `-a` flag to `git commit`, Git will stage all changes to files that it is already aware of. (Recall that new files are untracked and must be manually added to the index the first time they're committed; `-a` won't add those files because Git doesn't already know about them.)
Why have a staging area instead of just creating a commit directly from all the changes in the working directory? It's basically a sanity measure for organizing commits if you're ever anything less than a perfect developer. If you make a bunch of changes and later realize that there's more than one "unit of work" represented in those changes (however you choose to define those units), you can selectively add files to the index to create commits that make sense. You can even use the interactive mode of `git add` to selectively stage changed sections within a single file. If you care about the benefits of sensible commits -- bug hunting with bisection, ability to run `git revert` to undo a logical unit of work -- then the index is your friend.
A few random pages on the index that I pulled up:
[0] http://www.gitguys.com/topics/whats-the-deal-with-the-git-in...
[1] http://git-scm.com/book/en/Git-Tools-Interactive-Staging