I'm really not even sure a16z has corporate apartments. It's just poking a little fun in the middle of a dreary subject. I don't even own a single robe, much less twelve, although I'd be into it.
5,782 karma · joined November 14, 2009
http://twitter.com/holman + http://zachholman.com
As you might expect, it wasn't really the fault of feature flags but rather indicative of a process problem. We'd either have to prod the team or person in charge of it, verify that work was actively pushing things forward to ship, and so on.
At various times we'd have, for lack of a better phrase, the "No (wo)man", who would come in and say "no" to a lot of things. One of the best ways to achieve this is to see that nothing has happened on a feature flag for awhile and then send a pull request to remove the feature flag (and the feature entirely). This got people out of the woodwork who said waiiittttt a minute let me just finish that up, or if no one vehemently disagreed with the pull then you could actually just remove it entirely. But it did take some explicit reflection on whether the flags were defensible to remain flags.
As far as database migrations are concerned, GitHub (and others, of course) takes the perspective of migrating before the code that uses those migrations go out. In other words, as @herge says in a sibling comment, the code that gets pushed needs to support two branches of code and two branches of data simultaneously. It's certainly some extra work (and can be pretty gnarly depending on the scope of the migration), but once you get to a certain point it's kind of the only way to do no-downtime migrations.
There's many possibilities to help with the actual migration process, depending on what database you're using. With MySQL, for example, you can do something like the process in lhm: https://github.com/soundcloud/lhm
Zero-downtime deploys aren't super difficult in Rubyland anymore (many have written how they achieve it in Unicorn, for example), although I'm not as familiar with how other folk do it across other languages and platforms these days.
We need to get past this line of thinking. Why do companies not say the same thing for the salaries they've paid former employees? "Boy, I wish we could get back the $30,000 we paid Bob between July 2011 and October 2011."
We don't say that because the employee earned that and once they've earned it, it's out of your account and into theirs. Stock, though a different mechanism, needs to be thought of the same way. If someone has worked there long enough to vest that stock, they should have the option available to own that stock. Just because they made the company successful enough to not be able to afford to exercise their options in time doesn't mean we should take that possibility away from them.
Whether or not it was intended years ago when it became a norm, the 90 day exercise window, at this point, is a surrogate mechanism for companies to steal compensation from employees after the fact. That's horrible.
We always kind of hated the term "pull request". It's pretty confusing for a beginner, and for a number of years led to the idea that GitHub didn't have code review at all in the product. (For that reason, I always thought we should just call them "Code Reviews", or just "Reviews".) There were a number of attempts to change it, but they all died.
It wasn't until last year when I got a beer with an ex-Atlassian employee when we chatted about this and realized we both had hated the term and had a number of attempts to change the nomenclature, but they fizzled out. Funny how things work out.
I care pretty deeply about this, and I want to start pushing more startups in this direction. I think the tide started turning in the last six months or so and more companies are allowing for a >90 day exercise window on NSOs, but it's still a pretty small club. I've been keeping a list in a repo, since I think it's important to help promote companies that are doing this for their employees: https://github.com/holman/extended-exercise-windows
I really disagree with the general sentiment of this post, and very much agree with the original "Dear GitHub" letter. The product needs a lot of work, and that I couldn't address these problems while I was there really, deeply depresses me.
Issues hasn't been touched since I shipped the third large iteration a year and a half ago. It was never intended to be a finished product at that point; it was intended to evolve quite a bit from that initial vision. There's a lot of pain that open source developers and private source developers face today, and I really hope we all can start seeing that pain in our community eased soon.
Put another way: I've probably done a dozen or two product interviews this year, and have still never seen a full stack web request. I mean, I haven't seen a controller action, or a view, or even a model for that matter. And that's the area that's my entire job, really: I build screens and hook things together and make things work for users. As much as feasible, I'd like to be able to demonstrate those types of talents in the interview process.
I've been interviewed for a lot of these ostensibly "product" positions this year. A lot of it has to do with the company not even understanding what they're hiring for. Initial screeners would be all about product, product, product, but then they'd give me a new grad programming trivia test about rearranging chars in a string. Such a weird mismatch of aspirations vs. reality on the interviewer's part, and, most importantly, I've never come away from these interviews feeling the interviewer has a solid understanding of what I might bring to the table.
I'd push more for it before leaving the interview, but by that point the interview itself has soured me on the company overall.
I think this is exacerbated in the startup world in particular, because even "straight technological" roles in a sub-10 person team will inevitably include a ton of product decisions throughout the course of fast-paced development, and I worry too many startups focus on these type of algorithmic hiring tests being some sort of qualifier for these people when it's not.
Sounds a bit like a platitude, but there are so many different treatments and procedures modern dentists do that I think it the profession would generally be fine for quite some time. In a large sense, there'd probably be a transition towards more emphasis on repair and fixes of traumatic injury rather than preventative procedures, but it would likely take awhile before things dramatically change for the profession.
As we move more and more towards working in a distributed fashion, using tools that don't require us to even meet someone in person for months at a time, it's a little strange that there's so much emphasis placed on in-person interviews (which is inherently a fairly stressful process). How someone communicates in person is fine, but that's sometimes only part of the picture.
On top of that, some people are much more comfortable communicating over the internet, and weighing in-person interviews so heavily ends up discounting their real talents. Ideally you find people have skills with both asynchronous and synchronous communication... but you need to be keeping an eye out for both qualities for that.
Like I said, not something I have strong feelings about either way, but thought it was interesting that it did change my usage habits.
The fact that a lot of non-technical employees in marketing and other fields are using it for corporate blogs is actually a nice bit of pressure on the organization to make Pages and web editing even simpler for those users. It becomes harder to lean on "oh it's a developer site so they'll figure it out".
Mostly, though, I think it's just a matter that we wanted it for ourselves. It's pretty awesome from an industry bystander's perspective to have something free, simple, and static, so we can all benefit from more stable docs, blogs, and so on. Maybe that'll change in the future and something Totally Different will change the industry, but for right now I think it's pretty rad, and totally worth the investment.
I don't mind sites like the one here coming along and attempting to do this (it has some value), but I'm really proud that GitHub didn't head in this direction, even though there was a fair amount of pressure towards it.
Whoa, didn't expect that at all. Super interesting. Do you have a source for that?
> Buzz Lightyear walks into a bar called the "Uncanny Valley" and asks the bartender for a vodka soda. The bartender gives him a vasectomy. Voice recognition is important!
You did good by refusing to read the rest of the post and informing everyone of that fact on Hacker News. Cheers!
What's more, we found that if there was a file that had a ton of complicated, interwoven logic between the two versions of Rails, it was a clear sign we should see if we could instead backport a Rails 3 or 4 component so that we could nix the entire Rails 2.x-style functionality.
https://github.com/github https://github.com/libgit2 https://github.com/boxen
When it's easy to extract, well-documented, and has a clear team of maintainers, we try to open source. Sometimes it's difficult to nail one or all of those bullet points, though.