JetBrains Django-Developer Survey Results explained

Opinionated view

Handmade Software
Published in
8 min readJan 21, 2022


JetBrains releases developer surveys for various technologies, and this year is not an exception. The results reflect the trends and changes in the community and help us better understand what will be relevant tomorrow and what not.

Looking for some Python or JS freelance gig, rates up to 50 €/hour? Please don’t hesitate to contact me on Twitter or Linkedin with your CV, availability and hourly rate. (CET +/- 3 hours).


Changes to the Django’s governing model have paid out, and the fresh wind after decades of PRs blocking and favoritism is clearly to feel. Semantic versioning pushes folks to upgrade more quickly because the delta of the major version is not that big as it used to be, therefore the pain of updating is much lower.


PyUnit has always felt out of the place in the python universe, and no wonder pytest is taking over, the domain seemed to be solely taken by that ancient JUnit descendant. Pytest is a modern, modular and in general outstanding tool for testing any applications, and in fact pytest-django has never given troubles to me so far. Glad to see it in the first place.


Django’s way to async wasn’t exactly the straight one. The obvious milestone for a sync framework — making Django ORM — completely async will take a while to be developed to the stable state and adapted by the community.

ASGI, the async version of WSGI so well known to the Django devs, is just a first step there: of course there is no async-able framework without async application server. But still Django and async? Nope.

Django community is quite senior, and with seniority, the openness to new technologies drops. Python version usage proves that too.

Python versions

3–4 years ago this picture wasn’t that optimistic. I, personally, did not believe Python will make through to 3x, as all the major frameworks and technologies struggled with the switch. At the end it wasn’t that hard IMHO and I was proven wrong.

Python2 senior devs fail to understand that their work is threatened by this change and will very likely end up on the technological graveyard. The tremendous amount of code associated with PyPY or Cython seems to be an unbearable amount of work to be done. Being a total pessimist, I don’t think they all will make it.


Although comparably young, VS Code has occupied the dev community so quickly and the fact it is actually developed by whom? Microsoft! The most hated company in the open-source community is now used more by Django developers than PyCharm, that seemed to be indisputable leader in the branch. That said, looks like all products have their lifetime cycle and just need to be rebooted. What is VS Code if not the open source capable comeback of, let me clear my throat, Visual Studio.

The shortcomings of JetBrains in the last years, dropping performance of their main Java-based platform IDEA and their particular shift of focus to their own cloud-based development environment and cloud native IDE, bugs not being addressed in years: all of that made people seeking an alternative. And there was one!

VS Code, although based on Electron, and therefore cannot be even close to deliver the performance of native apps, served well to the so often globally unnoticed group of users: Linux communists, one of which I gladly am.

Linux plays a big role in the backend world, and Microsoft understood that. Although JetBrains has even created their own JVM, to liquidate the performance issues and bugs both OpenJDK (OMG) and proprietary Oracle JVM have and fail to fix for decades. The big comeback of Microsoft since Satya Nadella headed the company, Microsoft turned to Linux and open-source community and delivered astonishing products, that were so unimaginable for Microsoft of beginning of 2010s. AzureDevops developed in silence turned out to quite a neat tool, covering all the needs of a cloud developer in 2022, VS Code ruling the geek’s laptop and OMFG WSL — Linux Subsystem for Windows. If any executive in Microsoft had said something even close to this in 2012–13, their career would be over. Officially.

Linting & Quality

One more unexpected newcomer domination! Black’s first release on PyPI is from March 14, 2018, and since then, this formatting and linting tool has been a good competition to all other well established tools like flake8, PyUnit, autopep8 and similar. Here I’m not particularly agree with the classification of JetBrains, as I don’t really see the big difference between linting and code formatting. Mathematically speakings, it’s the same.

Only 14% for MyPy in the Django Community

MyPy so celebrated and being particularly modern and a well combined with such remarkable libraries and frameworks like FastAPI and pydantic, putting their focus on type annotations, has no real place in Django. Magic happening around the ORM and inevitable circular imports just create an endless hustle. Django developers are conservative and as there is no real additional value noticeable from typing in Django, most developers just decide not to adapt it.

Pylint’s performance issues and a huge amount of false positives, that make this tool hard to use in practice, were the actual reason flake8 has won the battle so long.

Interesting comparison in this survey: Pylint loses its community in the junior and senior groups, but is used kind of the same by the mids. I can confirm I also had my “pylint-phase”, where I wanted everything to be perfect and well: the best is the worst to the good. Pylint created more trouble than value.

In the non-Django Python world, type annotations allow catching the type mistakes in the first place, where MyPy is a strong tool to enforce correct typing, especially with pre-commit.


AWS in the first place, no big surprise here. Heroku in the second with its amazing toolkit for startup projects and suffering a bit from the legacy resulting from it’s pioneering in the early 2010s. Surprisingly low result for AzureDevops, is it just still mistrusted because it’s Microsoft? Time will show.

49% for container is a logical result: since Docker and microservices have revolutionized deployment, developers want to spend less time caring about how their code is delivered to the user. 9% for serverless, meaning a fortune AWS Lambda costs, is already an excellent result.

37% for virtual machines though seems illogical in this picture, but again it's due to the age of the Django community. The older people get, the less is their will to innovate, and it shows. Django devs in their 40s-50s prefer their hands on the things happening in their applications, even sometimes prefer the quick fix on production of a good old ssh session.

As wild as it seems in the modern imperative of vast parallelism and abstractly elastic and unlimited infrastructure, Django developers still tend to remain in the past. Besides that, performance degradation and cost of migration to a container environment seems to be a big factor in their decision, although it’s no secret that in the middle-sized applications I/O is the biggest issue slowing down the applications. In fact, lambda would be a perfect choice for a synchronous framework like Django, where worker pool exhaustion is a real problem which any Django developer has experience at least once. 502 Bad Gateway.

This is a remarkable result: don’t use containers for development. I’ve seen developers not even using volumes and rebuilding their Docker images for any change they make, waiting 50–70 seconds for every line they change. Just imagine how unproductive they get. Containers are for the CI and prod.


Rise of GitHub Actions is absolutely justified. Most of the direct competitors are implementing the same concept, while, although the community feared that GitHub after acquisition by Microsoft will degrade to stage of disability similar to Skype, GitHub actions is truly fresh approach in the world of CI. Public repositories with pluggable actions and base images speeding up the regular tasks, a new word in a tale where everything seemed to be told already. When used correctly, GitHub actions address the biggest problem of containerized CI: performance.

Test a matrix with a matrix of tens of jobs done under 2 minutes, easy

Jenkins a good old friend with 12% again can be explained by the vast conservatism in the Django community, this comes along with virtual machines and Ansible for provisioning.

I’m not judging, but Jenkins is a tool from the pre-pre-prelast generation of technologies and has no place in the modern technological landscape in 2022. Self-managed GitLab beats Jenkins on all criteria.


What was really a pleasant thing to find out is that senior developers, using primarily other languages, have switched to Python, which reflects in the middle 3–5 years group on the second chart. 2to3 catastrophe solved, amazing data science tools, new asyncio based technologies and frameworks, a well-deserved Python place 1 in TIOBE Index attracted developers and created a necessary momentum for Python to come back and spawn even more outstanding technologies in the future.

It was an excellent year for Python, and the best is yet to come!


If you liked this, check out my recent articles:

🕒 Why your software quality degrades with time: short story

😃 RapidAPI: first steps with Python

🐍6 Important Programming Languages and Their Original Purpose