I wrote this article, and appreciate your framing here. A few things contributed to this effect that I think are a bit clearer with hindsight. Central to this was a lack of clarity between designers and engineers about what the state of things actually was. Designers assumed that engineers had been doing some of this work in building shared components, while engineers trusted that designers were aligning with each other. A lot of that happened organically when we were smaller but as we grew faster, those assumptions start to break. Eventually, we were far along before recognizing how much some of our patterns had diverged.
We had a pretty good idea what needed to happen to fix it, but there was a ton of work happening to maintain our same quality at scale across all of our feature teams. When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.
In the end, it's difficult to get people to agree to one thing, much more so when you're adding more and more people to the mix. We're in a much better place now. More than just having an interface library, we've created a framework for debating the various parts of the system and reinforcing that understanding that was missing early on.
Hey, thanks for your response! Great article and you guys are definitely in a good place now (yay Dark mode!) Your iterative approach to course-correction was absolutely the way to go so hats off for a job well done.
>When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.
Been there, done that, got the T-Shirt. Routing in Angular, API design and versioning, CMS integration, and more. I get it.
>In the end, it's difficult to get people to agree to one thing, much more so when you're adding more and more people to the mix.
There are probably a dozen relevant Dilberts on design-by-committee which are probably amplified by the egos and inexperience of dozens of 2x-year olds working at $hottest_unicorn. I strongly suspect that you are a very kind, patient, and understanding man.
>We're in a much better place now. More than just having an interface library, we've created a framework for debating the various parts of the system and reinforcing that understanding that was missing early on.
Congratulations, again. My sincerest apologies for focusing on the 'start line' when your article was about the race. Hindsight is absolutely 20/20 so hats off for a job well done and thanks for the follow-up.
Genuine question – who DDoSes Github? From what I've seen, DDoS attacks often seem to be a response to a site or company entering the political sphere in a controversial way.
In previous threads about Github being DDoS'd, I asked the same question.
Apparently it's some scheme to ask ransom from companies/startups that have enough money to pay and/or not enough infrastructure to sustain the attack without giving up.
Yep. There's a well-written article about an early DDoS extortion attempt where the victim fought instead of paying, developing some novel protection technology in the proces: http://www.csoonline.com/article/print/220336
Yea, all of us successful web companies face these all the time. We get them multiple times a day. Most of us end up giving up and pay for Arbor gear and ridiculously over provisioned pipes as well as good relations with our hosting facilities.
From their post, they're complaining about Facebook disabling their fan page without explanation while littering the same item with unattributed images.
I've had work in the past posted to their site without attribution and it was a headache to get them to either attribute it or remove it (they chose the latter).
It seems rather obvious why their Facebook account was disabled.
I'm going to have to back you up here. I've had my own work published to their site without attribution - although it was a long long time ago - and odds are, it's this same process that got them on hot water again. I'm empathetic, but I'm certain they're playing a little dumb as to what's going on here.
While that's likely the case, at the end of the day if FB is trying to be an advertising platform, they can't do it without competent customer service to ensure they're not cannibalizing their own intent.
We had a pretty good idea what needed to happen to fix it, but there was a ton of work happening to maintain our same quality at scale across all of our feature teams. When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.
In the end, it's difficult to get people to agree to one thing, much more so when you're adding more and more people to the mix. We're in a much better place now. More than just having an interface library, we've created a framework for debating the various parts of the system and reinforcing that understanding that was missing early on.