E-Scribe : a programmer’s blog

About Me

PBX I'm Paul Bissex. I build web applications using open source software, especially Django. Started my career In the 1990s doing graphic design for newspapers and magazines. Then I wrote technology commentary and reviews for Wired, Salon.com, Chicago Tribune, and lots of little places you've never heard of. Then I taught photographers how to create good websites. Then I helped a giant media corporation serve 40 million pages a day. Now I work on a small Django team at the largest translation company in the world. Feel free to email me.


I co-wrote "Python Web Development with Django". It was the first book to cover the long-awaited Django 1.0. Published by Addison-Wesley and still in print!


Built using Django, served with gunicorn and nginx. The database is SQLite. Hosted on a FreeBSD VPS at Johncompanies.com. Comment-spam protection by Akismet.

Pile o'Tags

Stuff I Use

bitbucket, Django, Emacs, FreeBSD, Git, jQuery, LaunchBar, Markdown, Mercurial, OS X, Python, Review Board, S3, SQLite, Sublime Text, Ubuntu Linux

Spam Report

At least 235054 pieces of comment spam killed since 2008, mostly via Akismet.

What happens when you screw up?

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.

In short, in a sizable professional software organization a single person doesn't really have the power to screw up all alone. So the right thing to do when a production bug bites you is, figure out how you - as an organization - let that happen.

What "happens to" the engineer who typed the code in question, hopefully, is that he/she participates in a post-mortem review that helps the team figure out how they can improve things to reduce the likelihood of similar problems in the future.

For more on this, read the utterly excellent and inspiring "Blameless PostMortems and a Just Culture" essay by John Allspaw of Etsy.

Friday, April 1st, 2016
+ + +

Good Python Interview Questions

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?" (Best answer in my book here is itertools or functools, but anything that shows they have hands-on appreciation for the depth of the standard library is good.)

I've also asked, "Tell me something you don't like about Python." This can be a great gauge of someone's level of sophistication and breadth of experience. If they say "But I like everything about Python!" that's a red flag (and I say this as a bona fide Python lover and career man). It means they either lack enough breadth of experience to see Python's weak points, or they lack the confidence to answer truthfully.

My favorite answer to this question was, "I don't like that lambda expressions can only be one line." It had never occurred to me to see this as a defect, but now every time I am writing code that drives me to the same feeling, I think about the engineer who gave that answer. (We did hire her and she was great!)

Wednesday, March 23rd, 2016
+ + +

Teaching Non-programmers what Programming is Like

How do you comprehensibly explain to non-programmers the challenges of programming? Why can't you "just tell the computer what you want it to do"?

A classic teaching tool for this is the "make me a peanut butter and jelly sandwich" demo.

Put out on the table a jar of peanut butter, a jar of jelly, a loaf of bread, and a knife. Tell them you are a robot (computer) that is physically capable of making a peanut butter and jelly sandwich, but you need instruction (programming). That's their job.

If they say, "OK, put the peanut butter on the bread"... put the jar of peanut butter on top of the loaf of bread.

And so on.

In your supremely patient robot way, show them that while you make no inferences and have no common sense, you're happy to follow specific instructions.

To get you to spread peanut butter on a slice of bread, they'll learn they have to tell you to...

Getting all the way to the end may be more than is needed (and more than you or they have patience for).

But once they've gotten the idea, you can explain that if they had guided you all the way to a complete sandwich, all the instructions they gave you to achieve that would amount to the first, alpha version of the program. A version which doesn't yet account for things like what to do when you run out of peanut butter or jelly or bread, or what to do if the bread tears...

(Full disclosure: I have not taught this lesson yet myself!)

Saturday, March 5th, 2016
+ + +

Remote workers and how to keep them

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.

Wednesday, January 20th, 2016
+ +

I Remember the Web: altavista.digital.com

First in an occasional series where I show how old I am by reminiscing about the '90s World Wide Web.

Do you remember the Altavista search engine? I don't mean the thing that Yahoo bought and buried. I mean the original 1990s version.

Altavista was an exciting game-changer when it arrived at the end of 1995. Web search had a lot of room for improvement. Altavista's two standout attributes that crushed the competition (e.g. WebCrawler) were its size and its speed.

I recall Digital saying it was partly intended as a demo of the powerful hardware they had dedicated to it. But in any case it was a huge leap in usability.

Then Google came along and added better relevance while also being vast and fast. I didn't find Google to be an obvious Altavista-killer at first, but over time it kept improving substantially while Altavista did not.

Saturday, November 14th, 2015
+ +