I love Django management commands.
For dpaste.com I’ve written several management commands for things that I don’t need a web UI for, like:
expire - delete expired pastes (invoked by cron) expunge - manage TOS violations like spam stats - useful metrics on the current corpus of pastes, and on user activity In running the site I also use management commands from my django-blocklist app, for tasks like deleting expired entries (via cron) or generating reports.
Python 3.8 (2019) added “assignment expressions”, aka the “walrus operator”.
I generally like things that make Python more expression-oriented, like list comprehensions, but I’m ambivalent about these. It’s pretty easy to impair readability by using them overzealously. Is saving one line of code worth making it harder to notice that an assignment is happening?
However, I’ve found a use case I like a lot. I use them in the Django Python shell when doing exploratory ORM queries.
I enjoy writing tests because I love what they give me.
I love knowing that I’m adding defense against breakage from future changes. I love thinking through how a feature is really supposed to work, and having the test capture that understanding. I love thinking about edge cases that the code should handle, and writing tests for them — especially if it turns out that the code under test didn’t yet handle them correctly, because that means I’ve just saved us from a bug.
I can be kind of a stickler about leveraging the ticket/issue tracker in software projects (which always seems to be Jira these days, but nevermind that). I write tickets carefully; I link to related issues; I add comments to note the status of work in progress, or to record info that’s important to the work to be done.
I’ve been a full-time remote worker since 2010.
The COVID-19 pandemic has brought big changes to things involving face-to-face contact – like going to an office for work. Since this sea change has gotten more engineers (and employers) to think about remote work, I thought I’d share some tips on how to find and keep remote gigs.
This was written with junior-level engineers in mind, and is more about full-time employment than freelancing.
A couple weeks ago I accidentally replaced our live, production database with a 17-hour old snapshot.
I had intended to target a test server, not production. I didn’t realize what I had done for an hour or so, and by that time I had already left work. (I was actually out walking my dog. Not a good setting for managing a production crisis.)
Here’s how my team and I handled it.
Non-engineers want to know: what happens when a big bug is found in your software, and the bug is causing real users real problems, and you’re the one who wrote the code?
Engineers do sometimes write bad code, and sometimes it makes it into production, it’s true.
But shipping production software involves a lot more than writing code. It goes beyond that one engineer. That engineer is not the only person who saw or ran that code.
