Developers are often itching to try out the latest shiny tech on problems they’ve been asked to solve, even when there are perfectly good existing solutions they could adopt instead.
Need some help desk software? Sure we could use Zendesk. But if we rewrote it in HTXM and FastAPI, we could do MUCH better and it’d be custom-built for our use case. Think of all the integrations.
Adding silently: And I get to use HTMX!
This is often called Not Invented Here syndrome and is strongly cautioned against:
NIH: The belief that in-house developments are inherently better suited, more secure, more controlled, quicker to develop, and incur lower overall cost (including maintenance cost) than using existing implementations.
Just look at PyPI for packages to access PostgreSQL, there are 2,348 results! Yet, there have to be multiple projects connecting Python and Postgres in development right now.
But sometimes, you should build it here
I’m starting to think the advice to avoid NIH syndrome at all costs is not always good advice.
Looking back on the last 7 years at Talk Python, there have been plenty of times we could have slotted into someone else’s ecosystem but benefited from building parts of our tech ourselves. This is true both as a business and for me personally.
Here are just some of the ways embracing a NIH tendency has benefited us.
1. It’s made Talk Python a better service for everyone
Very polished platforms for listeners and advertisers
Controlling our platform means we don’t have to slot into someone else’s poor design and slow web apps.
Consider one of the more popular podcast hosts (think WordPress but for podcasters) and how great of an impression you get from visiting their content.
Does this page below draw you in and entice you to listen? I would think absolutely not.
Contrast that with Talk Python’s episode pages:
You may not totally love the design. But it’s certainly something I can be proud of.
The same goes for taking courses at Talk Python. Here’s the clean and fast view of taking a course:
We could have decided to publish our courses on other platforms like LinkedIn Learning. In fact, we have tried a few syndication deals. They were basically failures from a business perspective. So, I’m happy we built our course platform ourselves.
Integrations abound
Do you have amazing ideas of leverging some aspect of your org for another? Taking someone else’s product/platform might mean that’s not an option.
Here’s an example.
We stream all our podcast events with a live audience on YouTube. That’s lots of fun and a cool experience for our listeners:
But because we control the platform, we can push a single button on our Stream Deck, that:
- Announces the live stream on Twitter
- Announces the live stream on Mastodon
- Puts the website into live stream mode encouraging people to be part of the audience
But it goes further. Once the live stream is done, the platform takes the thumbnail we’ve carefully crafted for our YouTube video and make visible on the episode page.
After that, the website automatically pulls that image and uses it for our social share in Twitter, Mastodon, and others:
That’s Stream Deck > YouTube > talkpython.fm Live Mode > talkpython.fm episode page > social share.
All of that is fully automated. How is this possible? We built it ourselves.
Advertiser dashboards
The other side of the podcast story wins too. Podcast advertisers get a full dashboard with per second reporting of traffic to their sponsored episodes and the number of visitors to their sponsored links.
We can do this with zero tracking forced upon our listeners, unlike most platforms.
2. I gain experience writing real code
As someone who talks a lot about writing code and teaches a lot about writing code, it’s important to remain connected to actually writing code. Creating our platforms means I get daily experience working on high-end Python software in production.
- We do around 20 TB and millions of requests of traffic monthly
- I evolve the software from older code to newer code (like MongoEngine to Beanie & Pydantic or integrating FastAPI)
- I manage this platform on 8 coordinating servers as well as across CDNs and integrating with other platforms (like iTunes catalogs)
This means when I sit down to speak with guests or write a course, I often have very real world experience to draw from. Because I built it myself.
3. It is a lot of fun
Finally, writing this code and growing as a developer is just tons of fun.
4. But also a counterpoint
That doesn’t mean I don’t sometimes choose to NOT build it ourselves.
Our credit card sales are handled by Paddle. This site is creating using the static site generator Hugo. Neither of these was built here and I’m very happy to not work on them.
So when it makes sense consider building it yourself but just not for everything.