tom_walters's comments

I think this primarily comes down to a fundamental misunderstanding of where the value in streaming services lies from the perspective of old world media giants. The majority of people who buy streaming, I suspect, are interested mainly in the conveyor belt of diverse and engaging content. Sure I whack an episode of Rick and Morty on via Netflix once a month, but 90% of viewing is of new serialized content.

Disney naively thought they could just serve up old classics while wringing the life out of Marvel and Star Wars IP and people would happily continue to pay. But the IP dilution and very real costs of beaming 4K video around the world on demand don’t mix well together.

Meanwhile Netflix has built some of the most sophisticated production tooling in the world, and leveraged cross-country content like no old-world provider ever has.

It’s a classic story of a tenant mistakenly believing the landlord has it easy - so they abandon their sublet and try to build a mall from scratch - the models are vastly different, and perhaps in this case, lethal.

Agreed. I’ve had to create dedicated SPAs for several projects recently which is a huge shame. I’d be interested to understand the architectural goals of the Django project moving ahead to see if they’re even interested in solving for this type of problem.

Thanks for the reply. Agreed on the templating side of things - it certainly makes building sophisticated UXs harder.

Great point around project structure and ability to move between codebases - I think the lack of enforced structure in Django absolutely helps increase codebase entropy over time.

Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?

I think any company exploring ways to improve the financial system should be given plenty of space to do so, but I think the fundamental issue facing Coinbase, and all other crypto-based firms is: when will we see mainstream adoption of crypto as something other than asset speculation?

Or, is speculation the only use-case for crypto? Sure we've had example use-cases for crypto as a value store and exchange medium, but outside the bleeding-edge of technology, and away from the VC fever dream (let alone con-artist central), where does crypto fit into society?

There are major incumbent forces all the way up to government that are keen to control the rise of this technology so it's clearly not an easy task, but for the likes of Coinbase to survive I think we need to see real value in using the things you actually trade on their exchange. Unfortunately right now it seems that Coinbase is a company predicated on the assumption that “crypto is going to become the main way to exchange value at some point in the future”.

Companies powered by hype and VC speculation invariably collapse as markets move on, so if I were investing in them I'd be really keen to have them allocate the majority of their resources at pushing crypto adoption into non-investment-based use-cases, which is to say, banks having large crypto teams is much less important than average people actively using crypto for goods and services (if that's to be the dominant use-case for crypto.)

Did AWS just pay them to write this? I was hoping for an interesting article exploring the complexities of a massively distributed and high-throughout system, but I just read “we connected these managed AWS services together and it’s cool”

Hopefully further instalments might actually talk about the problems they faced building this out, and their unique challenges.

"I used a free service and it wasn't great"

Then use another service or pay for it.

This is highly unlikely to be as simple as the author conjects, we're talking about a service that processes an enormous amount of traffic and if what the author suggests is true, would someone else not have noticed by now? It's certainly possible that different infrastructure is used by free/paid plans, and perhaps this specific site was hosted on an unhealthy instance. But we don't have any external data points here to analyse - only those reported by Cloudflare, along with anecdotal reports.

Edit: I see the title has now been changed, at least we're reducing clickbait.

I fundamentally disagree with the conclusions of this article.

It doesn't take long to "build software" - git was built in a weekend, Facebook a similar timeline. When the environment is right there's no upper bound on the pace of delivery, it's just that modern day dev is, in many places, less about quality of the output (in terms of product/market fit and user value, not code quality) and more about the satisfaction of ceremony. You couldn't product manage Google into existence, or any truly valuable piece of software, hardware, or any other innovation, but it's customary for organisations to create structures which feel grown-up in order to yield software.

The talents now required to enter the field are also different, which has naturally played a part in the perceived slow-down. Development is a new field, and research into what makes teams effective is limited - we're still using the ideas of industrial steel production to try and bolster the present manufacturing line. This means there are plenty of undesirable behaviours.

But ultimately, it's about what you're optimising for. If you hire outstanding people and give them an excellent brief, you can deliver incredible software at pace. Most modern companies don't optimise for this, it's more about satisfying sprawling teams, polishing egos, and chasing incremental gains. In that environment you can bet delivery is slow.

Fantastic work. The on-boarding is excellent and first use is very intuitive. You've done a great job of abstracting away the complexity of defining the data models so that I was able to build and deploy an example in just a few minutes.

It's a snappy admin UI and I love the auto-generating docs. All around excellent job!

Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc.

If your mindset is persistently "this framework/tool will solve all our problems" you're always going to have a bad time. Understanding the pros/cons of each element is essential to becoming a good developer.

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article.

React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool.

If you want speedy initial interaction times and manageable codebases, (and requirement X) use the right tools for the job, and instil better, thoughtful, development culture.