There are endless tools available, and quick internet dopamine feedback loops, but almost no wisdom.

Give it a few more years and more inflation, and the remaining 35% of millennials will get out there to find their first jobs, and then the impact will be even worse.

It absolutely boggles my mind that nothing else exists to fill this spot. Fly and others offer varying degrees of easier-than-AWS hosting, but nobody offers true PaaS like Heroku, IMHO.

The truth of the matter is that the people who will choose to partake already weren't thinking; otherwise they wouldn't have chosen. This is the same with every bubble or major revolutionary thing that ends up having negative effects in the long run. GLP-1 is another great example of one that is still on the upward arc.

Sheep will always be sheep, and, in my opinion, this is the reason for the changes in hiring and the large scale encouragement of folks that obviously are not smart enough for this career to suddenly join in over the past 10 years.

Django does not provide magic, but it's ORM is like pure sorcery compared to the garbage out there (SQLModel, etc.).

Django provides the necessary tools to build terrific software. However, it does not prescribe extra extraordinarily high-level architectural guidance, so it leaves that up to you. For example, if you are building an app that will have a main UI for users to login, a backend UI for managers to view reports, an API for consumption by outside developers, Django doesn't provide some kind of automatic recommended pattern for structuring your app to support all this. However, it provides the exact ingredients you need to do this on your own. In the example a gave, you would simply structure your directories to reflect the various UI / inputs modalities, and then point a path to each section (urls.py). If you want to host your API as a separate service, you just define a WSGI/ASGI app and pointed to a separate urls.py, then start that container using that WSGI/ASGI app, simple as that. Django does not have any kind of magical mono effect structure to it. It is just a collection of unbelievably useful and clean and simple API that you can use to compose software at least 5x more quickly then you can with e.g., FastAPI. I'm in the second team I've been in that is using FastAPI, and it is uncomfortably slow, you wouldn't even believe it. With FastAPI or other API/micro frameworks, I think the perception is that "it's just python" as if Django is something else, and so people start off app.py and they "see now I can start from this fresh canvas", and then they learn after spinning their wheels for two years that having a solid ORM is actually important, having migrations that are always correct and automatically generated is important, having an admin interface for viewing, creating, managing local/testing data while debugging things, etc. is important, having an ORM that lets you do aggregation and annotation so easily that you find yourself wanting to make reports just as an excuse to use these features, is important, having a template system that lets you generate dynamic pages without having to set up a full SPA for every little interface that you want to make allows you to make a quick prototype or even a permanent UI of some kind without having to involve a team of front end developers who will then begin to dictate your entire backend architecture through their litany of ever changing API endpoint requirements. Speaking of, the common pattern that I have noticed with SPA/API based develop is that the front end wants to be large and in charge, until it comes time to validate data inputs or have to do anything with data that requires looking at it holistically (for example, given a list of orders, if there are any orders that have items that are backordered, provide a warning at the top of the page… SPA developers completely crushed by this requirement, now the backend has to add additional information via the end point called "are there backorder items", etc.). So you end up with this hodgepodge of mess, instead of creating a prototype of your interface and then coming back and deciding which things need to be "reactive", and either shoehorning those things in or rewriting your UI because it's absolutely necessary.

This has become quite the rant, but as somebody who has worked on software for nearly 20 years and can hand write HTML, CSS, JavaScript, use Svelte / React, Python, Django, SQL, etc., I've learned a LOT and seen a lot and I can tell you absolute certainty that choosing Django for a new project is the absolute most effective choice you can make on your path to success.

https://tonsky.me/blog/disenchantment/

Why has this happened? Everything is too easy. You used to have to have pretty good intelligence to break into UI design and software development. Now, anyone can do it with 30 minutes of "e-learning", and, therefore, the average IQ of a UI designer/or software engineer has decreased, dramatically.

TBH I also think that Alpine and HTMX are just as dastardly and disgusting, maybe even worse. I don't know why nobody can figure out a good way to just put in reactive components where you need them. All of the frameworks support that, Svelte seems to be the one that is the least against that, but I still don't see anybody using it that way. Front end developers, which tend to have the least business logic experience, somehow captured the entire SDLC. This is why literally all software is just completely riddled with insufferable bugs, beyond anything anyone in the 90s could have imagined.

If somebody were to reproduce the Django ORM, with full native asynchronous support, it would change Python forever. I know there are people who come from SQLAlchemy and swear by it. As somebody who has used both I can tell you, at least when working with a small team on enterprise software, the ORM blows SQLAlchemy out of the water, in terms of being able to produce quality software, quickly.

For anyone new out there thinking about using FastAPI... don't. You'll find 1 million people on the Internet happy to tell you that it's terrific, and 90% of these people have not built real software. The performance gains are lost, by double when you attempt to build real real software with it. I've worked with it in three different apps, and in all three cases it was used because the front end team insisted that all we needed was REST. In all three cases I have seen page load times that are slower than the 90s, 3 to 10 seconds or more before everything is done on the page. It's actually unbelievable to me that that is the direction a lot of Python backend development has gone in, relegating all the important logic, and, in a lot of cases, security, to frontend niceties.

When you were doing good you were sure it was your fault, but when you were doing bad you were sure that it was not your fault.

Do you see how that sounds?

Cookie banners are just one tiny example that illustrates how death from 1000 cuts is a real thing. In the case of cookie banners, you could say it's death from 100 cuts, because, if you live in the EU, you spend probably one percent of your entire life clicking cookie banners. 7.2 minutes a day is all it takes to waste one percent of your productive life (assuming 12 hours of useful time per day). You might scoff at this, "I probably spend 10 seconds", but I spend probably a minute or more dealing with broken cookie banner garbage every day and I am an American. Just from American websites complying with GDPR nonsense, we have to waste some small portion of our lives here as well. Stupid laws written by stupider bureaucrats ruin everything for everyone. This is the description of an idiot by Dostoyevsky, somebody who does things that harm themselves and others.

So many of the basic features (e.g., automatic Python venv, Pyright running, etc.) have random bugs that pop up from time to time, making the basic editor unreliable.

My fear is, if they keep going in this direction (adding bloat without fixing basic functionality), they'll be a perfect fit for Microsoft acquisition, at which point I'll have to switch careers, because there isn't any other editor out there that I like.

I'm typing this on an iPhone SE 2022 (the last one with a home button). I'm done with iPhone as soon as I am no longer able to use this model. I don't like the new, oversized pieces of junk, and I also like the home button as opposed to the new Face ID/swipe up workflow.

For people that have good visual acuity, the smaller screen is ideal; it's such high resolution that you can fit a lot of things in a small area. For people that turn the font size up to 600, the bigger screen is obviously ideal, but nobody really wants to have to hold something that is bigger if they don't need it for the screen size. That's the market I fit in and Apple has abandoned at market, along with all common sense (re: liquid glass, the recent Apple/Google Gemini deal, etc.).

It feels clever to make comments like yours right now, but in two years when the order of control flow moves up two more steps and you are no longer needed at all, it'll be frustrating to look back and think "I wish I wouldn't have given money to them."

The situation is extremely frustrating, because I have to be careful not to insult anyone or create endless arguments, while trying to somehow salvage the project into something workable, or convince a team of junior/mid-level engineers to start over (the code is technically not salvageable, at all). Trying to convince people who don't know what they're doing that the same end result could be reproduced in 45 days and then the next 18 months of effort could be condensed into an additional 45 days is like trying to convince an octopus that there are satellites in orbit around the Earth.