Hacker News Reader

Comment by simonw | Hacker News Reader

The title here is a bit misleading: the first few paragraphs of this are a really enlightened description of the challenges of engineering for a startup regardless of what framework you are using.

Even if you have no interest in Django at all I recommend reading the start of this.

> I wrote this guide to explain how to write software in a way that maximizes the number of chances your startup has to succeed — by making it easy to maintain development velocity regardless of the inevitable-but-unknowable future changes to team size, developer competence and experience, product functionality, etc. The idea is that, given the inherent uncertainty, startups can massively increase their odds of success by putting some basic systems in place to help maximize the number of ideas, features, and hypotheses they can test; in other words, maximizing "lead bullets," to borrow the phrase from this blog post by Ben Horowitz.

View on HN

Thanks, Simon! I thought a lot about how to position this piece, in terms of whether it was really about Django, or about Python, or about software architecture more broadly, or software architecture specifically for startups, or whether it's really primarily a business book that just happens to contain code snippets.

In some ways it's all of these things. But I think for people who aren't already senior developers, it's much easier to understand the advice if it comes with some specific context and functioning code snippets. My hope is that by making it Creative Commons (including for commercial use), people will remix the book to make it work for their specific framework, startup, language, etc.

This way people can also incorporate the sections they like into their internal style guides, change them to say whatever they wish I'd said instead, make online courses based on the content, sell their derivative works, etc.

One of the main reasons it's about Python and Django (and not Flask, FastAPI, Express, etc.) is because Python and Django are both transparently run by non-profit foundations, and development is done in the open by large communities of contributors. This is a significant enough advantage that even if, say, FastAPI has some technical advantages over Django on any given day, over the long run it's hard to see any other stack becoming a better choice for startups until both the language and the framework are managed in a similar manner.

That makes a lot of sense, especially given your decision to use Django for code examples. I wonder if it would be worth extracting out those first few paragraphs into a separate article? They're really good, and applicable to way more than just Django.

It's not a bad idea. It would be cool to make a single serving page for this and give it some more structure, break out recommendations specific to different technologies, incorporate content written by others, get testimonials, etc. But it's also evergreen content, so if I wait a year or two to incorporate feedback then I think it will still be just as valuable.

I’m with simonw - I use Django so have gained from the whole piece. But that first part is bloody brilliant and applies to every tech I’ve ever used.

First off, excellent work. Second, thanks for your effort - it’s incredibly welcome and helpful.

Exactly. FastAPI's maintainer was so unprepared he had to stir up a storm to prevent a legitimate Python feature from coming in. One of the benefits of a larger and more involved community process is the fact that each person exerts less individual control.

Hmm, what's the context there? I'm not familiar with the FastAPI events you mention.

They threatened the Python language committee if they didn't get their way wrt PEP 576. Their library also contains C extensions with undefined behavior, and telemetry that phones home.

> Their library also contains C extensions with undefined behavior, and telemetry that phones home.

Source for this?

My bad, I was confused with another project. I can't edit it now.

This is a really classy reply. Nice job! We all muck things up but it takes a special person to admit to it. :)

Wow this is a really uncharitable interpretation of what happened.

I don't think your choice of language helps here.

The reference to PEP576 here relates to some changes to annotations/type hints originally planned for Python 3.10.

For anyone interested, here is a great summary from Linux Weekly News two weeks ago:

https://lwn.net/Articles/858576/

Yeah, going to need to see some evidence and source code references for allegations like this.

Nah... That's not what happened. Please read Sebastián Ramírez's post on the issue:

https://dev.to/tiangolo/the-future-of-fastapi-and-pydantic-i...

Have you thought of going on the Django Chat podcast to talk about your book? Seems like a candidate for a great episode!

https://podcasts.apple.com/us/podcast/django-chat/id14515364...

Not sure how to get on the guest list, but probably someone on HN can help…

I hadn't read the Lead Bullets article yet; it really is fantastic. For anyone else who hasn't read it, you can find it here:

https://a16z.com/2011/11/13/lead-bullets/

Reply on news.ycombinator.com