Dashdoc is a fast-growing transport management platform for the road freight transportation industry.
We're hiring a Lead Software Engineer to work on our Invoicing domain. Small 3-person (including you) team, great impact on tens of thousands of people using the tool all day everyday, great colleagues, international context, access to good tools (Cursor, Claude Code).
It doesn't matter. Office suites are a commodity. Google suite is knockoff of MS Office at certain point in time. That's just the nature of digital - information want's to be free.
It's network effects / lock-in. There is a reason why people still use Microsoft Office and that is that surprising amount of industries have everything build around it. In my country anything law related is submitted in Microsoft Word. Academic texts? Microsoft Word. Communication with government? Microsoft Word.
The reason why Google Docs somewhat managed to break this was 1. free, 2. multiplayer/easy to share.
One law about requiring the state documents to be submitted in open formats, editable in libre software... and the lock instantly breaks.
I don't understand why pytest's collection is so slow.
On our test suite (big django app) it takes about 15s to collect tests. So much that we added a util using ripgrep to find the file and pass it as an argument to pytest when using `pytest -k <testname>`.
From my experience speeding up pytests with Django:
- Creating and migrating the test DB is slow. There is no shame in storing and committing a premigrated sqlite test DB generated upon release, it's often small in size and will save time for everyone.
- Stash your old migrations that nobody use anymore.
- Use python -X importtime and paste the result in an online viewer. Sometimes moving heavy imports to functions instead of the global scope will make individual tests slower, but collection will be faster.
- Use pytest-xdist
- Disable transactions / rollback on readonly tests. Ideally you want most of your non-inserting tests to work on the migrated/preloaded features in your sqlite DB.
We can enter into more details if you want, but the pre migrated DB + xdist alone allowed me to speedup tests on a huge project from 30m to 1m.
Agreed, the db migrations are usually the slowest part. Another way to speed this up substantially if you are using postgres and need your test database to be postgres too, is to create and maintain a template database for your tests. This database should have all migrations already run on it and be loaded with whatever general use fixtures you will need. You can then use the Django TEMPLATE setting https://docs.djangoproject.com/en/5.1/ref/settings/#template and Django will clone that database when running your tests.
I've done some work on making pytest faster, and it's mostly a case of death by a thousand paper cuts. I wrote hammett as an experimental benchmark to compare to.
Lest we start to malign the JVM as a whole, my Clojure test suite, which includes functional tests running headless browsers against a full app hitting real Postgres databases, runs end to end in 20s.
The spring tests are generally quicker then the equivalent python test, so ime - the jvm is mostly to blame.
How much time actually goes by after you click "run test" (or run the equivalent cli command) until the test finished running?
Any projects using the jvm I've ever worked on (none of which were clojure, admittedly) have always taken at least 10-15s until the pre-phases were finished and the actual test setup began
If I completely clear all cached packages maybe, but I never do that locally or in CI/CD, and that's true of Python too (but no doubting UV is faster than Maven). Clojure/JVM startup time is less than half a second, obviously that's still infinitely more than Python or a systems language but tolerable to me. First test runs after about 2s? And obviously day to day these things run instantly because they're already loaded in a REPL/IPython. Maybe unfair to compare an interpreted language to a compiled one: building an uberjar would add 10 seconds but I'd never do that during development, which is part of the selling point I guess. Either way, I don't think the JVM startup time is really a massive issue in 2025, and I feel like whatever ecosystem you're in, you can always attack these slow test suites and improve your quality of life.
Dashdoc is a fast-growing transport management platform for the road freight transportation industry.
We're hiring a Lead Software Engineer to work on our Invoicing domain. Small 3-person (including you) team, great impact on tens of thousands of people using the tool all day everyday, great colleagues, international context, access to good tools (Cursor, Claude Code).
https://dashdoc.welcomekit.co/companies/dashdoc/jobs/lead-so...
reply