It is easy to cling to the familiar to avoid the unknown – even when unfamiliar approaches better serve your work. My talk explores this fact, specifically, by looking at the technical and emotional dimensions of my less-than-easy journey from writing raw SQL to using the Django ORM.
Reconciling old assumptions with new approaches can be difficult. This reconciliation can be especially difficult, when those assumptions and approaches correspond with one’s emerging professional identity. A musicologist turned developer, a Rubyist turned Pythonist, I know well how intrapersonal tensions can shape (or hinder) approaches to writing code. This talk confronts these tensions by describing the technical and emotional dimensions of my less-than-easy journey from SQL to the Django ORM.
Django supports two basic approaches to interacting with a database: (1) running queries with the Django database-mapper (more commonly described as the “ORM”), and (2) performing raw SQL. My first Django projects display a strong preference for the latter approach. I came to Django with very limited coding experience. I started my job at a Python shop as a freshly minted grad of Dev Bootcamp, where I had acquired some knowledge of Ruby on Rails and its ORM, but also learned about the possibilities and easeful-ness of SQL. I eschewed the Django ORM, in part because of its seeming unknowableness, but mainly because SQL was a familiar face in an unfamiliar land. In Django, I wrote SQL for simple queries (selecting with a WHERE clause), moderately challenging ones (joining multiple tables + ordering with CASE expressions), and obscenely complex ones (subqueries + aggregate functions + string manipulations). Whatever case, I generally found my queries to be transparent, flexible, and friendly.
It took over a year for me to appreciate that the Django ORM does clever and astonishing things. I eventually found joy in annotating querysets with derived values, and I stood in awe of the Prefetch object in elaborate prefetch operations. The ORM, I learned, could produce clean code and also bypass the performance loss that comes with transforming SQL results into more amenable data types (e.g., namedtuple).
In this talk, I will share some lessons in Django. But also, I will suggest strategies for evaluating solid, familiar approaches and replacing them with alternative ones.
