DEV Community: Will Vincent

Careless People by Sarah Wynn-Williams - Book Review

Will Vincent — Thu, 05 Jun 2025 14:10:00 +0000

Careless People is a new memoir by Sarah Wynn-Williams, a former New Zealand diplomat who joined the company in 2011 and rose to become its global public policy director. She pitched herself to the still-nacent Washington D.C. office for over a year before finally securing a job. As she says in the book:

"I know what I want this job to be. It's clear that in these next few years, Facebook and governments all over the world are going to be figuring out the rules of the road for these giant, globe-spanning internet companies. What they set in place will determine how social media is used for decades to come. It will affect elections, privacy, free speech, taxes, and so much else. I want to be part of that."

As she quickly learns, Facebook--meaning Mark Zuckerberg--has no interest in policy or politics. In fact, it's a source of pride for him to focus only on engineering. Facebook's COO, on the other hand, Sheryl Sandberg, handles these things along with running the business and everything else. It feels odd to read these passages now, in 2025, where Facebook routinely influences elections and politics, to see that for quite a long time Facebook was aggressively indifferent to being involved in anything beyond tech.

Sarah notes that at one point, someone on Facebook's small policy team asks how the company is meant to change the world.

"They're shocked when the answer is...nothing really. For Mark and Sheryl, it's obvious. We run a website that connects people. That's what we believe in. We want more. We want it to be profitable and to grow. What else is there to say?

There is no grand ideology here. No theory about what Facebook should be in the world. The company is just responding to stuff as it happens. We're managers, not world-builders."

This indifference and narrow focus on growth at all costs more or less defines the company. And for Sarah, coming from the world of the U.N. and global law, it is quite shocking.

Nonetheless, Sarah finds her niche, introducing global leaders to the Facebook team. Initially they have no interest in meeting Mark Zuckerberg, but in only a few short years most of them are currying his favor, looking for local investment and help being reelected. Unsurprisingly, Sarah relates that Facebook can and routinely does weight its algorithm to benefit certain people, most noteably any posts by Mark or Sheryl, but also world leaders as needed.

For her part, Sarah is often flying around the world in the early days trying to open up countries to Facebook. This includes often dangerous situations, especially for a young woman. Trips to Mynamar to try to get the junta to allow Facebook. To central America. And so on. There is even a chapter titled "The Body" around efforts to visit South Korea, which had open arrest warrants for Facebook officials. Leadership wants to send a body in before the leadership team, to see how serious the country is about this. Sarah is told to go but finds a way out. Ulimately, it is one of the few other women on her team who goes. Not any of the men.

And so on. Sarah acts generally as a consigliere to Mark or Sheryl at global gatherings. Arranging meetings with world leaders. Finding ways for informal one-on-ones. As such, she spends a lot of close time with both of them. Suffice it to say, neither comes across well.

At one point, returning from a global trip, Sheryl invites Sarah, who is several months pregnant, to get some sleep and share the only bed on the plane with her. Sarah awkwardly declines and is seemingly frozen out thereafter.

There is also the cruel irony that the company aggressively promoting Sheryl Sandberg's book, Lean In, is, wait for it, not that kind to its female employees. This isn't unique to Facebook, though the company seems particularly cruel in how it treats people. During the birth of her second child, Sarah loses an enormous amount of blood and even goes into a comma for a period time.

"I return to work in August 2016. My first day back, Joel decides to do a performance reviews, as he says "it's performance review season." A quick Google search confirms my suspicions that you are not supposed to be given a performance review of your maternity leave. In fact, I understand that pushing someone to work during their maternity leave is against the law. Nevertheless.

"You weren't responsive enough," he says.

"In my defense, I was in a coma for some of it."

"It's not just me, Sarah. Some of your other colleauges found it challenging to engage with you."

And so on.

What are the takeaways from this book? It is a memoir so it's important to consider this is a first-person account, but it's a useful book for anyone new in their career to read as it provides insight into how leadership often thinks about things. Not all companies operate this way, but many do. Especially towards women.

What resonates for me is the author's feeling of being trapped, aware that unethical things were being asked of her, done around her, but feeling like she couldn't stop them. Part of this was financial, as she was the chief breadwinner in her household and had children. Part of it was legal since her immigration status and that of her husband depended upon being employed. But one way or another, she felt like a frog in boiling water at the company, her idealism slowly but surely chipped away.

In the end, after six years, Sarah is fired. As she notes, "It's less of a savage attack on my career and more of a quick euthanasia...My laptop is confiscated. I'm not allowed back to my desk to retrieve the personal items that had built up over the years at the company...I ask to say goodbye to my team and beloved assistant and I'm told no. Instead, I'm walked out of the building by a security guard."

AI Thoughts in 2025

Will Vincent — Mon, 26 May 2025 13:35:00 +0000

Artificial Intelligence (AI) is a broad term describing the overall goal of creating machines that can perform tasks that typically require human intelligence. The term was first coined in 1955 by John McCarthy, a Dartmouth College computer scientist. Today, our everyday lives are drenched in AI, from large language models like ChatGPT to visual recognition features on phones and cameras, recommendation systems on Netflix and Spotify, Google Search, credit card fraud, self-driving cars, and more. It is literally everywhere.

Within the larger bucket of AI are several major areas, including:

Machine Learning: Systems that learn patterns from data on their own rather than being explicitly programmed
Natural Language Processing: Programs that can understand, interpret, and generate human text and speech
Computer Vision: Allows machines to interpret and understand visual information from images and videos
Robotics: Combining AI with physical systems to create machines that can act in the real world

Until recently, AI relied heavily on expert systems and rule-based programming, where humans had to manually program the computers and provide guidance on how to make decisions. But in recent years, Machine Learning (ML) has taken over as the dominant AI technique because it can handle complex, unstructured data found in the real world, whether that is all the text on the internet, images, videos, or any other type of data. The more data you feed ML systems, the better they typically perform. This fact, combined with advances in processing power through more efficient computer chips and companies able to spend billions of dollars on data centers, means most major AI breakthroughs in the last decade--from AlphaGo beating the best Go player in the world, ChatGPT mimicking human conversations in a chatbot, and newer image and video generators--rely heavily on ML techniques.

Risks and Rewards

But in addition to clear potential benefits, machine learning comes with a significant number of risks that are becoming increasingly apparent as these systems are more widely deployed:

Data and Bias Issues: If the dataset given to an ML system is inherently biased, the resulting ML model will be biased, too. For example, many training sets for dermatology focus exclusively on white patients, meaning the model is trained to work well for them but not for patients with darker skin. Or suppose you train an ML model on historical data that contains discrimination. In that case, the model will perpetuate that, such as hiring systems that favor certain demographics, facial recognition systems that work poorly for people with dark skin, and so on. As ML models become more and more pervasive and start to replace humans, how accurate they are becomes important. The 2016 book, Weapons of Math Destruction goes in-depth on the societal impacts of algorithms, especially as many are used to perpetuate and even exacerbate preexisting inequality.
Black Box Problem: In many ML systems, especially the deep neural networks used to power LLMs like ChatGPT, the creators can't explain how the model reached specific decisions. Programmers provide an ML model with massive amounts of data, train it with enormous amounts of computer processing, and then evaluate if the end result seems to be accurate. But on the inside is a literal "black box." ML engineers can't recreate the ML models' thought process to understand why a certain decision was made. As these systems become ever more incorporated into daily life--and especially in critical areas such as medicine, science, policing, and finance--the risks of using programs we don't fully understand continue to grow.
Privacy and Surveillance: ML enables governments and private businesses unprecedented surveillance options via facial recognition, behavior analysis, and data mining. Governments can monitor and control populations on a level never before deemed possible, while companies can engage in "algorithmic wage discrimination," such as nursing gig apps that offer different rates to a nurse based on their credit history. The lower a nurse's credit history--and, by extension, the more desperate they are for money--the lower the rate the app will offer. The hospital and the app pocket the difference in exploiting a person's financial situation. There are similar examples across a growing number of professions.
Job Loss: As ML displaces more tasks, it threatens to displace workers faster than new jobs are created, leading to significant economic and political unrest and most likely exacerbating already record levels of inequality.
Education: ML models, especially LLMs, are already running rampant in education, where both students and teachers use them. Students use LLMs to write papers, and overworked teachers rely on them to grade large amounts of student work. There is a real risk that as people become more and more dependent on ML systems, they lose critical thinking skills, domain expertise, and the ability to step in should these ML systems start to fail in any way.

It is not hyperbole to state that the current AI explosion is analogous to the Industrial Revolution in the late 19th century: back then, physical labor was mechanized, while today, ML is mental labor and the current knowledge economy. The Industrial Revolution didn't just change how things were made; it completely restructured the economy and politics, creating new classes or workers and concentrating power ever more in the hands of a wealthy elite.

Both revolutions started with specific applications and then quickly cascaded across society. Steam power began in mining before transforming transportation, manufacturing, and agriculture. ML started in tech companies but is now actively reshaping healthcare, finance, transportation, and even creative industries.

The Future

Machine Learning is on track to radically remake human society. Back in 1930, the English economist John Maynard Keynes wrote a famous essay, Economic Possibilities for our Grandchildren, where he ruminated on the potential changes of future technological progress and economic growth over the next 100 years. He estimated that living standards would increase by 4-8 times, and people would only need to work about 15 hours per week to maintain a comfortable lifestyle. Keynes' main concern was what people would do with all this leisure time once their basic economic needs were met. He worried that humanity might face an existential crisis when work was no longer necessary for survival.

From 1930 to 2020, in developed countries like the U.K. and the United States, real GDP per capita actually increased 6-7 times, so Keynes was remarkably accurate in his estimate. But he was wrong in his predictions about everyday life. Most people today are forced to work ever longer hours just to get by. Most of the economic gains over the last one hundred years--powered by increases in technology and productivity--have been concentrated in the hands of a few capital-owning elites rather than evenly distributed amongst the general population.

The question now is what comes next? Will modern political systems adapt quickly enough to manage this transformation? If not, as seems likely, we will find ourselves living through a period of profound social upheaval where unprecedented job losses overlap with ever-more-powerful AI systems that operate beyond democratic control, shaping society according to the narrow wishes and whims of those who build and own them.

PyCon US 2025 Recap

Will Vincent — Wed, 21 May 2025 16:59:00 +0000

I just attended PyCon US this year in Pittsburgh as part of the PyCharm crew. We had a booth in the Sponsors Hall, where I met many attendees. I was able to attend a few open spaces and squeeze in some sightseeing. This was my first time attending in person since 2019, so seeing what has changed over the last six years was interesting.

Preparation

The two chairs of PyCon US, Elaine Wong and Jon Banafato, were guests on the Django Chat podcast last month, so for anyone interested in a very in-depth look at the conference and what goes on behind the scenes, I recommend you take a listen!

It also selfishly gave me a good sense of what to expect. PyCon US is a very big event, with somewhere around three thousand attendees, many talks, open spaces, and more. It can be a bit overwhelming the first time.

Thursday, May 15th

I flew in from Boston on an early flight and was surprised to see an enormous T-Rex skeleton at the airport!

T-Rex Sculpture in the Pittsburgh Airport

There was an evening reception from 5 to 7 p.m., and before that, I needed to help set up the PyCharm booth. Since my flight was very early, I had most of the morning to explore the city.

The first item on my list was the Duquesne Incline. Pittsburgh is very hilly and sits at the confluence of two major rivers, the Allegheny and Monongahela. These rivers form the Ohio River, which then snakes its way to the Mississippi River. This means that historically, if you controlled Pittsburgh, you controlled the interior of the United States, and as a result, Pittsburgh was very prominent in early wars between the French, British, and U.S. in the late 18th century.

Duquesne Incline

Look at the different colors of the two rivers! The Allegheny originates in the northeast, in relatively cleaner, forested regions of Pennsylvania and New York, so its water is often clearer and bluer/greener. The Monongahela comes from the south and tends to carry more sediment and pollutants, giving it a brownish or murkier appearance.

Allegheny and Monongahela rivers joining to form the Ohio River

The conference was held in the very large David L. Lawrence Convention Center. I picked up my badge from registration and added some additional Django flair.

PyCon Badge

There was a lot of traffic on the opening night as there were drinks and appetizers on the floor and, most importantly, no competing keynotes or other events!

Friday, May 16th

I was on booth duty from 7:30 a.m. the following morning until 6:00 p.m. It was a very full day of doing demos and chatting with people. We also hosted a mid-morning book signing with Matt Harrison and an afternoon one with Naomi Cedar.

PyCharm Booth

Sponsors Floor

The primary topic of conversation for us was Junie, the new coding agent that is part of PyCharm. Attendees were pretty evenly split between those who were well versed in agents and had detailed questions about ours vs. the competition, people who I'd label as "AI-curious" who hadn't used them, and a third group that couldn't use AI at work for privacy or security reasons but was trying them out for their personal usage.

In the evening, I was planning to have a quiet night, but I got a last-minute invite from Eric Matthes (pictured later on this post) to attend the Pittsburgh Symphony for a performance including Beethoven, Stravinsky, and Prokofiev.

Pittsburgh Symphony Hall

It was a fantastic performance, but it resulted in a very late night for me. So it goes.

Saturday, May 17th

The next morning, I was on booth duty for most of the day. At 10:00am there was a book signing with Eric Matthes, author of the very popular Python Crash Course. One of the attendees was Jib Adegunloye, the lead engineer at MongoDB on their new Django backend. I had the pleasure of interviewing him on the Django Chat podcast back in February.

Eric Matthes & Jib Adegunloye

At 11:00 a.m., I briefly escaped the booth to support my colleague Paul Everitt, who led an open space on PEP 750—Template Strings, which was just accepted for Python 3.14. Open spaces are a big deal at PyCon US and one of my favorite features. These are informal meetups on a wide variety of topics that you can just show up for.

Paul is a co-author of PEP 750, which introduces t-strings, an enhanced version of f-strings. While f-strings evaluate to str (a string), t-strings evaluate to a new type, Template, which provides a host of additional features. See this article by Dave Peck, one of PEP-750s authors, for more information on t-strings.

Also in attendance were two co-authors on the PEP, Dave Peck and Koudai Aono, as well as David Lord, lead maintainer of Flask and Jinja (which t-strings might impact), and many other heavy hitters. Only at PyCons do you literally have almost all the decision makers for a major new Python feature sit in person in the same room.

After the meeting, I raced back to the PyCharm booth to help Calvin Hendryx-Parker, CTO at Six Feet Up, who presented a lunchtime talk on Battle of the Bots: Which AI Assistant Delivers?, covering Aider, Claude Code, Cursor, Goose, and Junie.

Calvin Hendryx-Parker Talk

And then, at 3:45pm, there was a book signing by me, of all people, and my book, Django for Beginners. I'm pleased to say we quickly ran through all 25 books on hand, and there were still quite a few people in line, so next year, we'll have to order more books!

Sunday, May 18th

At 7:00am sharp, I headed off on a run with my colleague Galina, the PyCharm Product Manager, who is also a competitive ultramarathon runner. There are some great running routes in Pittsburgh along the rivers and bridges. I am a casual runner at this point in my life, so the plan was that I'd run with her four or so miles and then turn around to head back into town at an equal distance. She continued on for a two-hour tempo run, while I got lost going back--at one point ending up 50 feet in the air along a railroad track that I thought was a shortcut but turned out not to be--and the overall return journey turned into a lot longer slow run/walk than expected. I didn't bring my phone, or I would have some pretty dramatic photos to show from this detour.

After finally making it back to the hotel and showering, I was ready for a proper breakfast. I headed to Sally Ann's just down the street, which had excellent avocado toast and a cappuccino.

Sally Ann's Breakfast

Then, it was off to the convention center for more open spaces on topics including Django simple deployments, high-performance Django, and AI evals. All three gave me a lot to think about.

Given the long run/walk earlier, I was pretty well famished at this point, so I made it over to Bae Bae's Kitchen for a Bulgogi and egg seaweed burrito.

Seaweed Burrito

Then, it was more socializing with friends and colleagues and a recap with the entire PyCharm team from 8 to 10 p.m. that evening.

Monday, May 19th

I had an early flight back to Boston, so I was out the door by 7 a.m. and home in time to pick up my son from preschool. A short flight in the same time zone is a gift versus longer trips overseas.

Overall, it was a jam-packed trip. I saw Pittsburgh for the first time, learned a lot, and interacted with hundreds of people about PyCharm and our new AI features. As there always is with PyCons, there is a lot to take away. If you have the opportunity, I strongly recommend attending one yourself in the future!

What's Happening in Developer Tools? (OpenAI Just Bought Windsurf for $3B)

Will Vincent — Wed, 07 May 2025 23:22:00 +0000

Disclosure: I work at JetBrains, a competitor in this space, and all comments are my own.

Yesterday it was announced that OpenAI was buying Windsurf, an AI-first code editor, for $3 billion. This is a pretty amazing feat considering that Windsurf has only been Windsurf since November 2024, a long seven months ago. Before that, it was Codeium, an AI-complete tool that plugged into existing IDEs like VS Code and JetBrains. And before that, way back in 2021, it was founded as Exafunction, which focused on optimizing GPU usage for Machine Learning workloads.

A $3B acquisition is indeed extreme, considering Windsurf's annualized recurring revenue (ARR) is reportedly $40m, which makes it a 75x acquisition premium. For context, a typical premium for a mature Software-as-a-Service (SaaS) business is 3-7x, for high-growth, 8-15x, and for hypergrowth, 15-25x. When Microsoft bought GitHub in 2018, it was at a reported 25x premium. Windsurf's 75x multiple is literally off the charts.

And remember, this is revenue, not profit. Most of Windsurf's revenue is directly related to LLM usage, ie. collecting money from customers and using that to buy tokens from LLM providers like OpenAI or Anthropic.

OpenAI just raised $40B at a $300B valuation, meaning they acquired Windsurf for 1% of their current value. But at the same time, OpenAI reportedly lost $5B in 2024, and their own coding agent, codex, has had middling success. Clearly they were feeling pressure to "do something." It has been widely reported that they were interested in acquiring Cursor, the leading startup AI-powered coding editor, yet the price was too high. Cursor was founded in 2022 and just raised a $900m Series C round at a $9B valuation on the back of doubling its ARR from $100m to $200m over the last two months. Clearly, something is afoot!

The Current Developer Tooling Ecosystem

At the moment, the developer tooling ecosystem contains a dizzying mix of companies, products, and goals. Let's try to break it down and see where all these forces interact.

Part 1: LLM Models

First, there are the LLM models powering the current craze: ChatGPT from OpenAI, Claude from Anthropic, Gemini from Google, and many more. Some of these models are proprietary, others like DeepSeek and Facebook's Llama are "somewhat open," and others like Mistral and Phi-3 from Microsoft are truly open.

Amongst the general public, ChatGPT has the headstart and the branding, yet Claude by Anthropic is the clear leader amongst developers who are willing to pay real money for it. Thus, even as ChatGPT has been succeeding in growth, it has not managed to tap into what is currently the most lucrative part of the market. Claude's advantage means that it gets something even more valuable: data. When a developer uses a cloud LLM, they send their context (aka their coding files/projects/etc) to the LLM provider, who can evaluate how successful the responses were, retrain the model, and so on. This also means an LLM can slice and dice its customer base to find out what types of developers and companies use what.

If LLMs eventually start adding ad-supported tiers—and I think it is inevitable that they will, given that search is clearly broken-then they will want to harvest as much customer data as possible for targeting. It is likely that the current emphasis on result quality will face pressures around revenue, and so on. But that's a separate thread.

The more immediate issue is that it is unclear currently whether the hundreds of billions of dollars invested into LLMs will result in truly proprietary models that can charge a premium or whether the space will be eventually commoditized. There are even newer smaller models focused just on a specific task; for example, JetBrains just open-sourced Mellum, its own coding LLM.

The fact that DeepSeek's launch in January led to a $1T (that's trillion, by the way, with a T) stock market loss speaks to fears that maybe all this investment in proprietary LLM models costing billions of dollars isn't an infinite pile of cash to collect. Perhaps only a few million dollars is needed. And what if your competitor gives away the model for free?

Part 2: Apps

Then there are the apps. These days, almost every startup and company is "AI-powered," a deliberately broad term that deserves unpacking. But for this analysis, let's focus on text editors like Windsurf, that sell AI-powered coding editors to developers.

Microsoft's Visual Studio Code is a free code editor that relies on community plugins for support across various languages and frameworks. It also has an AI offering, Copilot, that provides code completion and it just added its own agent. VSCode supports multiple LLMs, but initially, there seemed to be a preference for ChatGPT, in part given its early lead and no doubt influenced by the fact Microsoft was an early investor in it. However, that relationship seems to be fraying.

Cursor and Windsurf are forks of VSCode, which means the developers copied the open-source VSCode code base and then modified it on their own to add AI and other features. That's why relatively small startup teams of recent college graduates could make such progress, taking an existing and relatively mature project and focusing on just the AI integration.

Somewhat predictably, though, Microsoft has started to restrict access to the VSCode Marketplace and popular extensions. Presumably, Cursor and Windsurf have the resources to recreate and manage these things. Still, it is a lot less glamorous than focusing on the fun AI parts and will consume company attention and money. This is just the latest iteration of Microsoft's famous "Embrace, extend, and extinguish" strategy, first seen in the United States government's antitrust legal case against it in the 1990s:

Embrace - Development of open source software and standards
Extend - Add features, creating inoperability problems
Extinguish - When extensions become de facto standards, marginalize competitors

There are other AI agents and text editors out there, including Replit, Zed, and many others, but if you say AI text editor at the moment, most people will think of Cursor/Windsurf/VSCode.

A fourth option in this space is my employer, JetBrains, a privately held European company that has been around for over 20 years and creates popular free and paid tools for developers. JetBrains has been aggressively improving its own AI offerings, including AI Assistant that integrates chat mode with leading LLM models and its own coding agent, Junie.

It is worth pointing out that JetBrains does not have the same funding pressures as VC-backed startups. It does not have an expensive LLM model to maintain and market. It does not have a $2T market cap and other offerings like Microsoft. JetBrains is focused solely on developer tools, primarily text editors.

Part 3: The Future

So where does this analysis of current models and apps leave us? Are we in a bubble or a new age where developer tools are worth tens of billions of dollars?

One possibility is that the total market for developer tools has greatly expanded now that "vibe coders," aka non professional programmers who want to build software, can now do so with the help of AI. I think there is a definite limit to how much a non-technical person can build, but there's no question they can do a lot more than before and they are willing to pay for it.

But even if the total market has grown and doesn't contract in the future, I'm still somewhat skeptical that the current pace is sustainable. After all, where will we be in just 2-3 years if OpenAI and Anthropic, both VC-backed and losing billions, have failed to either greatly improve their models to ChatGPT 5 levels and/or stop losing money? And what about Google, which has its own Gemini model but no coding editor to speak of? Given its current valuation, it seems the natural--and, indeed, the only--company capable of buying Cursor.

But how much value is there in the app compared to the underlying LLM model? I'm partial to the hypothesis that smaller, potentially local, and maybe even "free" models will win out. That puts the emphasis back on the integration with the text editor.

A final point is that AI certainly has a place in software development and will only grow in the future. But is it a total replacement or just a new tool developers must adopt? I agree with Tim O'Reilly here, who wrote a fantastic piece called The End of Programming as We Know It that provides some historical context for the current hype, pointing out that there have been radical changes in the recent past, from desktop to internet programming, from compiled to interpreted languages, and so on.

Marie-Alice Blete has a wonderful graphic illustration of the current AI engineering landscape.

If there is one person I personally look to for insight into what's coming, it is Simon Willison, who writes regularly and knowledgeably about these trends. In January, he posted an annual My AI/LLM predictions for the next 1, 3, and 6 years that provides a fantastic analysis of what might occur.

Thoughts on Vibe Coding

Will Vincent — Tue, 06 May 2025 14:28:00 +0000

After reading yet another AI hype article--this one by Kevin Roose at the New York Times gift link here--I feel compelled to respond.

Let's look at the title:

We could easily swap out "Not a Coder" with just about any profession. Not a writer? Not a doctor? Not a lawyer? Not an engineer?

The idea that you can whole swath replace an entire field or area of expertise is wrong on a number of levels. So here we go.

1. Current AI Is Not Intelligence

All the evidence we have is that current AI does not appreciate actual intelligence. See Gary Marcus's prescient take in 2022, Deep Learning is Hitting a Wall, for more on this. What has happened is that existing LLMs turn out to do really well with huge amounts of data and compute power.

2. AI vs LLMs

It's also important to note that AI and LLMs are not synonymous, even though it is common to see journalists and others in popular media conflate the two terms. "AI" is a very large field and applies to much more than just Large Language Models. For example, DeepMind's AlphaFold used deep learning to predict protein structures (see the Nature article) and this resulted in the 2024 Nobel Prize in Chemistry for members of the team.

But that is not what LLMs do. Rather, they ingest large amounts of data--think downloading most of the internet such as Reddit and Wikipedia, not to mention copyrighted books--run them through algorithms, do fine-tuning, and the result is a probabilistic mathematical function that predicts the next word in a sequence. In other words, LLMs try to predict the next response to any user input. There is not currently any actual "intelligence" there.

However, modern LLMs are powerful enough that they can seem intelligent and indeed do well on standard measures of intelligence, such as taking the SAT or answering math questions. Yet if I preloaded all SAT questions ever into a computer and then asked it to answer them, and it got the right answers, is that intelligence or just memorizing? It's not really intelligence.

Similarly, LLMs are a long way away from actual AGI (Artificial General Intelligence), a theoretical form of AI that has or exceeds human reasoning.

So AI is a real thing, a deep field with lots of applications, of which LLMs are just a subset, albeit the most popular one amongst the general public at the moment. Take a lot of data and run it through algorithms, and the result is something that tries to predict the right response.

Andrej Karpathy's Intro to Large Language Models video is one of the best resources out there to actually explain how LLMs work, if you want to dive deeper.

3. Vibe Coding

Vibe coding means using an LLM in a modern text editor to generate all your code for you. Rather than actually code, you say things like, "Build me a website that helps choose lunch." And away the LLM will go, churning out code for you. From there, you can ask it to refine and use specific technologies or features.

It is possible in some contexts to have a working website this way, provided it is doing routine tasks and you don't have to really trust it. Why? Because the LLM has been trained on billions of lines of code by human programmers, so it is quite good at trying to predict how to do that. However, two major problems emerge.

First, what happens when you want to do something that needs to be 100% correct? For example, building a website that handles payments in some way? Or manages user information that must be private? LLMs still wildly hallucinate and if you are not knowledgeable yourself, there is no way to tell when your code has deep-seated errors. Second, if you've used an LLM to write hundreds of lines of code you don't understand, there is no way to go in and meaningfully change things yourself. An LLM will want to rewrite and repredict most of it, not laser focus on a particular area. And if you don't know what the code is doing, how can you even tell the LLM where to start?

This speaks to the larger truth that most of programming is reading and understanding existing code. It is not starting with a blank canvas and creating things from scratch. Programmers typically work in teams on complex codebases with millions of lines of code. If just one person puts in a serious mistake, it can cause the whole artifice to stop functioning correctly or, worse, to have hard-to-find bugs that result in big problems.

If I were to ask 10 experienced developers today to build the same membership website that handles user accounts and payments, they would all do it slightly differently. Which way is right or wrong? If you have no programming knowledge yourself, it is hard to weigh in on decisions. Hard to evaluate any of them? If it's hard to do this even with experts, how can you expect a statistical function to do better on its own that you lack the capacity to evaluate? That's a long way of saying, someone somewhere needs to actually understand--or have the ability to understand--what is actually happening.

4. Using LLMs Today

I've spent most of this post talking against LLMs, but it's important to note that I personally use them daily, not as a replacement for my thinking or writing or programming, but as a drunken partner. By that, I mean LLMs are fantastic for generating ideas based on a topic. For example, "I want to build a membership website with payments and user accounts, what are 5 different ways I could architect it." This is useful and something I have done recently, because it provides an overview of existing approaches. From there I can dig deeper, asking questions about design decisions, and even asking for specific pieces of code. But the "drunken" part of my description is important: I don't trust the LLM. And I shouldn't. It is a guessing partner that can help me be creative, sometimes can find bugs or help with things, but it all has to be run through a human filter that has some domain knowledge.

In this way, I think of LLMs as similar to Steve Jobs's description of computers as, "A bicycle for your mind." With them you can travel much further, but they don't replace your mind. And I suspect they never well.

Final Thoughts

I'll end this piece with something I've been thinking a lot about recently. Let's assume an Artificial General Intelligence (AGI) is actually created that far exceeds human capabilities. How would we even know that? Even if it came to seemingly correct decisions, if we do not understand its reasoning--and with current LLM approaches it is impossible to derive how, exactly, the models reasoned on something--then what value does it have?

We are already in a world awash with more facts and knowledge than ever before, and yet our everyday and political discourse has never been dumber. I highly doubt there is an actual AGI out there. Instead I think there are increasingly powerful tools that enable educated humans to be better (and learn more) about what they are trying to master.

Final, Final Thoughts

As a fun exercise, try using an LLM to write an article like the author's mentioned at the top of the page. If you prompt it with, "Write a New York Times article in the style of Kevin Roose that explores vibe coding and the idea that you don't have to be a programmer but can instead just use artificial intelligence." The result won't be as good as what he wrote, but it will be pretty close. And more importantly, how many readers will really be able to tell the difference between the two? Especially if they are just going to copy and paste the article into an LLM and ask for a short description of it, rather than read the whole thing themselves. 😛

Vibe Recap of DjangoCon Europe 2025

Will Vincent — Tue, 06 May 2025 14:08:00 +0000

DjangoCon Europe 2025 was in Dublin, Ireland, this year, and I was fortunate enough to attend, thanks to my employer, JetBrains. This is my second time attending a European DjangoCon, the first being in 2023 in Edinburgh, Scotland.

Compared to U.S. DjangoCons, the European version feels a bit more intimate. Rather than two separate tracks of talks (as in the U.S.), there was one room for the main talks and a smaller side room for workshops and other events, which meant that most people attended the same events.

I recorded a Django Chat podcast on the conference if you prefer your info in audio format, but then you'll miss out on some of the pictures below.

Ireland Pre-Conference

The week before coincided with my children's school vacation week, so we took our first overseas trip together, exploring the country's southwest corner, namely Killarney and Ennistymon. Unsurprisingly, Ireland is beautiful, wet, and very rural. I'd love to return and spend more time soaking it all in. Here are a few highlights:

The Cliffs of Moher

The Burren

Inishmore

Typical Irish Breakfast

Typical Irish Dinner

Day 0 (Tuesday)

The night before the conference I met Carlton Gibson at the airport and traveled down to the conference venue, the Talbot Hotel Stillorgan. There is a very convenient Aircoach bus option, but given it was quite late and pouring rain, we opted to share a taxi instead.

There were too many talks and workshops to give them all justice, so what follows is a series of highlights based on what I could attend in person.

Eventually, all talks will be on YouTube. I will add a link to that playlist when it is live, but you can subscribe now to the DjangoCon Europe YouTube account to be notified when they are live.

Day 1 (Wednesday)

The day started with a keynote from Django Fellow Sarah Boyce titled "Django needs you! (to do code review). " She discussed the current review process and why it takes so long, which is a source of frustration for everyone. I enjoyed her overview of the bottlenecks in the current system, as well as a lively question-and-answer session afterward about all things Django.

Sarah Boyce giving the opening keynote.

Next up, Jacob Rief gave a great talk on "End-to-end testing Django applications using Pytest with Playwright," probably the most popular testing pattern I see these days, and he had a lot of examples and insight into why it's such a powerful combination. You don't have to use Pytest--in fact, I don't use it on LearnDjango.com--but on an intermediate and advanced code base, it can be much faster than Django's testing framework and comes with a ton of extra goodies around testing.

Tim Bell was the following speaker and talked about his current work at Kraken, converting integer fields to bigint using Django migrations at a massive scale.

Before lunch, Adam Johnson presented on writing indexes to improve your queries, another perennial topic for at-scale Django apps.

During the afternoon, the workshop room had a Q&A with the Django Software Foundation Board. Four board members were present--Thibaud, Sarah, Tom, and Paolo--and there was a presentation on the current state of things, work in progress on various new initiatives, and then lively questions from the audience. The Django Board meets monthly and online, so conferences like this are one of the few opportunities for them to meet in person and with the broader Django community.

In the evening, Django Social held an event in downtown Dublin, but I was fairly tired, so I took what Kojo Idrissa has termed a self-care sprint. I spent a quiet night having dinner by myself and walked down to the water. In his words, "Self-care sprints make EVERY OTHER Sprint sustainable."

Commuter train running alongside a park and the sea with Dublin in the distance.

Day 2 (Thursday)

I felt much refreshed this morning, and several people even commented that I seemed more like myself than I was on the first day. So, self-care sprint for the win!

The opening keynote was by Mia Bajić on "The Most Bizarre Software Bugs in History." It was a super engaging talk and one I highly recommend watching when the video comes out. It's not Django-specific but relates more generally to software bugs and how things can/do go wrong.

Mia Bajić presenting.

Next up was "How to get Foreign Keys horribly wrong in Django" by Haki Benita, and if I had to vote on the single most impressive technical talk I saw, it was this. He really knows his stuff on databases and Django and the talk was more like a university lecture, mixing examples with audience interaction. Unsurprisingly, he also teaches online live training with O'Reilly, and I need to take some of his classes.

After Haki's talk, my podcast co-host Carlton Gibson spoke on "How we make decisions in Django" because there is a lot of concern that Django's current decision-making process is no longer working. To quote his abstract of the talk, "New feature requests often hit a wall, as an endless discussion thread arises for even the smallest proposal. New contributors are frustrated. Established contributors are exhausted. It's not serving anyone." He provided an overview of how we got here and suggested several ways to improve things. The talk also dovetails with the work he and others are doing on the new Django Steering Council.

Carlton Gibson presenting.

After his talk, I had to find a quiet room and work on the slides for my own presentation. One downside of presenting is that you can't fully relax until your talk is over.

After lunch, Carlton and I celebrated his talk and had a few drinks at the bar. While there, we met Wouter Steenstra and colleagues from Monit a Dutch platform for tracking and measuring parking data. He had just given his own talk, "100 Million Parking Transactions Per Year with Django," and so we had a hallway track meetup of sorts over beers.

In the evening, there was a Speakers' Dinner at Eddie Rocket's, an American diner-themed restaurant nearby. I always enjoy these evenings because it's a chance to meet other speakers and have a somewhat quieter discussion about things. After dinner, many people headed to a nearby bar to continue socializing but I had to retire early as I was presenting the following morning.

Speakers's Dinner après (photo courtesy of Paolo Melchiorre).

Day 3 (Friday)

I led off the morning by giving a keynote talk on Django for Data Science that showed how to train a machine learning model from scratch in a Jupyter notebook and then deploy it using Django. Along the way, there are lots of points about data science generally and how it can/should integrate more closely with web development.

Will Vincent presenting.

You can try out the live version of the demo at DjangoForDataScience.com. Here is the Jupyter notebook repo and the Django repo.

I think Django is perfectly placed to be the default way data scientists post their information and interact with users. After all, it's already in Python, comes with built-in batteries for most of what's needed--CRUD, auth, security--yet most data scientists find the web and Django in particular quite confusing.

If I'm able to do an updated version of this talk, I'd like to dive more into two areas. First, more focus on the actual training of the model part using scikit-learn. There are a ton of built-in algorithms for supervised (labeled data) and unsupervised (unlabeled data) learning. Just as Django abstracts away much of the low-level coding required to build a web framework, so too does scikit-learn abstract away a lot of difficulty coding required if you were to craft this algorithms from scratch yourself.

The second area I'd dive deeper on is completing the feedback loop. Currently, we trained an ML model, presented it to users, and recorded the results. But in the real world, a data scientist would want to take those records and use them to retrain the model iteratively. Think of a recommendation engine for books as one example. In fact, my colleague Jodie Burchell has an excellent free course on this topic if you're interested, LLM Course – Build a Semantic Book Recommender (Python, OpenAI, LangChain, Gradio).

After my talk, it was time for Paolo Melchiorre to present on Djangonaut Space, an amazing program that has paired experienced Django contributors with newcomers.

At the coffee break, many people came up to discuss data science with me. Several people in attendance were using Django and data science professionally, so I wanted to learn as much as I could from them about how these two domains are being combined in the real world.

I want to mention that the food at the conference was excellent. The coffee breaks had coffee, decaf, tea, scones, and other small pastries. For lunch each day, there were sandwiches and other goodies. More importantly, the food was laid out near the main conference room, so everyone could seamlessly gather in between talks.

Following the break, there was a talk on "Evolving Django: What We Learned by Integrating MongoDB" by Anaiya Raisinghani. MongoDB recently introduced official Django support, and we did a whole podcast episode of Django Chat with Jib Adegunloye, the lead engineer on the effort.

Anaiya Raisinghani presenting.

At the same time, in the workshop room next door, there was a live recording of the Real Python Podcast with audience participation. Hopefully, that episode will come out soon.

The last morning's talk was on Feature Flags by Graham Knapp. Feature flags activate features for some users while hiding them for others. Graham had many good tips on how to use or misuse the flags.

After this talk, I spent a while doing the "hallway track" and chatting with various people about what we'd seen so far, how each of us was using Django at work, and so on. Quite a few people used PyCharm and had feedback on it and the recent AI releases.

In the afternoon, Karen Jex gave a very in-depth yet accessible talk on database operations, focusing on what happens behind-the-scenes when you send a database query, how is data stored, retrieved, and modified. And more importantly, why should you care! You can see her slides and notes here.

With a basic understanding of the way select, insert and update operations work, you can make sure your code and database play nicely together!

It's a tough balancing act to see all the talks while taking time to chat with people in the hallway. I try to aim for 2/3 talks and 1/3 chatting during talks, but ultimately, we're at a conference to meet other people, so I will usually prioritize continuing a great conversation with someone over cutting it short to go see a talk.

At the end of the talks, there was a moment of thanks to all the conference organizers. These are all volunteers who do an incredible amount of work to plan the event, run it day-to-day, select the talks, and so on. It's an incredible gift to our community that year after year people are willing to do this work.

Conference organizers (photo courtesy of Adam Johnson).

In the evening, there was a party at The Camden in downtown Dublin, so many of us hopped onto buses and headed there.

Bus to dinner (photo courtesy of Paolo Melchiorre).

We stopped off at an excellent sushi restaurant along the way.

Sushi dinner (photo courtesy of Paolo Melchiorre).

Before making it to the party itself, Adam Johnson discovered an ancient Viking Archaeology Site underneath a Lidl supermarket. So, of course, we had to check that out.

Archaeology site in a supermarket.

The party was at The Camden, and many people from the conference were able to attend. I enjoyed chatting with the folks from Hacksoft, among other conversations.

The Camden.

DjangoTV

At both DjangoCon Europe and DjangoCon US, talks are recorded and later released on YouTube. This is so helpful even if you can attend because it's not possible to see two talks at once, and it's better to be present and listen rather than furiously write down notes. But even so, it can be difficult to find all the amazing content put out by the community.

To that end, Jeff Triplett, a current Django Board member and my partner on the Django News newsletter, has a website called Django TV that compiles conference talks from all the DjangoCons, Django events, and Wagtail conferences globally. I strongly recommend taking a look to uncover some gems you might have missed.

DjangoTV Website.

Final Thoughts

I always come away from DjangoCon events feeling energized about the community and our beloved framework. It is an investment of time and money to attend (or speak at) these events, but they are so vital to the continued health of the ecosystem. And if anything, the second or third times you attend are even better because everything is so new the first time, and you are doing lots of "nice to meet yous" with people you follow online. But in the following years, you can jump right into conversations about things. And it puts a human face on our otherwise digital community interactions.

Carlton Gibson and I both came away with a long list of people we'd like to chat with in the fall for Django Chat. I received lots of generally positive feedback on PyCharm and our new AI features, which I was happy to share with my colleagues on my return.

When you work on a digital product like PyCharm, it's easy internally to focus on the feedback you see on the socials/Reddit/videos, and generally, people only take the time to write or say something if it is very negative. There's almost always something actionable within a complaint, but hearing that many developers are using PyCharm, enjoying it, and have small critiques is a more realistic representation of our user base, but you can only find that out through in-person interactions.

Averaging Our Way to AGI

Will Vincent — Tue, 04 Mar 2025 18:52:00 +0000

I’ve been thinking a lot recently about this LinkedIn post (shout out to my colleague, Michelle Frost, who first brought it to my attention), which makes the point that LLMs, initially built for translation and pattern matching, were then hyperscaled via Transformers and lots of money into the current leading example of AI intelligence amongst the general public.

Are they truly a path to AGI (Artificial General Intelligence), a broad term used as a goal meaning an LLM that matches or exceeds human capabilities? Currently, we have ANIs (Artificial Narrow Intelligence) that can far exceed humans in closed systems, such as games like Chess or Go. However, true AGI is still in the future, even as companies like OpenAI publicly point to it as a goal for their products.

Can the LLM approach ever reach AGI? I suspect no. The underlying architecture is designed to approximate, pattern match, and guess. It was initially built for language processing and translation. There is no deep inference of meaning or logic there, no matter how many hidden inputs the models create.

The algorithms used to train LLMs have been around for quite a while. What was lacking until Transformers came onto the scene in 2017 was the ability to massively scale them. ChatGPT was among the first to use Transformers and publicly release them to the general public. While there are other LLM models out there, we will focus on GPT’s history here to give a sense for how quickly these models have grown.

Brief LLM History

Let’s use GPT as a proxy for advancements in the field in general. We can track the rapid changes based on their model releases from 2018 to the present.

GPT-1, released in 2018, had 117M parameters and was trained on BookCorpus, a dataset of 7,000 self-published books. A “parameter” is a numerical value the model learns during training. Broadly speaking, more parameters mean a model can store more complex patterns and perform better, although at a certain point (see future sections) efficiency matters more than just size.

GPT-2 was released the following year, 2019, and had a large leap in parameters (1.5B) as well as training on a much larger dataset, WebText, containing 8 million documents and 40GB of text. The model had more fluid text responses but still struggled with accuracy and relevancy. This was the last GPT model that was open source; by GPT-3 the company shifted to proprietary closed models and datasets.

GPT-3 (2020) was the big breakthrough: for the first time, a publicly-available LLM generated responses that felt vaguely natural, though it still suffered from hallucinations and errors in back-and-forth conversations. It featured 175B parameters, a much larger (though proprietary) dataset that ChatGPT itself estimates at ~570GB, and a larger “context window” (the number of tokens a model can process at once). Context windows become increasingly important since LLMs are inherently stateless--each request is independent of previous ones, similar to HTTP. On the web, we use cookies to remember “state,” such as whether a user is logged in to a website. In an LLM, a context window allows the model to process more information--vital for analyzing long documents--and maintaining a back-and-forth conversation history with the user.

To highlight this point, if I am using an LLM to help with programming, it is very helpful if I can send the entire codebase to the LLM, which stores it in the context window, and therefore all future requests reference the same stored data.

Three years passed before GPT-4 was released in 2023. The number of parameters was not publicly released, but it was likely over one trillion. Instead, the focus was on efficiency and smarter parameters rather than just more of them. GPT-4 demonstrated near-human-level performance in many exams such as the US bar (law) exam, GREs, AP courses, and so on. It was able to process text and images quite well and featured a much larger context window of 8,192 tokens.

The Competition

Amidst these rapid improvements to GPT, a growing ecosystem of competing LLM models emerged. In 2023, several “open” models were released for the first time: Mistral, Falcon, and Meta’s Llama. Mistral and Falcon are available for commercial use, reveal their model weights (meaning anyone can use the models) and training code, but both have some restrictions on training data information. Llama has open weights, too, but restrictions for large companies. Llama also does not disclose its training code or training data.

In the proprietary LLM space, many competitors popped up, most notably Anthropic, founded by former OpenAI engineers. Anthropic’s Claude model was first released in March 2023 with 9,000 context window tokens (more than GPT-4), and by September 2024 featured a 500,000 token context window, allowing for GitHub integration, and other advanced features. This made it arguably better than GPT for many coding tasks, as well as analyzing entire books, legal documents, financial reports, and so on, since all of the data could be fed directly into the context window for processing by the model.

The prevailing thought at this time was that there were still-unlimited gains to be had by increasing the amount of computation and data in LLM models. As a result, billions of dollars of VC and corporate money went into this LLM arms race.

2025

In January 2025 there was a “Sputnik moment” with the release of DeepSeek from a small Chinese company. DeepSeek roughly matched the performance of leading LLM models, including GPT 4, while open sourcing its model weights, training data, and allowing commercial use. The DeepSeek app was the most downloaded one on the Apple App Store the weekend it was released. But even more amazingly, DeepSeek claimed that training costs were only $6 million, rather than the billions used for competitors.

We don’t know how accurate that $6 million figure truly is, but training costs were clearly far less. DeepSeek used a number of novel techniques including “knowledge distillation,” essentially training student models on larger teacher models, most notably Meta’s Llama and Alibaba’s Qwen.

DeepSeek’s release of a cost-effective LLM model led to a $600B drop in market value for Nvidia, the company behind the GPUs used to train most models.

The following month, February, GPT 4.5 was released, featuring a 30x cost increase over GPT 4, and so far, it seems, provides only marginal improvements.

The Future

The back-to-back releases of DeepSeek and then GPT 4.5 bring up the question of whether we are finally in an era of diminishing returns for LLMs. Has the previous approach of ever-more computation and data finally reached a limit? Gary Marcus famously predicted this back in 2022 with his piece, Deep Learning is Hitting a Wall.

So what’s next? I suspect LLMs will continue to make marginal improvements, training costs will decrease, and we’ll see more and more open-source options available, as well as more and more LLMs trained on specific datasets and use cases, such as JetBrains’ Mellum. Will open-source models that are good-enough win out over proprietary ones? Or will proprietary models continue to improve at a rate that justifies their growing price tag?

I suspect we will also see improvements in the broader LLM ecosystem, such as an ever-increasing context window, which leads to a growing use case of industries where models can be applied.

The larger issue of model inaccuracies and hallucinations persists. If a user asks a sufficiently niche question that the model wasn’t trained on, it will struggle to generate a good response. Likewise, if you ask questions after a model’s training data period, it will not handle them well. But there are techniques, such as Retrieval-Augmented Generation (RAG), that promise some solutions. RAG allows a model to interact with external data sources in real-time--for example by doing its own searches--to either supplement or double check its initial responses.

And in the AI-assisted coding realm--where I work at JetBrains--things are really heating up with the rise of agents that can use AI to not just ask questions, but update code on its own. I don’t think this means the end of programmers, something I wrote about previously in Thoughts on Vibe Coding and which Gary Marcus (again) wrote about more eloquently soon thereafter. But it is clear that programming tools are changing rapidly and likely most professional programmers will use LLMs to help write code going forward.

But while LLMs have dominated the spotlight in the quest for AGI, it’s important to remember that they are not the only approach. There are other potential pathways such as reinforcement learning, neuro-symbolic systems, and hybrid models that combine multiple approaches. It is far to say that LLMs have demonstrated the power of scale, but given they are still--by architecture and definition--trying to average their way to the next response, they are not a straight path to true AGI.

Will we ever get there? Personally, I have doubts. We still can’t even define intelligence in humans, let alone machines. Maybe there is some sort of incompleteness theorem that AGI attempts will bump up into. Or not. I am keeping an open mind. But it is clear to me that LLMs are a game-changer but not the end of the game when it comes to AI surpassing humans.

Big thanks to my colleague, Michelle Frost, for detailed feedback and suggestions on an earlier draft of this piece.

What Does a Developer Advocate Do?

Will Vincent — Thu, 27 Feb 2025 14:14:00 +0000

I'm two months into my new job as a Python Developer Advocate at JetBrains and realize there is a lot of confusion in the general public about what exactly a Developer Advocate does.

Defining the Role

Conversations with friends and family are typically along the lines of:

Them: Congratulations on the new job! So what do you do?

Me: I'm a Developer Advocate.

Them: So what do you do day to day?

Me: It's a mixture of content, marketing, and community. I help developers learn and, where possible, feature our tools (primarily the PyCharm IDE in my case).

Them: So are you writing code or doing marketing?

Me: Both, but I'm not in marketing and I'm not a programmer per se.

Them: Ok (eyes glaze over and move on to another topic)

The History of the Developer Advocate Role

In fairness, the concept of a Developer Advocate is pretty foreign outside of the tech ecosystem. It is a role that sits between product, marketing, and community. The earliest forms of developer advocacy emerged in the 1980s, when companies like Microsoft, Apple, and IBM who had "Evangelists" promoting their platforms. In the 1990s, Microsoft had "Platform Evangelists" who helped developers build applications on top of the Windows operating system.

But it is in the 2000s when the term "Developer Advocate" really picked up speed. Google is often credited with formalizing the role with employees who focus on developer experience (DX), APIs, and open web standards rather than just sales. Companies like Mozilla and Twitter also adopted Developer Advocacy positions to help engage better with developers building on their platforms.

A big reason for the role is that developers do not like to be marketed to. It is hard to sell products in traditional marketing ways to a group of superusers who are likely skeptical, full of questions, and want a domain expert to engage rather than just read or watch marketing materials.

By the 2010s, Developer Advocacy had become a standard role in cloud, API-driven, and developer tools companies like AWS, Twilio, Stripe, GitHub, Docker, and JetBrains (my employer).

These days, almost every developer-focused company--ie. selling products and services directly to developers--has Developer Advocates.

Company-Level Developer Advocate Differences

Part of the difficulty in defining what a Developer Advocate does is that the role varies widely depending on the company. It is always a hybrid of content, marketing, and community, but that balance varies depending on the company's goals. For example, DAs (Developer Advocates) at large companies like Google, Microsoft, or Amazon/AWS are often product-centric, focused on advocating for specific cloud and developer products. That means deep dives into their APis, SDKs, and integration guides. DAs at other companies like Stripe or JetBrains, might be more developer-centric, writing tutorials, making videos, building sample apps, and helping developers integrate the product into their workflow.

It really depends upon the needs and size of the company itself. In an enterprise-focused company like SalesForce, Oracle, or IBM, a DA works closely with B2B customers, hosting webinars, training sessions, and working with sales teams. Whereas a startup-focused company would often have a DA do community-driven work, open source contributions, live streaming, and quick iteration on documentation and developer experience.

What does JetBrains Do?

My company, JetBrains, makes tools for developers, most notably IDEs (Integrated Development Environments), that make it much easier to write code in a variety of programming languages. It started off with one product, IntelliJ IDEA, which is an IDE for the Java and Kotlin programming languages. And soon developed multiple other products with a similar focus, including PyCharm, focused on the Python ecosystem.

The company just celebrated its 25th birthday and is privately held, which makes it somewhat unusual in a tech landscape dominated by VC-funded startups and established public companies such as Microsoft and Google. We have around 2,000 employees, which makes us not a small company, but again orders of magnitude smaller than our competitors, who typically have trillion-dollar market caps. And as a final point of differentiation, the company is based in Europe, whereas most of the tech industry is in the United States. JetBrains was originally formed in Russia and later established its headquarters in Europe, where there are large offices in Prague, Munich, and Amsterdam, as well as small regional offices around the globe. There are also remote employees, such as myself and most of the ~30-person Developer Advocacy team.

IDE Landscape and AI

The big change across all of technology, and especially developer tools, is AI. Everyday users have seen glimpses of its power through Large Language Models (LLMs) like ChatGPT, and developers are increasingly hooking into LLMs to power different products. For example, why pay a legal assistant to review thousands of documents when you can run them all through an LLM to pull out insights, find specific references, and so on? LLMs can also reason and increasingly find their way into medical contexts, where they can assist nurses and doctors reviewing patient information. And it turns out LLMs are quite good at writing code, which means every IDE out there is focused on integrating these capabilities into their product.

The most recent Python developer survey, from 2023, showed the following distribution of IDE/Text Editors:

As you can see, VSCode and PyCharm dominate. The big difference between the two is that VSCode is free and relies on community-driven plugins for Python-specific support. In contrast, PyCharm is paid (there are free and Professional editions, but 68% of respondents use the Professional one) but has built-in support for Python and the broader ecosystem.

VSCode is, therefore, the obvious competitor to PyCharm. It has a different value proposition and is backed by "an infinite competitor" in Microsoft, which makes buckets of money elsewhere and does not have to charge directly for VSCode. On the other hand, relying on community plugins has risks and the integration is often not as good as in a paid product, like PyCharm, which handles all of that for the developer.

But the big, big change is AI. JetBrains has AI Assistant whereas VSCode has Copilot. And there are even newer coding agents, such as Junie for JetBrains being released as we speak, that handle even more tasks directly for a programmer.

And there a host of VC-funded startups focused on AI integration such as Cursor, Windsurf, Zed, and many more.

So it is an exciting time. It is clear that AI tools can and will help developers write code, but the details of that remain to be seen.

A final point of interest is that the landscape for LLMs themselves is rapidly shifting. Simon Willison has an excellent overview of things as they stood at the end of 2024. Among the main points, LLM prices are dropping, there are ever-more open-source models that can run on a local laptop, and the costs of training next-generation models are falling, as demonstrated by DeepSeek, which claimed to match leading performance benchmarks for a fraction of the cost.

All of which is to say, will LLMs become a commodity soon? And if so, does that mean the integration of them is more important than the underlying LLM itself? We shall soon see.

My Role at JetBrains

So what do I actually do as a Python Developer Advocate at JetBrains? It's a mixture of things and the balance will change over time, but here are my current goals:

Content: Creating content is a big area, which means videos and guides on topics relevant to the commnunity, highlighting PyCharm-specific features where relevant. This is all in the works but something I'm very excited to release. I am giving a keynote at DjangoCon Europe this year and hope to also do a talk at DjangoCon US in the fall.

Community: This is a squishy topic to define but basically means being out-and-about in the Python ecosystem, listening to developers and learning about their current needs. I will be attending a number of conferences this year, including PyCon US, EuroPython, and PyTorch, as well as the two DjangoCons noted above. I also continue to produce the Django News newsletter and Django Chat podcast, which serve as community resources within the Django community.

Open Source: I'm excited at the prospect of contributing directly to Django, since JetBrains are big contributors in both dollars and time, to the Python community. There are open Django tickets to my name around documentation and user authentication that I plan to tackle this year. And I continue to maintain the awesome-django repo and the lithium Django starter project.

Product: The PyCharm IDE is the primary product I support, so I have regular meetings with the product team there, evaluating new and proposed features, providing feedback, and learning about what's coming out soon so that I can create content around it. I also work directly with the PyCharm Product Manager, helping to escalate certain issues, sharing insights from the community, and so on.

Marketing: PyCharm has a dedicated marketing department and as a DA I'm marketing-adjacent, meaning I work closely with them on specific things. That can mean reading over blog posts and other materials produced by the team there, to ensure they are accurate and appropriate. Or creating videos for PyCharm marketing pages and YouTube Channels, and directly highlighting new features.

Final Thoughts

So far I'm really enjoying my job at JetBrains. I have a great direct boss, helpful colleagues, and a wide variety of goals to tackle. I also appreciate working at a European company (a first for me), where everyone works quite hard but also values time to rest and recharge. That is somewhat new to me given my past experience at U.S. startups, but I know it is ultimately more productive for me personally and I think companies as a whole.

It is also a very interesting time to be in the developer tools space, given the rapid changes brought about by AI. JetBrains is well-positioned, ultimately, given that the focus is on solely on providing best-in-class tools for developers. There are no other ulterior motives or products to sell. We may lack some of the resources of larger competitors, but I think that makes us focus more on the task at hand.

Fixing Django FieldError at /admin/accounts/customuser/add/

Will Vincent — Sun, 23 Feb 2025 00:48:00 +0000

If you are a Django developer who wants to add a custom user model to your project, you've likely come across this error on Django versions 5.0 and above.

FieldError at /admin/accounts/customuser/add/ Unknown field(s) (usable_password) specified for CustomUser. Check fields/fieldsets/exclude attributes of class CustomUserAdmin.

The issue is around UserCreationForm. In Django versions up to 4.2, you could set your accounts/forms.py file to add updated user creation and change forms.

# accounts/forms.py
from django.contrib.auth.forms import UserCreationForm, UserChangeForm

from .models import CustomUser

class CustomUserCreationForm(UserCreationForm):

    class Meta:
        model = CustomUser
        fields = ("username", "email")

class CustomUserChangeForm(UserChangeForm):

    class Meta:
        model = CustomUser
        fields = ("username", "email")

However, as of Django 5.0, that leads to the above-mentioned FieldError. The fix is straightforward to do, thankfully, which is to swap out UserCreationForm for the newer AdminUserCreationForm instead, which includes the additional usable_password field causing the initial issue.

# accounts/forms.py
from django.contrib.auth.forms import AdminUserCreationForm, UserChangeForm  # new

from .models import CustomUser


class CustomUserCreationForm(AdminUserCreationForm):  # new

    class Meta:
        model = CustomUser
        fields = ("username", "email")


class CustomUserChangeForm(UserChangeForm):

    class Meta:
        model = CustomUser
        fields = ("username", "email")

You can see the related ticket #35678 and forum discussion.

For a complete guide on using a custom user model in Django, refer to this tutorial.

Django Redirects App Tutorial

Will Vincent — Thu, 05 Sep 2024 16:26:00 +0000

URL redirects are a fundamental part of maintaining a production website. There are many reasons why you might want to redirect a user from one part of your website to another, but doing so correctly is important for a positive user experience and to maintain the maximium SEO (Search Engine Optimization) possible.

Django ships with a built-in redirects app to help manage redirects, but the official documentation is not particularly friendly to newcomers, hence this tutorial.

Set Up Django Redirects

The Django redirects app works alongside the sites framework, which is also built-in but not automatically installed. We, as Django developers, need a few pieces of setup to use both fully.

To configure the Sites framework, add it to the INSTALLED_APPS configuration in settings.py and set a SITE_ID. It is customary to define a web application with only one site as 1.

# settings.py
INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "django.contrib.sites",  # new
]

SITE_ID = 1  # new

For completeness, you should run a migration now to update your database.

(.venv) $ python manage.py migrate
Operations to perform:
 Apply all migrations: admin, auth, contenttypes, sessions, sites
Running migrations:
 Applying sites.0001_initial... OK
 Applying sites.0002_alter_domain_unique... OK

Like the Sites framework, the redirects app is included in Django by default but requires some configuration. We will update INSTALLED_APPS, MIDDLEWARE, and again run a database migration. Note that when adding the middleware, it should be placed near the bottom to work properly since middleware is run from top to bottom for an HTTP request (and bottom to top for an HTTP response, but that is a topic for another day).

# settings.py
INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "django.contrib.sites",
    "django.contrib.redirects",  # new
    # other local and 3rd party apps
]

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
    # ... any other custom middleware ...
    "django.contrib.redirects.middleware.RedirectFallbackMiddleware",  # new
]

Now run migrations to create the necessary database tables for the redirects app to work.

(.venv) $ python manage.py migrate
Operations to perform:
 Apply all migrations: admin, auth, contenttypes, redirects, sessions, sites
Running migrations:
 Applying redirects.0001_initial... OK
 Applying redirects.0002_alter_redirect_new_path_help_text... OK

Our set up is complete. Let's explore two different approaches for using it.

Approach 1: Admin Interface

The Django admin is a user-friendly way to manage redirects without writing any code. It is ideal for quickly setting up a small number of redirects or for non-technical team members.

Log into the admin: the Redirects and Sites sections should be visible.

Click on the "+Add" button next to Redirects. It brings up a form to select a Site, a "redirect from" path, and a "redirect to" path. As noted on the page, use an absolute path for the former and either an absolute path or full URL for the latter.

Here is an example of adding a redirect from "example.com/old" to "example.com/new".

Once saved you will be sent to the main Redirects page where you can see and edit all existing redirects.

If you want to change the "example.com" portion of the site, click on the Sites section, and you can update the Domain Name or Display Name. The Display Name is the human-readable name for the site, used in the admin and in templates for identification. The Domain Name is used for URL generation and validation, such as in a sitemap.

Next Steps

The redirects app uses permanent (301) redirects by default, which is typically what you want for SEO purposes. It is important to regularly review your redirects and monitor performance on a production website, as a large number of redirects can impact performance, and you might look into caching options if this is an issue. Also, remember to use relative URLs for new paths to ease the transition between local, staging, and production environments. A final tip is to add tests to confirm that redirects are working as expected.

If you'd like additional tips on optimizing your Django website's SEO, check out the list of tutorials on this topic.

Getting Started with Django Tutorial

Will Vincent — Thu, 29 Aug 2024 02:12:00 +0000

This tutorial is designed for programmers new to the Django web framework, whether you are a beginner who wants to build web applications in Python for the first time or an experienced web developer looking for a complete overview of what Django offers.

In comparison to Flask, which adopts a microframework approach, Django is a "batteries-included" framework that includes by default most of what you need to build, test, and deploy powerful websites quickly. It has built-in solutions for user authentication (sign up, log in, log out), database connections and queries, logic, templates, security, and more. As the tagline says on the Django website, it is "The web framework for perfectionists with deadlines."

This tutorial focuses on Django itself. If you'd like to compare the two most popular Python web frameworks, please refer to the article on Flask vs Django.

What is Django?

Django is a web framework written in the Python programming language that takes care of the difficult and routine parts of web development--authentication, database connection, CRUD (Create, Read, Update, Delete) operations, URL routing, forms, security, etc.--so that developers can concentrate on what makes a website unique without needing to reinvent the wheel.

It was initially developed in the early 2000s at the Lawrence Journal-World newspaper in Lawrence, Kansas, and named after the famous jazz guitarist Django Reinhardt. First open-sourced in July 2005, Django grew rapidly thanks to an active community, regular updates, and widespread adoption that makes it one of the most popular web frameworks used by companies including Instagram, YouTube, Spotify, DropBox, Octopus Energy, and more.

Django is run as a non-profit by the Django Software Foundation and features regular local meetups, an online forum, and constant updates every month with a major new release every eight months. In short, Django is a mature and stable technology that is also actively maintained and improved.

Why Use The Django Web Framework?

Django's "batteries-included" approach offers a wide range of features right out of the box, including:

ORM (Object-Relational Mapper): write Python rather than SQL to create and query database information
Admin Interface: a visual way to interact with website content
URL Routing: clean, elegant URL schemas that are easy to maintain and reason about
Templating Engine: a simple syntax for adding variables and logic to create dynamic HTML
Forms: a powerful form library that handles rendering forms in HTML and validating user-submitted data
Authentication: a full-featured and secure authentication system for user accounts, groups, permissions, and cookie-based user sessions
Internationalization: multilingual support plus locale-specific formatting of dates, time, numbers, and time zones
Security: protection against SQL injection, cross-site scripting, cross-site request forgery, clickjacking, and remote code execution
Documentation: world-class documentation that is extensive and actively maintained by the community
Third Party Packages: thousands of supplemental packages available to provide further functionality (see DjangoPackages.org)
Regular releases: bugfixes every month and a major new release every eight months
Written in Python: an expressive language suitable for beginners and used in many areas of programming, including data science, AI/ML, scientific computing, web scraping, and more

But the best part of Django is the community, which is welcoming and supportive to developers of all backgrounds and experience levels. There are regular meetups in major cities, annual conferences, online communities, and a forum to help fellow developers.

What are the Prerequisites for Django?

The two major prerequisites are a basic understanding of the Python programming language and web development fundamentals. You should understand Python syntax, how to import and export modules, and be familiar with object-oriented concepts like classes and objects. The building blocks of web development also include knowledge of HTML, CSS, some JavaScript, and how databases/SQL work together.

You don't need to be an expert in Python or web development to start. The best way to learn is to have a project in mind and then learn as you go rather than trying to understand all these concepts abstractly without actually building something.

Django Architecture

Django follows a variant of the Model-View-Controller (MVC) architecture called the Model-View-Template (MVT) pattern that emphasizes separation of concerns:

Models are the data structure layer that represents the database schema
Views are the business logic layer that receives a web request and returns a web response
Templates are the presentation layer that displays information to the user

All websites follow a client/server model where HTTP requests are sent from the web browser, processed by the website, and an HTTP request is returned. In Django, that sequence looks as follows:

A user makes an HTTP Request, for example.com
A URLs processes it and assigns the correct View
The View combines a Template and data from a Model/Database to create an HTTP Response
The HTTP Response is returned to the user

Under-the-hood things are slightly more complicated than that, but the general flow remains the same.

An image of the request/response cycle is as follows:

Django Project Structure

Django doesn't force you to build web applications in a particular way. Still, there is a default structure that applies to most websites: a single Project has multiple Apps, each containing discrete functionality.

Django Project
    -> App 1
    -> App 2
    -> App 3
    ...
    -> App X

Django ships with several built-in apps such as admin, auth, sessions, messages, staticfiles, and more containing its "batteries." If you were to create a new Newspaper website with articles, you might make an articles app with that functionality. If you added payments later on, that would reside in a separate payments app. This structure helps developers reason about the code and means that even large Django codebases are relatively similar in structure.

Models

Django's ORM (Object-Relational Mapper) means developers can define data models in Python and query them via a dynamic API, but you can still write SQL if needed. For example, this model defines an Article table in a newspaper app that contains three fields: title, content, and pub_date.

# models.py
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    pub_date = models.DateTimeField(auto_now_add=True)

The title field is a character field (CharField) with a maximum length of 100 characters; the content field is a text field (TextField) that can store any amount of text; and the pub_date field is a date-time field (DateTimeField) that stores a timestamp of when the article was published.

Django provides support for many different field types as well as field options such as null, blank, primary_key, and unique.

Once you've created your data models, Django provides a database-abstraction API to create, retrieve, update, and delete objects.

URLs

A clean and elegant URL schema is essential for any high-quality web application. Django encourages beautiful URL design by creating a Python module called a URLconf. Similar to a table of contents for your app, it features precise mapping between URL patterns and your views.

# urls.py
from django.urls import path

from .views import HomePageView, ArticleListView, ArticleDetailView

urlpatterns = [
    path("", HomePageView.as_view(), name="homepage"),
    path("articles/", ArticleListView.as_view(), name="article-list"),
    path("articles/<int:pk>", ArticleDetailView.as_view(), name="article-detail"),
]

In this example, three views are imported for a home page, an article list page, and an article detail page. Then, we define three paths that can define thousands or even millions of different webpages of articles.

Views

Views are the business logic layer that receives web requests and returns web responses. In Django, you can write your own function-based views, class-based views, or take advantage of class-based generic views to handle common use cases such as displaying a template, a list of items, or a detail view of a single item.

# views.py
from django.views.generic import TemplateView, ListView, DetailView
from .models import Article

class HomePageView(TemplateView):
    template_name = "home.html"

class ArticleListView(ListView):
    model = Article
    template_name = "article_list.html"

class ArticleDetailView(DetailView):
    model = Article
    template_name = "article_detail.html"

This snippet is all the code we need to use built-in views to display a template called home.html, list all articles in a template called article_list.html, and display a detail view of a single article in article_detail.html.

Templates

Django's templating engine strikes a balance between power and ease. A template is a text file, typically HTML, that contains variables replaced with values when the template is evaluated and built-in tags and filters that control the logic of the template.

For example, a simple template file that displays all articles in the database would look as follows:

<!-- article_list.html -->
<h1>All Articles</h1>
{% for article in article_list %}
  <div>
    <h2>{{ article.title }} | {{ article.pub_date }}</h2>
    <p>{{ article.content }}</p>
  </div>
{% endfor %}

And a template file to display a single article could look like this:

<!-- article_detail.html -->
<h1>{{ article.title }} {{ article.pub_date }}</h1>
<p>{{ article.content }}</p>

It is possible to swap templating engines to use Jijna if you prefer and it is easy to sprinkle in HTMX as needed.

Projects

If you want to jump in and try Django for yourself, here are several free projects demonstrating how to build web applications with Django.

Courses

If you'd like to become proficient in Django, premium courses cover multiple projects in far richer depth and provide a progressive introduction to Django concepts.

Frequently Asked Questions (FAQs)

Is Django easy to learn?

If you have a basic understanding of Python and web development concepts, yes. Django is written in Python and comes with many batteries included to make it fast to start and deploy websites quickly. As with all web frameworks, you will need some understanding of HTML, CSS, JavaScript, and databases to maximize its features.

What are the differences between Flask and Django?

Flask and Django are Python-based web frameworks but adopt very different approaches. Flask is a lightweight and flexible micro-framework, whereas Django is "batteries-included" and provides an extensive feature set by default. Flask is ideal for projects requiring maximum flexibility, while Django shines for traditional websites that value structure, excellent documentation, and a vibrant ecosystem.

Is Django for the backend or frontend?

Django is primarily used for backend web development: connecting to a database, adding logic, user authentication, creating APIs, URL routing, etc. It has a lightweight templating language for frontend use, but Django can also function as a backend API coupled with a frontend JavaScript framework like React, Vue, or Angular.

What is Django vs. Python?

Python is a general-purpose computer programming language that emphasizes the readability of code, making it popular for both beginners and experienced programmers. It is used in data science, artificial intelligence, automation, and web development. Django is a web framework written in Python that handles common challenges in web development--connecting to a database, authentication, forms, security, URL routing, etc.--so developers don't have to reinvent the wheel.

Is Django a programming language?

No, Django is a web framework for creating applications or APIs written in the Python programming language. There are many common challenges in web development--connecting to a database, user authentication, URL routing, forms, security--and a framework like Django handles them all so a developer can focus on writing code specific to the project rather than reinventing the wheel.

Is Django full-stack or not?

Yes, Django provides all the backend and frontend web development tools, including database connections, URL routing, forms, and templates. It is generally considered a backend framework because developers can also swap in a dedicated JavaScript frontend library like Vue or React.

Should I learn Django before Python?

You should start with Python since Django is a Python-based web framework. Everything in Django is just Python. You don't need to master Python before attempting Django, but understanding basic syntax, variables, dictionaries, and object-oriented techniques like classes is recommended.

How do I ask a good programming question?

Many beginners need help moving past following a tutorial or course to building their own projects. Whatever functionality you can imagine has already been implemented by others. The trick is finding an example online or asking a good question on a place like the Django Forum. If you need help, try to be as specific as possible and make clear you have put in effort already. So, instead of saying, please help me build a blog!, you could say, I've already implemented authentication and models, but I'm stuck on a view displaying all posts, and here is the code I'm trying to use that I know is incorrect. A more experienced developer can quickly look at the code and make suggestions.

Flask vs Django in 2024: A Comprehensive Comparison of Python Web Frameworks

Will Vincent — Thu, 29 Aug 2024 02:06:00 +0000

Flask and Django are the two leading Python web frameworks and while they both help developers build websites quickly, they do so with vastly different approaches. In this article, we will look at what each framework does, how they work, and why developers choose one over the other. To demonstrate these differences we will build out three distinct projects from scratch—Hello World app, Personal website, and a To Do project—so you can see for yourself how they work and make the best decision for your needs.

What's a Web Framework?

Database-driven websites have remarkably similar needs: URL routing, logic, connect to a database, render HTML templates, user authentication, and so on. In the early days of the World Wide Web, developers had to construct all these pieces themselves before they even started work on the website itself.

Open-source web frameworks soon emerged that allowed groups of developers to collaborate on this challenge, sharing best practices, reviewing code, and generally not reinventing the wheel every time someone wanted to build a new website. There are web frameworks in every major programming language with notable examples including Ruby on Rails written in Ruby, Laravel written in PHP, Spring written in Java, and in Python the two frameworks we cover here: Flask and Django.

If you're new to programming, it might be confusing to hear the term Python "framework" vs "library." Both refer to software but the difference is complexity: a library is focused on a specific problem, while a framework tackles a larger challenge and often incorporates many smaller libraries to do so. As we'll see, both Flask and Django rely on quite a few Python libraries.

Which is More Popular?

If we look at GitHub stars, Flask and Django are relatively neck and neck but we can see the explosive growth of FastAPI, which is now clearly established in the top 3 of Python web frameworks.

The 2023 Python Developers Survey shows Django just ahead of Flask in 2023 but with FastAPI also gaining momentum.

Stack Overflow's 2023 survey of developers across all programming languages Flask slightly ahead but followed almost immediately by Django and with FastAPI a little behind.

These comparisons are interesting to view for trends but don't account for many things. For example, just because a web framework is popular, does that mean that real companies and professional developers are using it, or is it just something that beginners like to play around with?

Regardless of the comparison metric, it is clear Flask and Django are currently the top two Python web frameworks.

Jobs

If you're looking for a job as a Python web developer, Django is the better choice. There are almost twice as many listings for Django developers as for Flask on major job boards such as Indeed.com.

However, this disparity is likely because Django is a much more specific choice than Flask. A startup or company can run almost all of their services just on Django whereas Flask is often used alongside other technologies given its lightweight footprint.

The most employable approach is to truly master Python first and then add web development knowledge with either Django or Flask (ideally both!) on top.

Community

Django has the larger, more organized community of the two. There are over 1,800 committers to the Django codebase vs around 550 for Flask. On StackOverflow there are ~212,500 Django questions compared to ~31,500 Flask questions.

Django also has annual conferences in the United States, Europe, and Australia. Flask does not have a similar level of conferences, although there are active discussions for both frameworks at PyCon events.

What is Flask?

Flask is a micro-framework that is intentionally minimal and flexible by design, which clearly doesn't limit its utility. As we will see, this design decision comes with both strengths and weaknesses.

Flask started out as an April Fool's joke in 2010 by Armin Ronacher and was inspired by the Sinatra Ruby framework. FLask was meant to be simple enough to fit in a single Python file and, despite its humorous origins, Flask quickly gained popularity due to its simplicity and flexibility.

Flask itself has a quite small codebase and relies heavily on two major dependencies: Werkzeug and Jinja, both of which were initially created by Armin Ronacher.

Werkzeug is a WSGI (Web Server Gateway Interface) toolkit that provides the core functionality for Flask. It handles HTTP requests, and responses, a URL routing system, a built-in development server, interactive debugger, test client, and middleware. Jinja is a templating engine used to generate dynamic HTML documents that comes with its own syntax for basic logic, variables, if/else loops, template inheritance, and more.

Although Flask doesn't specify a specific structure, it is often used in a Model-View-Controller (MVC) pattern common to other web frameworks such as Ruby on Rails.

Model: Interacts with the database and handles data logic.
View: Renders HTML templates (usually) with data for the user.
Controller: Processes user input, interacts with the Model, and selects the View to render.

Flask's micro-framework architecture means it performs a few tasks extremely well and relies on third-party libraries (and the developer) to implement the rest. This approach is well-suited to smaller web applications that don't require all the bells and whistles built into Django. On the other extreme, experienced programmers who demand complete control over their application often prefer Flask, though this means making more design decisions than they would with a full framework like Django.

What is Django?

Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. It was created in at the Lawrence Journal-World newspaper and publicly released in 2005. "High-level" means that Django is designed to minimize the actual coding required during the web application process by providing built-in "batteries" for most use cases, including an ORM (Object-Relational Mapper), URL routing, template engine, form handling, authentication system, admin interface, and robust security features. In Flask, the developer must choose and implement these various features but with Django they are included out-of-the-box.

Django is managed by the non-profit Django Software Foundation and has a large and dedicated community behind it working on new releases, extensive documentation, active online communities, and regular community-run conferences.

Django follows a variant of the MVC architecture called the Model-View-Template (MVT) pattern that emphasizes separation of concerns:

Model: Handles data and business logic, including methods to interact with the data
View: Handles business logic and interacts with the Model and Template. It also processes user requests.
Templates: Render the user interface, usually as HTML using the Django templating language

A fourth component, URLs, is also included and used to handle URL routing, matching a user request to a specific View that then generates a response.

Flask: Hello, World

Python should already be installed on your computer so all we need to do is create a virtual environment and install Flask.

# Windows
$ python -m venv .venv
$ .venv\Scripts\Activate.ps1
(.venv) $ python -m pip install flask

# macOS/Linux
$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv) $ python -m pip install flask

With your text editor, create a new file called hello.py. Flask famously requires only five lines for a Hello World web page.

# app.py
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    return "<p>Hello, World!</p>"

This code imports the Flask class at the top and creates an instance called app on the next line. The route() decorator tells Flask what URL should trigger the function; here it is set to the homepage at /. Then the function, hello_world, returns an HTML string between paragraph <p> tags with our message.

To run the code, use the flask run command.

(.venv)
$ flask run
 * Debug mode: off
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:5000
Press CTRL+C to quit

If you navigate to 127.0.0.1:5000 in your web browser the message is visible. Flask uses port 5000 by default.

This is about as simple as can be and speaks to both Flask's roots as an attempt at a single-file way to create a web application and also an example of its inherent flexibility.

Django: Hello, World

The Django docs don't provide a similar quickstart guide but we can accomplish a similar feat with only a few more lines of code. In fact, doing so has become a bit of a game among seasoned Django developers and there is an entire repo, django-microframework, dedicated to these efforts. We will choose Option2, which is not the most concise, but is more easily understood than some of the other approaches.

Navigate to a new directory, perhaps called django on your Desktop, and create a virtual environment containing Django.

# Windows
> cd onedrive\desktop\code
> mkdir django
> cd django
> python -m venv .venv
> .venv\Scripts\Activate.ps1
(.venv) > python -m pip install django

# macOS
% cd ~/desktop/code
% mkdir django
% cd django
% python3 -m venv .venv
% source .venv/bin/activate
(.venv) % python3 -m pip install django

In your text editor create a hello_django.py file with the following code:

# hello_django.py
from django.conf import settings
from django.core.handlers.wsgi import WSGIHandler
from django.core.management import execute_from_command_line
from django.http import HttpResponse
from django.urls import path

settings.configure(
    ROOT_URLCONF=__name__,
    DEBUG=True,
)


def hello_world(request):
    return HttpResponse("Hello, Django!")


urlpatterns = [path("", hello_world)]

application = WSGIHandler()

if __name__ == "__main__":
    execute_from_command_line()

Django is designed for larger web application and typically relies on a global settings.py file for many configurations, however we can import what we need in a single file. The key points of reference are the hello_world function that returns the string, "Hello, Django!" and the urlpatterns defining our URL routes, namely at "", meaning the empty string, so the homepage.

Start up Django's built-in server using the runserver command

(.venv) > python hello_django.py runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
July 17, 2024 - 13:48:54
Django version 5.0, using settings None
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Navigate to Django's standard port of 8000, http://127.0.0.1:8000/, to see the "Hello, Django!" message.

Django required tweleve lines of code rather than Flask's five, but both these examples are intended as quickstart guides; they are not how you structure a real-world Flask or Django app.

Flask Personal Website

Now let's build a Personal Website with a home page and an about page. This will give a chance to introduce templates and repeat some of the patterns we saw around how routes are defined in Flask.

Update the app.py file as follows:

from flask import Flask, render_template

app = Flask(__name__)

@app.route('/')
def home():
    return render_template('home.html')

@app.route('/about')
def about():
    return render_template('about.html')

if __name__ == '__main__':
    app.run(debug=True)

Both the home and about View functions now return a template. We're also using the route() decorator again to define the URL path for each. We've also added debug=True at the bottom so that the development server runs now in debug mode.

The next step is creating our two templates. Flask will look for template files in a templates directory so create that now.

(.venv) $ mkdir templates

Within it add the two files with the following code:

Create templates in templates/:

<!-- templates/home.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Personal Website</title>
</head>
<body>
    <h1>Welcome to My Website</h1>
    <a href="{{ url_for('about') }}">About Me</a>
</body>
</html>

<!-- templates/about.html -->
<!DOCTYPE html>
<html>
<head>
    <title>About Me</title>
</head>
<body>
    <h1>About Me</h1>
    <p>This is my personal website.</p>
    <a href="{{ url_for('home') }}">Home</a>
</body>
</html>

Each file use the method url_for to define links based on the view function name.

Run the server again with flask run and navigate to the homepage:

Then click the "About Me" link.

This is a rudimentary example but you can start to see how templates and views interact in Flask. We still have only one main Python file powering the whole thing, but once we have many more pages and start to introduce logic, the single-file approach stops making sense and it's time to start organizing the Flask app in different ways. There are some common patterns used in the Flask community, however, it is ultimately up to the developer.

Django: Personal Website

Django is designed for full-bodied web applications so building a Personal Website is a chance to see this in action. We'll start by creating a project, which is the central hub for our website, using the startproject command.

(.venv) $ django-admin startproject django_project .

We've named the project django_project here. Adding the period, ., means the new folder and files are installed in the current directory. If you don't have the period Django creates a new directory and then adds the project folder and files there.

This is what your directory should look like now. The hello_django.py file remains and can either be left there or removed entirely: we will no longer use it. There is an entirely new django_project folder containing several files and a manage.py file used for running Django commands.

├── django_project
│   ├── __init__.py
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── hello_django.py
└── manage.py

We want to create an app now using thes startapp command which will be called pages. A single Django project typically has multiple apps for different functionality. If we added user registration that code should be in its own app, same for payments, and so on. This is a way to help developers reason better about their code.

(.venv) $ python manage.py startapp pages.

This command creates a pages directory with the following files:

└── pages
    ├── __init__.py
    ├── admin.py
    ├── apps.py
    ├── migrations
    │   └── __init__.py
    ├── models.py
    ├── tests.py
    └── views.py

Our first step is updating the django_project/settings.py file to tell Django about our new app. This is a global settings file for the entire project.

# django_project/settings.py
INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "pages",  # new
]

Second, update the django_project/urls.py file. When a URL request comes in it will hit this file first and then be either processed or redirected to a specific app. In this case, we want to send requests to the pages app. To do this we'll import include and set a new path at "", meaning the homepage. Django defaults to including the URL configuration for the built-in admin, a powerful visual way to interact with your database.

# django_project/urls.py
from django.contrib import admin
from django.urls import path, include  # new

urlpatterns = [
    path("admin/", admin.site.urls),
    path("", include("pages.urls")),  # new
]

Within the pages app we need a view and a URLs file. Let's start with the view at pages/views.py.

# pages/views.py
from django.shortcuts import render


def home(request):
    return render(request, "home.html")


def about(request):
    return render(request, "about.html")

In Django, views receive web requests and return web responses. The request parameter is an object containing metadata about the request from the user. We'll define two function-based views here, home and about, that use the shortcut function render to combine a template with an HttpResponse object sent back to the user. The two templates are home.html and about.html.

For the templates, we can create a templates directory within pages, then another directory with the app name, and finally our template files. This approach removes any concerns about confusing the Django template loader in larger projects.

(.venv) $ mkdir pages/templates
(.venv) $ mkdir pages/templates/pages

Then in your text editor add two new files: pages/templates/pages/home.html and pages/templates/pages/about.html.

<!-- pages/templates/pages/home.html -->
<!DOCTYPE html>
<html>
<head>
    <title>Personal Website</title>
</head>
<body>
    <h1>Welcome to My Website</h1>
    <a href="{% url 'about' %}">About Me</a>
</body>
</html>

<!-- pages/templates/pages/about.html -->
<!DOCTYPE html>
<html>
<head>
    <title>About Me</title>
</head>
<body>
    <h1>About Me</h1>
    <p>This is my personal website.</p>
    <a href="{% url 'home' %}">Home</a>
</body>
</html>

The final step is configuring the URLs for these two pages. To do this, create a urls.py file within the pages app with the following code.

# pages/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path("", views.home, name="home"),
    path("about/", views.about, name="about"),
]

At the top we import our views and then set a URL path for each. The syntax is defining the URL path, the view name, and optionally adding a URL name that allows us to link to each path in our templates.

Start up the Django local server with the runserver command.

(.venv) $ python manage.py runserver

You can see the homepage:

Click the "About Me" to be redirected to the about page:

As you can see Django required more scaffolding than Flask, however this approach provides a consistent structure that is quite scaleable.

Detailed Comparison

The true comparison of these web frameworks depends on your project's needs. Are you building a traditional web application that connects to a database, requires CRUD (Create-Read-Update-Delete) functionality, and user authentication? If yes, Django has built-in solutions for all of these needs. By comparison, Flask requires installing multiple third-party libraries: Flask-SQLAlchemy to connect to the database, Flask-Migrate to manage database migrations, Flask-WTF and WTForms for forms, Flask-Login for user authentication, FLask-Mail for email support, Flask-Security for security features, Flask-Admin for an admin interface to manage application data, Flask-Caching for caching support, Flask-BCrypt for password hashing and so on.

The power of Django is that you don't have to worry about any of these things. They are included, tested, and supported by the community. For Flask, the third-party libraries are not as tightly integrated and require more manual installation by the developer. This affords greater flexibility but also requires more programmer expertise.

Conclusion

Ultimately, you can't go wrong choosing Flask or Django for your web application needs. They both are mature, scaleable, and well-documented. This difference is in approach and the best way to determine what you prefer is to try each out by building more complex projects.

If you're interested in learning more about Django, check out Django for Beginners for a guide to building six progressively more complex web applications including testing and deployment. For Flask, the Flask Mega-Tutorial has a free online version. There are also two courses over at TestDriven.io worth recommending: TDD with Python, Flask and Docker and Authentication with Flask, React, and Docker. If you prefer video, there are many Flask courses on Udemy but the best video course I've seen is Build a SaaS App with Flask and Docker.