New Motto: Perfect is the Enemy of Good


“Python Environment” (

My week-three lesson turned out to be “never be afraid to change your mind.”

To recap: After overzealous research on a Friday into the “perfect” tools 🙄 to build my next-bug application, I decided to use a MEVN stack. However, upon sitting down at my desk the following Monday and firing up MDN Web Docs (which are awesome → well-written documentation = more access to tech), I reconsidered. When I started reading up on server-side programming, I knew I could probably start up in Node.js without much trouble — I’ve worked with it before and have the basics down. But then I saw that there were two options covered in the tutorial: Node/Express and Python/Django, and I began to have second thoughts that began with: Oh, crap … not Express.

This was unfair of me, and I couldn’t have made a terribly cogent case to support my  antipathy (which is, incidentally, a common feature of fervent nerd creeds) because it really had more to do with loathing the Jade template engine*, which is certainly not the only option✿. But the more I thought about it, the less using Node seemed to make sense. The dashboard I’d be building in the coming weeks would ideally run on the already existing framework other team members had recently set up, and that framework being a Python/Flask backend with a React + Redux frontend … what good was plodding through Express (again)? (Hmm … I keep meaning to learn more Python, and … ooh, Django was written by developers in the web department of a Lawrence, Kansas, newspaper? Cool, I’m in✤!)


Thus, the new plan became: Build the app with Python, Django, and vanilla JavaScript (with possibly some jQuery if necessary). This turned out to be a good decision. Not only did I learn the basics of an entirely new framework and get some Python practice, but the whole process of going through an alternative server-side setup and basically starting over from scratch:

  • installing a second Python (current Django pushes Python3) and all the virtual environment noodling that entails (pip vs pipenv, virtualenv vs venv, etc.)
  • learning a new template engine
  • being pleasantly surprised to find that Django defaults to SQLite

… reinforced the overall model/view/controller web development concepts in my head and made the myriad procedural and syntactical differences seem less intimidating. It’s not that I’ve gotten to any level I’d remotely consider mastery, but more that the vast universe of terminology has some recognizable categories to it now, which makes it (a little) less intimidating. I remember hearing the term “package manager” for the first time when I was trying to set up my first open source project and being incredibly anxious about that fact that I had absolutely zero idea what that meant. Since then I’ve successfully used homebrew, pip, rvm, nvm npm, and yarn — now a package manager is just another type of tool in the crowd.

There’s a frenzied conviction online about the magical and terrifyingly important “best way” to do any given project. Given all the never-ending options available, this “best way” changes with new technologies, new workplaces, Medium ranking algorithms, and from one region or person to another, and trying to figure out the current one for X situation is a gigantic waste of energy. The “best way” is a myth, and I’ve finally started to realize that it’s a dangerous goal for someone like me, early in their career. Believing in some perfect set of tools, libraries, or frameworks is a time suck that delays new ideas and different voices from finding outlet on the web. Pick some stuff and get started already!


This lesson learned (not for the first time, nor, I fear, the last), I tried to do that.

I spent a day following the Django tutorial to start off. After that, I was able refer back to the completed project model to reconfigure the next-bug app. This was mostly successful, although in trying to show different ways of doing things in the name of efficiency or preference, the tutorial has you change things a few times, so I couldn’t always remember what the simpler version had been and had to re-reference the documentation.

For someone with limited experience, Django was a great re-introduction to the server side. I found its weird extra-directory file system confusing to use for such a simple app, but I really appreciated the default decisions made that allowed me to concentrate mostly on the big picture and basic functionality. Between the SQLite database default and the built-in generic views, to my mind it was actually vaguely reminiscent of Android. For the design, I adapted a simple W3Schools template to use Webcompat’s yellow and font, which resulted in a frightfully boring CSS headache that I ultimately resolved (and the details of which I will spare you).

Because I’d decided to name the app Next Bug Oracle, I also wasted a couple of hours trying to find open source images for “Delphic oracle” online. This turned out (to no sane person’s surprise) to be a non-starter. I did stumble across the following image, though, which came from — and I’m not making this up — an “article” about the best Greek goddess names for your dog:


The app is live now (\o/), at least Heroku-live, and while it’s still a work in progress☞, I was able to demo it for my team at Mozilla’s AllHands meeting last week, which was pretty satisfying despite there being precious little show-and-tell to squeeze out of an app with a single button 🧐.

🤓 links:

* Jade (now Pug) is, in all seriousness, the worst thing ever. Why anyone ever thought a system of super-sensitive indenting that will not load any of your content when ONE CHARACTER IS OFF BY ONE MEASLY SPACE was somehow easier to deal with than a few annoying-to-type tags, which, ahem, can be chock full of mismatches, danglers, and all manner of disgusting sloppiness and still work:

“Tags” (

… I will never understand.

Apparently, there are several different template engines — including a Mozilla project, Nunjucks — that will work with Express (although my favorite part of that article is the end where React thrown into the mix and described as a newfangled library with a “ton of buzz”… oh, the difference <4 years makes).

Raised by proud Midwesterners, one of whom got his doctorate from the University of Kansas (go Jayhawks).

For one thing, there’s no reason to have an entire second page for the results — the content should just update dynamically, and for another, some sort of system (whether by login or a persisting already-claimed-bug database) to prevent giving to same bug to multiple people will be necessary.