I spoke for more than an hour last month with Morgan at ParentsInTech.com — 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.
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.
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.
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.
There are songs that I still like because I had some past emotional connection with them (and I suspect I’d reject otherwise), like this one.
I have a yen for a handful of old Nat King Cole tracks, like this one; I like this Rosemary Clooney song and a few others by her (and Dean Martin’s version isn’t half bad either) but if you give me random, or even the most popular tracks by any of those three, you’re going to have me rolling my eyes. And damn it, if you think I want to hear Natalie King Cole dubbed in with her father singing “Unforgettable”, you are dead wrong. (Can you tell I’ve tried a few sites that guess what I want to hear based on what I’ve selected already? No, I don’t think that’s the answer either…).
I wander about sites like bandcamp, thesixtyone, soundcloud — these are neat (but it’s frustrating how much music is out there that I don’t really like). I found this and liked it, (and used an excerpt in a youtube video), though it starts a bit mediocre, and degrades into confusion at the end. And nothing else the artist did worked as well for me.
This is my personal landscape of music preferences, but am I the only one? The amazing diversity of music “out there” has become the amazing diversity of music “right here”, whenever we feel like wandering around a bit in the aural landscape to sample some new treats.
The old-fashioned radio stations — and the entire model of a radio station, with a programmed sequence of tracks to be shared by everyone listening — can’t cater to this kind of demand.
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.
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?
Well, the first implementation of anything is half proof-of-concept and usually rushed, and no one ever knows at the beginning of the project how to design for its entire lifespan. And the later developers needed to get these features added ASAP, these bugs fixed ..and after a while, trying to clean things up is an act of recklessness. Everyone is leery of changing code they don’t understand, so they tiptoe around adding in redundant code, touching only what they must, and not even updating comments (what are you going to write? “this does a bunch of weird stuff but at least line 2038 no longer crashes on nulls”?).
Methods sprawl into hundreds or thousands of lines (and have less & less connection to their original names).
Logic gets stranger (because it’s safer not to touch what’s already there… just sort of sneak in the new bit however you can).
Spaghetti code snowballs. (insert horrifying sound-effect here)
Notice that this doesn’t require incompetent developers at any point. If they aren’t somehow getting time to actively maintain the quality of the codebase, it will go straight to hell all by itself. It’s a natural process.
Let’s get to a more interesting insight I had into this whole mess, though. It’s a hell of a lot easier to fix a problem if you can explain it quickly without resorting to technical lingo.
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 TED.com talks, also excellent and worth looking up.