I'm very sorry if I've misquoted you or quoted you out of context. I'd certainly correct them instantly if contacted. I've searched my email and I don't see any corrections, so I'm not sure how I can make amends.
I pull a lot of quotes from a lot of sources. Many thousands a year. My goal is always to highlight ideas that I think might help readers do their job better. Highlight is they key word here. That you say those sort of things often is not surprising. My hope is always readers will be made curious enough to follow the link and learn more on their own.
And unfortunately there is no "they" at HighScalability.com. There's only me and there's only ever been me. So all mistakes are mine and only mine. There's never been much money or time to be as comprehensive as I'd like.
I do the best I can, but I often fall short, no doubt. I'm not a journalist. I never said I was. I'm a programmer. Have been all my life. I started this blog a long time ago. It was just stuff I found interesting. For whatever reason it got popular for awhile so I tried to make something out of it. That, like most of the industry is petering out now, so we'll see what the future holds.
The point about interviews is a good one and one I've wrestled with. Over the years I've conducted a lot of interviews. Much less so lately, and that's for a reason. I've learned that presentations at major conferences are usually the best resources. Presenters put a huge amount of effort into making those talks. And everything they say is open and approved for public consumption by definition.
Interviews with someone like me are often a bother, a time sync, so I don't usually get as much out of them. Interviews have a high overhead, taking a lot of time to setup and there's often a lot of red tape and legal wrangling that must go on to get access and content approval. Which is again, why, presentations are such awesome resources.
This article was derived mostly from people working on a project making a major presentation or from primary sources writing an article. I couldn't do better than that.
And regardless, I would still make mistakes. Believe me. It's surprisingly hard to make sense of an interview and turn something from thread mode into document mode. That process is an error prone one because I have to fill in the gaps and there are always gaps.
It's rare that I've ever just published an interview. I don't think they are that useful in general. I want people to read a highly condensed document they can get something concrete out of with minimal effort or just ignore easily if it's not relevant to them. The strange style I've developed reflects that goal. This article was of course different because it has a different audience.
So again, I apologize. But I guarantee my mistakes are never intentional, never for money, and never for lack of caring or effort.
One solution would be to email your draft to all authors whose content you used in your article and see if they require any amendments. Thanks for writing the article!
Also want to thank you for highscalability.com- I've been a fan for years. I understand you're not presenting yourself as a journalist- I've always just taken your website as a blog. You've helped me understand a lot of concepts about building bigger websites and engineering practices of so many websites I admire. I very often follow your sources to watch all the videos and read all the posts they link to. Thank you again and keep up the good work!
I think the condensed format is great, but the initial disclaimer makes it sound like it was assembled in a vacuum from open sources. For a post like this with a very specific focus it might make sense to reach out to a couple Netflix engineers for clarifications or just making sure there are no errors. I have worked on some playback systems for a few years and would not mind answering technical questions, I am sure others would do the same
> For whatever reason it got popular for awhile so I tried to make something out of it. That, like most of the industry is petering out now, so we'll see what the future holds.
I'm very sorry if I've misquoted you or quoted you out of context. I'd certainly correct them instantly if contacted. I've searched my email and I don't see any corrections, so I'm not sure how I can make amends.
I pull a lot of quotes from a lot of sources. Many thousands a year. My goal is always to highlight ideas that I think might help readers do their job better. Highlight is they key word here. That you say those sort of things often is not surprising. My hope is always readers will be made curious enough to follow the link and learn more on their own.
And unfortunately there is no "they" at HighScalability.com. There's only me and there's only ever been me. So all mistakes are mine and only mine. There's never been much money or time to be as comprehensive as I'd like.
I do the best I can, but I often fall short, no doubt. I'm not a journalist. I never said I was. I'm a programmer. Have been all my life. I started this blog a long time ago. It was just stuff I found interesting. For whatever reason it got popular for awhile so I tried to make something out of it. That, like most of the industry is petering out now, so we'll see what the future holds.
The point about interviews is a good one and one I've wrestled with. Over the years I've conducted a lot of interviews. Much less so lately, and that's for a reason. I've learned that presentations at major conferences are usually the best resources. Presenters put a huge amount of effort into making those talks. And everything they say is open and approved for public consumption by definition.
Interviews with someone like me are often a bother, a time sync, so I don't usually get as much out of them. Interviews have a high overhead, taking a lot of time to setup and there's often a lot of red tape and legal wrangling that must go on to get access and content approval. Which is again, why, presentations are such awesome resources.
This article was derived mostly from people working on a project making a major presentation or from primary sources writing an article. I couldn't do better than that.
And regardless, I would still make mistakes. Believe me. It's surprisingly hard to make sense of an interview and turn something from thread mode into document mode. That process is an error prone one because I have to fill in the gaps and there are always gaps.
It's rare that I've ever just published an interview. I don't think they are that useful in general. I want people to read a highly condensed document they can get something concrete out of with minimal effort or just ignore easily if it's not relevant to them. The strange style I've developed reflects that goal. This article was of course different because it has a different audience.
So again, I apologize. But I guarantee my mistakes are never intentional, never for money, and never for lack of caring or effort.