This is the most important tech story of the week, and everybody has chosen to write about it. This just happens to be the one I’m linking to. It’s by Tim Wu on the New Yorker’s Elements blog.
Former New York Times executive editor (and current columnist) criticized a straw man version of cancer patient Lisa Adams, arguing that she is:
… the standard-bearer for an approach to cancer that honors the warrior, that may raise false hopes, and that, implicitly, seems to peg patients like my father-in-law as failures.
He then added:
Steven Goodman, an associate dean of the Stanford University School of Medicine, said he cringes at the combat metaphor, because it suggests that those who choose not to spend their final days in battle, using every weapon in the high-tech medical arsenal, lack character or willpower.
As it turns out, it’s not Lisa Adams who introduced the combat metaphor, but rather Keller himself. Here’s what Adams said about combat metaphors on her blog in 2012:
When I die don’t say I ‘fought a battle.’ Or ‘lost a battle.’ Or ‘succumbed.’ Don’t make it sound like I didn’t try hard enough, or have the right attitude, or that I simply gave up.
After people started calling Keller on it, he responded to a question from the paper’s public editor thusly:
I think some readers have misread my point, and some – the most vociferous – seem to believe that anything short of an unqualified “right on, Lisa!” is inhumane or sacrilegious.
I have no doubt that he did get some responses like that, but choosing to dismiss those responses rather than engaging with more substantive critiques was lazy and evasive.
Plenty of people have written excellent pieces explaining why Keller is simply wrong on the facts and in his conclusions. For example, you should definitely read Zeynep Tufekci’s post Social Media Is a Conversation, Not a Press Release. What I want to write about is Keller’s lack of preparedness to opine in the age of social media.
One thing we do on the Internet is argue. A lot. Some of us have been arguing with people on the Internet for decades, and many of us have internalized the big list of fallacies and are just waiting for an opportunity to recognize their use and shove your argument back in your face. It doesn’t matter whether you’re arguing about text editors, the baseball Hall of Fame, or how cancer patients ought to use social media, the Internet knows more than you do about it. In the open source world, they say that given enough eyes, all bugs are shallow. It’s also true that given enough participants in an argument, all errors of fact and fallacious arguments are exposed.
It’s times like these when the old media really shows its age. In the good old days, you could pronounce and pontificate with relative impunity. The worst thing they faced were letters to the editor. These days, by publishing, you are making an argument, and you can expect for people online to argue back. The second a column goes up, people start dissecting it on Twitter. Then come the blog posts. And finally, other publications, or even your own, start running think pieces about the online reaction to your crappy column. If you’re David Brooks, the Internet will probably skewer you with top notch satire as well. The old guard is going to have to harden up.
Update: Really nice post by Linda Holmes for NPR about how Bill Keller uses language to diminish Lisa Adams and her readers.
I had one of those “reading your own obituary” moments this morning when I picked up the New York Times. In an article about how banks are trying to change the customs that coerce junior employees to work nights and weekends, the writers bring up the increased competition from the technology industry. Here’s how they put it:
Though the prospect of a large salary and experience in finance still draws many college graduates to the industry, some ambitious students are considering other career paths, including those in the technology industry, famous for its employee perks like free oil changes or staff masseuses.
It irritates me to see that the industry in which I’ve spent my entire career is defined to outsiders by the perks offered, and not just because I’ve never gotten a free oil change or a massage at the office. I have plenty of friends who work in industries full of people who are motivated by compensation, perks, prestige, and everything but the work itself. Most of them are eagerly looking forward to retirement.
Weeding out those sorts of people is probably my number one goal in the interview process. As I said when I reviewed The Soul of a New Machine, for me, the work is the reward. If you don’t see it that way, you should consider the opportunities available in finance.
University of Rochester computer science professor Philip Guo has written a great post, shining a light on the bias in the computer industry in favor of people who look like him (or me). In it, he explains how he has gotten the benefit of the doubt in situations simply because he looks like what people expect a computer programmer to look like. It’s a first-hand account of what John Scalzi talked about when he wrote about straight white males playing the game of life on easy mode.
Here’s a bit from the post, Silent Technical Privilege:
… people who look like me can just kinda do programming for work if we want, or not do it, or switch into it later, or out of it again, or work quietly, or nerd-rant on how Ruby sucks or rocks or whatever, or name-drop monads. And nobody will make remarks about our appearance, about whether we’re truly dedicated hackers, or how our behavior might reflect badly on “our kind” of people. That’s silent technical privilege.
He contrasts that with the challenges placed before people who are outside the demographic sweet spot that so many people associate with being a computer programmer. As he says, you don’t have to be a superhero to succeed in software development, and we shouldn’t demand that people who don’t enjoy these privileges be superheros to make it in this business.
This leads me to the theory that if you want to hire superheros, you should ditch your biases and expand your hiring pool. The people who have persisted and succeeded in this industry in the face of the inequeties that Philip documents are much likelier to be superheros than your run of the mill bro who shows up to the inteview in his GitHub T-shirt with a cool story about making money in high school by creating Web sites for local businesses. There are plenty of superheros that fall into the privileged category, but they already have good jobs because they will never, ever be overlooked in the hiring process. The awesome programmer who also seems like they’d be super fun to have around the office? They get a job offer every single time.
The enterprising hiring manager has to think outside the box a bit. You know the feeling. The person seems like they’d be great at the job, but is different enough from everyone else that you wonder a bit how hiring them would affect team chemistry. I’m not talking about personality here, but demographics. (I’d never recommend that a non-competitor hire brilliant jerks.) The hypothetical candidate I’m talking about here has to deal with these unspoken questions every single time they apply for a job. That’s not fair, and it’s incumbent on our industry to change, but in the meantime, it’s possible to exploit these widespread biases to hire the superheros that most companies won’t even consider. At least that’s the theory.
Felix Salmon: Netflix’s dumbed-down algorithms
Good piece on the evolution of the Netflix user experience, necessitated by the transition from the “rent movies by mail” model to the streaming content model, and the licensing fees for streaming content online. I find that Netflix is OK if you just want to watch something, and mostly terrible if you want to watch a specific thing. The Netflix experience has been changed to discourage you from attempting the latter.
Camille Fournier: 2013: The Constant Introspection of Management
Nice post on the hard parts of being a manager. One thing I’d add is that as a manager, the mistakes you make all too often have an impact on real people, an impact that’s impossible to undo. If you put someone on the wrong project and they spend six months not really learning anything, that’s six months they can never have back. It’s a tough job.
John D. Cook has a post on one of my favorite management topics, when to delegate.
My thoughts on delegation are probably fairly radical. The first principle is that if a project strikes me as interesting to work on, I must delegate it immediately. Managers almost never have the bandwidth to tackle interesting technical problems, it’s the nature of the beast. When I delegate projects, I can remain engaged to a degree that allows me to learn and to hopefully add some value, without stalling progress because I’m too busy dealing with the other million distractions that are part of manager life. I tend to stick with working on the tasks that are too boring or repetitive to bother delegating to other people – they’re generally about the right size to get out of the way when I’m between other things.
The second principle is, delegate everything, especially if you’re in a new role. When you take on a new role, there is no way to estimate how much work is going to be coming your way, or to list what all the demands on your time will be. All of the stuff you were doing is either going to keep you from succeeding in your new role, or just isn’t going to get done, unless you can delegate it to someone else. Of course, in reality you’ll never be able to delegate everything, but proceeding as though you can will hopefully keep you mindful of the fact that you should always be looking for opportunities to delegate.
The point I’m really getting at is that most people are far too reluctant to delegate, and far too selfish when it comes to delegating. Usually when you’re in a position to delegate, you are also at least partially responsible for the professional well-being of the people you’re delegating things to. The things you delegate should hurt a little to give away.
Katie Siegel: It’s Not “Too Late” for Female Hackers
Paul Graham’s comments in an interview behind the paywall at The Information (and unflatteringly excerpted by ValleyWag) have been the subject of much discussion this week. Siegel’s post gets at what was really problematic about them. I’m one of those people who started programming at age 13, and it has always been easy for me to advocate hiring people like myself, for exactly the reasons Paul Graham gives. Siegel ably makes the point that this line of thinking is unfair to everybody who doesn’t fall into his select group, but I’d argue further that it’s also just bad business. More on that later.
Update: Paul Graham says he was misquoted. I’m glad Graham cleared things up. In his update, Graham says:
If you want to be really good at programming, you have to love it for itself.
That’s a sentiment I agree with completely. One reliable indicator that a person loves programming for itself is that they started as a kid. The problem arises when we treat that as the only reliable indicator, which Graham does, at least based on this passage from the transcript:
The problem with that is I think, at least with technology companies, the people who are really good technology founders have a genuine deep interest in technology. In fact, I’ve heard startups say that they did not like to hire people who had only started programming when they became CS majors in college. If someone was going to be really good at programming they would have found it own their own. Then if you go look at the bios of successful founders this is invariably the case, they were all hacking on computers at age 13.
I enjoy the great privilege of working with Dan McKinley, whose blog is at mcfunley.com. He doesn’t post very often and his posts are reliably great. I want to call out one post specifically … Testing to Cull the Living Flower. Here’s one sentence:
When growth is an externality, controlled experiments are the only way to distinguish a good release from a bad one.
In it, he argues for why sites that are enjoying rapid growth must use A/B testing to build features if they want to be confident that they are making a measurable, positive impact on that growth rate.