Laundry backpressure

It’s been a recurring problem in our house – clean laundry starts piling up on the bed in the spare bedroom, and we always intend to finish sorting & putting it away… but it mostly doesn’t happen until there’s an intimidating heap and we have to dedicate serious time to a rescue effort.

We’re all busy – two parents with work to do, two kids with homework & music practice waiting, two cats busy with their mysterious cat priorities. Food things, friend things… Every now & then, we manage to get ahead of it, but soon, when we’re choosing between “sort & put away laundry” vs. all the important stuff… the laundry starts to collect again.

I came up with a strategy yesterday, though, inspired by a concept I’m familiar with from work: backpressure.

Interview: Parents In Tech

I spoke for more than an hour last month with Morgan at — then he was tasked with winnowing it down to a blog post of a reasonable duration.

I have somewhat mixed feelings about it — what comes across the most is that I’m bursting with advice about parenting; lessons I’ve learned, things I’ve noticed.. I’m fascinated by the evolving relationships between parents and children (and where they go right, and where they go wrong), and I could talk about them for hours.

I didn’t talk as much as I should have specifically about how to be an involved parent in the tech startup world in general, and in particular how our work environment at PKB enables that… I’ll add more thoughts here, briefly.

Waiting is horrible. So don’t do it.

The NY Times has an writeup today on the psychology of waiting – mostly, waiting in line.

Here’s the wrap-up at the end:

The dominant cost of waiting is an emotional one: stress, boredom, that nagging sensation that one’s life is slipping away. The last thing we want to do with our dwindling leisure time is squander it in stasis. We’ll never eliminate lines altogether, but a better understanding of the psychology of waiting can help make those inevitable delays that inject themselves into our daily lives a touch more bearable. And when all else fails, bring a book.

Understand why it’s unpleasant?  Bring a book?  Meh.
Here’s my counter-offer: waiting is optional; don’t do it.

I’m not talking about finding clever ways to jump the queue or get VIP treatment. This is simpler (and more practicable).

You can do whatever you like in a waiting room, in a supermarket queue, in your car while stuck behind a truck on a winding back road, etc. etc. — anything, as long as you can do it in your head.

If this sounds like a joke, or that it wraps a cruel assumption that you’re some kind of mental Olympian, bear with me for just a moment while I connect some dots.

What’s wrong with making money from advertising?

Any hardcore developer must be dying to work at Google, Twitter, or Facebook, right? Well, no; see this post by Dave Copeland, “Why I’d never work for Google, Twitter, or Facebook”.

I generally agree with his points; if your core business (where the money comes from) is advertising, your customers are the businesses who pay for the ads, and — to put it bluntly — your users are your product. However sophisticated the services you offer to keep your users around (viewing ads…), your relationship with your user/product is unavoidably marred by this fact.  “I’m giving you things, on the assumption that I can convince you to give sufficient money to my actual customers.”

As a developer, I’m not interested in pushing ads any more than Dave is (though the point is academic, since I’m not exactly being recruited by the “big three” — but the principle certainly influenced my job search last year).

It’s not just that I’m not interested in advertising, though. Any company’s actions in the world have myriad effects on lots of people, from tiny to grand scale, and delivering better and more effective advertising is a net negative.

My music doesn’t come in “genres”

I had an odd realization the other day; I ran across a new music streaming site – promising “interactive radio that will blow your mind” – but while scanning through the list of 50 or so categories of music to choose one matching my tastes, my interest rapidly waned. ALL of them looked bad to me. It was like going back in time 20 years and flipping through the free audio cassette bin at a suburban yard sale. I couldn’t imagine starting up an audio stream in any of these categories and liking what I heard.  R&B?

At first I thought that maybe my musical tastes have just grown too weird and eclectic over the years, but there are plenty of tracks I like that are “popular”, or were popular 10 or 15 (or 100) years ago.

Here’s the catch, though — I don’t like categories. I don’t even like artists. Example: I like Radiohead — see, that’s totally mainstream! — but they have entire albums I’d just as soon skip past, and no single album I’d want to hear in its entirety.  There are songs I’ve liked enough that I’ve listened them to death, and never want to hear them again.

Why Don’t Developers Like to Estimate Time Accurately?

I was reading this just now – Why Can’t Developers Estimate Time? – and realized the discussion leaves out some fairly important psychological factors that influence time estimates significantly.

As the developer, you focus on the risky bits — the parts that are technically difficult & complex, that use new APIs or new libraries you aren’t familiar with, that require designing a new UI, or matching very strict performance tolerances.

For these sections, developers (with a little training) can learn how to estimate as well as possible — it’s hard, we know it’s hard, and either we’ll say “that’ll take a long time” or we say “we’d better do a proof-of-concept first, because I’m not sure at all how that will go.”

Now we get to the rest of it — the trivial parts. Writing some simple tests, taking input, validating it, storing it, returning something else simple straight out of the database… it’s simple, it’s boring, and any developer on the team could do it.

But it always takes an embarrassingly long time (with the emphasis on “embarrassing”).

Your codebase is a user interface

Every developer has spent time working on at least one project that was rife with poorly or bizarrely-named variables/methods/types, dead code, impossibly long code blocks, misleading comments, contorted logic, ancient libraries and dependencies that are never upgraded, and worse.

“Someday,” of course, “we’ll clean that up” — but there are urgent features already promised to customers, urgent bugs, and of course everything is always running late because the codebase is so darn hard to work with.

So yeah, curse the earlier developers who made the first mistakes, right?

Long shadows of colonialism

First: an brief, animated guided tour of health and wealth statistics over the past 200 years, from Hans Rosling (this is far more interesting then it sounds at first blush).  If you haven’t seen this video already, you may still know Rosling from his talks, also excellent and worth looking up.

Creative procrastination

I was taking Mrs. Bang for a walk last night, at 2am or so, and mulling over my ideas for a dauntingly large new feature I want to add to my music theory site. One idea spun from another, and I started thinking about mad libs — you know, the game where you fill in the blanks in a pre-written story with input from your friends (“adjective about a person”, “action ending with -ing”, “unusual animal”), then read the resulting silliness aloud.

Well, an online mad-lib engine would be pretty trivial to write — just collect the words from the user first, and plug them into the text of the story in the right places. You could play madlibs at a party without anyone knowing beforehand what the final result would be, or even play alone.

Eye surgery

Thank you to all of the friends, and friends of friends, and contacts of friends of friends (!) who shared their advice, thoughts, warm wishes and professional opinions with me when I was deciding how to proceed with the slipped IOL (artificial lens) in my right eye.

I’m documenting discussions I had with my ophthalmologist and his colleagues, the decisions I made, the operation and ongoing status here.