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.
When we were growing our team of Python devs at CMG, I was involved in a lot of interviews. I really enjoyed it, meeting and hiring interesting and talented engineers.
I’m not a big fan of quizzing people on technical minutiae in interviews. I do think that asking some questions about technical likes and dislikes can be very illuminating though.
For example, “What’s your favorite standard library module?” (My favorite answers are itertools or functools, but anything that shows they have hands-on appreciation for the depth of the standard library is good.)
I’ve been working as a remote software developer for over five years now. I gather that some outfits do this better than others. In case they’re useful/inspirational for anyone else, I want to highlight the key things that have made this workable for so long. The key idea: Treat your remote workers as first-class, full-fledged members of the team.
I move between a couple different computers regularly: my old 12" PowerBook and the 15" MacBook Pro my job provides me with. Like all multi-computer users I periodically bump up against the challenges of what files (and versions) are where, especially when there’s work in progress.
To further complicate things, I also have an extra laptop running Ubuntu. And sometimes I just SSH to my web server from somebody else’s machine.
Among the many anti-spam measures on my mail server – which help me reject 5000 spam attempts per day – is SPF. SPF allows domain name owners to specify which mail servers are allowed to send its mail. That makes it an excellent way to detect address forgeries, a favorite spammer tool.
One of the early questions raised about SPF was: won’t spammers just buy their own domains and set up their own SPF records that say it’s all OK? You can read the answer in the SPF FAQ, but the short version is: Yes, they will, but it won’t give them a free pass.
A significant difference between developing Django sites versus static-HTML-based approaches (among which I count PHP and the like) is that static files, aka “media”, live in a dedicated spot.
Sometimes you need a piece of static content to be available at a specific URL outside your media root. robots.txt for example. This can be done in pure Django (i.e. without even touching your Apache configuration), and is especially nice if your robots.txt content is short. The example below serves a basic “keep out” configuration.
If you use Django’s admin application, you’re familiar with its “Recent Actions” sidebar. It gives a simple summary of your latest edits, including clickable links to the relevant objects (not any ones you deleted, naturally, but ones you added or changed).
It’s probably not something you look at very often, unless you do such intensive work in the admin that you lose track of things.
Django stores that log data (via the admin’s LogEntry model) for all admin users, a fact which has caused me to repeatedly daydream about writing a custom view or two to display it. In other words, I’d like to let superusers browse all object editing history. Because sometimes you need to answer questions like “When was that changed?” and/or “Who changed it?”