Yearly Archives: 2011
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?