| in blog | Better Simple |
|---|---|
| original entry | Send your people to DjangoCon |
This is a 100% biased take. I’m on the DjangoCon US 2023 organizing team and am a member of DEFNA’s board. I also had a fantastic time at DjangoCon US 2022, so much so that I became an organizer and a member of DEFNA’s board. Simply put, I’m all in on Django. That definitely skews my perspective, but you’re here for an opinion.
point over
In all seriousness, I had this discussion with an executive on why we should send our other engineer to DjangoCon US this fall. It comes down to two reasons:
There are other reasons, but these are the two I focused on. Since I was discussing this with an executive, I was pitching based on the benefit to the company.
The first point, re-invigorating software folks seems like it’s focused on the employee. But let’s consider what happens when a person comes back from a conference all energized. An energized employee is a productive employee. An energized employee is more likely to solve those painful bugs or technical hurdles that have plagued the company for the last three years. An energized employee improves at their craft. An energized employee will pull the team forward.
These points all assume that the company isn’t actively demoralizing and draining the employee of their lifeblood. It also assumes that the company is willing to support an employee, try new things and encourage them to push boundaries. As with all things, you can’t expect one thing to fix everything. But, it can go a long way to making things better.
The second point, investing in the company’s infrastructure is less tangible, but immensely important to the company. I’m going to work backwards in this argument.
A maxim I hope we can agree on is that the company wants to limit expenses. For the sake of my argument, let’s assume our company is an established one with a sizable application, 50k lines of code. If Django were to die (no fellow-program, few contributors, no community), the company would be faced with two options.
Switching is always costly. Your employees would need to learn a new skill, eliminating the efficiencies of deep Django knowledge. There would be speed bumps along the way where they learn things the hard way. Alternatively, you could bring in other people with the knowledge in that new framework. Again, this isn’t very cheap. And you may mishire, then misstep when building your new app, leading to more rework in the future.
The alternative is to continue to use the framework. This may work fine for a while, but eventually you’ll run into some difficult problems. Some obvious ones are that the framework will have fewer features, fewer security patches and generally be more difficult to maintain. That argument can be hard to relate to as a non-technical person. A less technical consequence is that a dead framework doesn’t attract employees. As time goes on, it will be more and more difficult to attract employees to work on this project. This gives your existing employees more leverage within your company making salary negotiations and management more difficult. Someone is more likely to be a «insert preferred insult» if they know you can’t fire them.
Alright, that’s enough doom and gloom.
If you want to prevent the above situations from happening, send your people to DjangoCons.
I generally believe most software developers that use open source software want to contribute back to it. They don’t because either they lack time or don’t know where to get started. Thankfully, conferences can help a person with both. Sort of. A conference won’t open up a person’s schedule. But existing contributors are more than happy to share about their experiences. They let people know that it’s okay to limit your involvement (note: there are some alarming sentiments in that thread).
On the getting started front, DjangoCon’s have development sprints which are times when groups of contributors get together to work on a project. Typically, there will be a few tables to getting started with working on Django, but also working on third-party libraries. At DjangoCon US, there were tables for other projects. Some that I remember were django-simple-deploy, BeeWare, and the Django Debug Toolbar (that’s where I was!).
Part of that re-invigoration that comes with a DjangoCon is also directed towards the community. It makes people want to be more involved in the community. Arguably, by attending they are already making themselves a bigger part of the community, so when they return home they are simply readjusting to their new position. Regardless, my point is that a DjangoCon breaths life into the broader Django community.
As I’ve mentioned and talked about on Django Chat with Chaim Kirby, the only way for Django to die is if the community disappears. So if you want to keep Django relevant and avoid tough decisions around a dead framework in the future,