Alan Turing’s royal pardon
2

Alan Turing’s royal pardon

One piece of news this week is that Alan Turing received a royal pardon for his conviction for indecency in 1952 for indecency. The best book I read in 2013 was Andrew Hodges’ Alan Turing: The Enigma. I keep intending to write more about the book, but on the occasion of Turing’s pardon, I’ll again encourage you to pick it up. Most articles about Turing’s life explain that he committed suicide after undergoing chemical castration after being convicted for homosexual acts, but Hodges’ conjecture about why Turing took his own life is far more nuanced and interesting. Here’s Hodges on the pardon:

Alan Turing suffered appalling treatment 60 years ago and there has been a very well intended and deeply felt campaign to remedy it in some way. Unfortunately, I cannot feel that such a ‘pardon’ embodies any good legal principle. If anything, it suggests that a sufficiently valuable individual should be above the law which applies to everyone else.

It’s far more important that in the 30 years since I brought the story to public attention, LGBT rights movements have succeeded with a complete change in the law – for all. So, for me, this symbolic action adds nothing.

A more substantial action would be the release of files on Turing’s secret work for GCHQ in the cold war. Loss of security clearance, state distrust and surveillance may have been crucial factors in the two years leading up to his death in 1954.

It’s a great book.

It’s OK to verify skills in an interview
0

It’s OK to verify skills in an interview

Philip Walton: Interviewing as a Front-End Engineer in San Francisco

Walton reacts to the types of questions he got interviewing for front-end developer positions with Internet companies. He was asked lots of abstract questions and few questions about the practicalities of front-end development. I think that it’s a mistake to focus too much on a skills match when interviewing candidates, but I also think that you should verify the skills candidates claim to have in the interview process. In other words, a company that mostly uses Python shouldn’t be afraid to hire Ruby developers, but they should make sure that those Ruby developers really can program in Ruby. Front-end skills are more generalized, and it seems crazy not to interview front-end developers about those skills.

The costly bias against older workers
1

The costly bias against older workers

Harvard Business Review posted an interview with MIT professor Ofer Sharone about the limited job prospects for older workers, especially the long-term unemployed. I agree with most everything Sharone says, but I want to put a bit of a different spin on it. In the interview, he addresses the excuses people use when they refuse to consider hiring older, LTU workers–skills mismatch, underemployment, and fear that they won’t stick around in general.

First, there’s the obvious point that I don’t see made often enough–if the job market were robust, none of these excuses would prevent businesses from hiring older workers, and the problem of long-term unemployment wouldn’t really exist because everybody who wants to work would have a job. Indeed, if economic growth were strong enough, people would be begging retirees to come back to work. This already happens in specific fields that enjoy full employment. I know I write this every time I write anything related to the economy, but it can’t be said often enough. The number one demand we should make as voters is that the federal government pursue policies that lead to greater economic growth.

Now I want to write a few paragraphs for people who are in the position to hire. I think it is inarguable that there’s a bias against hiring older workers in just about every field. I know the Web business well, and I know that it is lousy with ageism. From an economic perspective, this is painfully wrongheaded.

Recruiting great people is probably the most difficult task facing anyone whose job includes hiring. The competition for good people is intense, candidates are tough to evaluate, and the costs of getting it wrong or failing to fill key jobs can be really high. Plus, hiring isn’t a whole lot of fun. As a hiring manager, I’m always looking for an inefficiency that can be exploited. Bias against older workers is a truly spectacular inefficiency.

While you may disagree with the specifics of the 10,000 hour rule, at some reductive level it’s obviously true. Ten thousand hours is five years of full time work. If someone’s been in the work force 20 years, they’ve invested enough time to master four things, and one of those things is usually showing up to work and getting things done. Brilliance is great, but experience can be better, and there are plenty of people out there who are both brilliant and experienced. Age bias somehow makes it hard to see that some older workers are former young geniuses who’ve added a couple of decades of relevant experience since they started out.

The second advantage is that older workers have an actual track record of stuff they’ve delivered, and often that’s lots of lots of stuff. They’ve usually worked on all sorts of projects good and bad, with all kinds of managers good and bad. This track record makes it easier to evaluate them during the interview process. The tough part with older workers is that you have to be somewhat clever when you’re hiring, because you can’t afford the older workers who are obviously great. They’re pulling down huge paychecks at places like Google or Facebook running engineering teams or inventing the next generation of the tools you rely on.

The third advantage is that older workers can often be a useful stabilizing influence and source of perspective in an organization. Having people around who saw the highs and lows of the dot com boom is not a bad thing. If you’re in finance, having people around who remember both the 2008 financial crisis and the savings and loan crisis from the 80’s is probably a good idea. After reading The Soul of a New Machine, I’d love to work with anyone from that team. They know things about working on a high pressure skunkworks project that anybody could learn from. Things aren’t that different than they used to be, but if you don’t work with anyone who’s been around awhile, you’d never know that.

Here’s the catch. There are a fair number of people who discover over time that their profession isn’t really something they’re passionate about, even if they started out that way. Maybe they don’t love the work as much as they thought they would at one time, or maybe that love was beaten out of them by a succession of crappy managers and sucky jobs. Keeping the fires burning brightly over the long term is a skill unto itself. When you’re interviewing older workers, you’re interviewing people who may have already figured out that for them, the job is just a job, but need to keep bringing a paycheck home every week. Regardless of how they get there, people who aren’t passionate about either their work or the mission can bring the whole team down.

Passion is the number one thing I look for at an interview. A fair number of people are obviously brimming with sincere passion for the company, or some aspect of the job, or something that will propel them to show up every day with the kind of energy that makes work fun. For those that aren’t, the best approach is to find a topic that makes their eyes light up, whether it’s programming, or stamp collecting, or Seinfeld, and then comparing that level of passion to their passion when they talk about the work they’ll be doing.

Right now, older people are an undervalued asset. Smart business people will figure out how to take advantage of that inefficiency. I’m not just saying that because I turned into an older person when I wasn’t paying attention.

That’s not analytics
2

That’s not analytics

OK, so a guy made a Web site called Tab Closed Didn’t Read to post screen shots that hide their content behind various kinds of overlays demand that users take some action before proceeding. He’s written a followup blaming the problem on over-reliance on analytics, mainly because some people justify the use of these intrusive calls to action by citing analytics. Anyone who justifies this sort of thing based on analytics should be sued for malpractice.

You can measure almost anything you like. It’s up to the practitioner to determine which metrics really matter to them. In e-commerce the formula relatively simple. If you’re Amazon.com, you want people to buy more stuff. Cart adds are good, but not as good as purchases. Adding items to your wish list is good, but not as good as putting them in your cart. If Amazon.com added an overlay to the home page urging people to sign up for a newsletter, it may add newsletter subscribers, but it’s quite likely that it would lead to less buying of stuff, less adding of stuff to the shopping cart, and less adding of items to wish lists. That’s why you don’t see annoying overlays on Amazon.com.

Perhaps in publishing, companies are less clear on which metrics really matter, so they optimize for the wrong things. Let’s not blame analytics for that.

The latest batch of insider details on Healthcare.gov
1

The latest batch of insider details on Healthcare.gov

Here’s a paragraph from the New York Times’ latest insider account of the efforts to fix the Healthcare.gov Web site (and deal with the political fallout of the problems with the rollout):

But perhaps most important, it remains unclear whether the enrollment data being transmitted to insurers is completely accurate. In a worst-case scenario, insurance executives fear that some people may not actually get enrolled in the plans they think they have chosen, or that some people may receive wrong information about the subsidies for which they are eligible.

I’d like to read a whole article about this paragraph, and not some worthless outpouring of moral outrage either. How’s it supposed to work, and what’s missing right now?

Update: From the comments, a story on the data loss issue.

Required reading: GoldieBlox versus The Beastie Boys
0

Required reading: GoldieBlox versus The Beastie Boys

Like everybody else on the Internet, I’ve been following the dispute between GoldieBlox and The Beastie Boys, or to put it more as I see it, the fight that GoldieBlox picked with The Beastie Boys in order to generate publicity. For a really excellent rundown of the questions of law, check out Andy Baio’s fairhanded take. For the argument that questions of law aside, GoldieBlox doesn’t really deserve the strong outpouring of support they’ve gotten from the rabble, read Felix Salmon.

Capitalism Writ Small
0

Capitalism Writ Small

John Gruber writes about a leaked email from Yahoo executives beseeching employees to switch from Outlook to Yahoo’s own mail product. It’s kind of sad, and as Gruber points out, wrongheaded:

If your employees are only using your own products or services because they have to, or feel obligated to out of some sort of loyalty, you’re losing.

At work, my team builds internal tools. I have no interest in imposing those tools on anyone. It’s our job to build tools that people want to use, or prefer to use over the other available alternatives. I welcome the competition, because participating in the marketplace of ideas sharpens our work and keeps us honest. When I see people doing their own analysis work rather than using something we built to make that work easier, it’s clear that we’re failing to build the right things or to communicate about them effectively.

Duplicated effort can be a waste, but it’s not as wasteful as demand that people use tools that make them less productive and happy. These sorts of mandates are what gave us generations of internal tools that are profoundly worse in terms of usability than widely available consumer software. I like it when people user our software, and more importantly, I like it when people choose to use our software. This kind of internal protectionism at companies weakens the teams involved, it doesn’t protect them.

The Soul of a New Machine
4

The Soul of a New Machine

I’ve recently read two books about computing history, and I intend to write about them both. The first is Tracy Kidder’s The Soul of a New Machine. Kidder was invited by Tom West of Data General to document the creation of a new computer–a 32 bit supermini designed to compete with the formidable VAX 11/780 from DEC.

The book covers the era when building a new computer meant building a new computer from the ground up. The idea of building a computer from off-the-shelf components had not yet arrived, companies built everything from scratch, and wrote all of the code for the new system, all the way down to the metal. Even for highly integrated, brand new systems like the iPhone, many more components sourced from third parties were used than companies like Data General, DEC, and IBM used back then. The original iPhone was built using an existing CPU, and an existing operating system. All of the hardware and nearly all of the software for the Data General system was produced specifically for that system. It is likely that no engineers work completely original systems any more, the costs are too high. It’s hard to read about that kind of work and not feel both nostalgic and intimidated.

At the same time, the mechanics of how projects are run feel familiar, especially if you’ve ever worked on a big project that started with an unrealistic deadline. In many ways, the book documents the computer industry at its worst, even as it cements the mythology of heroic engineering feats that seem romantic from a distance but are usually awful in the moment.

Kidder talks about two phenomena that really resonated with me. The first is the idea of the managers getting people to “sign up” – for the project and for specific tasks. The idea is that “signing up” meant showing a willingness to sacrifice whatever was necessary to complete the task, and to work impossibly hard on the project in general. The managers gauged job candidates on their likelihood of signing up, and turned down those they didn’t believe would. Having had a relatively long career in the computer industry, I’ve seen signing up from both sides. On one hand, as an engineer, you crave a project worthy of signing up for. Signing up only happens when you feel like you’re doing work of significance, that you’re experiencing an opportunity that surpasses any you thought you’d ever be offered.

By the same token, as a manager, you want to work on projects that you would be willing to ask people to sign up for, and you want to hire people who you feel like you can motivate to sign up. Managers must also know that intentionally exploiting people’s willingness to overcommit is almost certainly evil. One of the key attributes of a good manager is a commitment to do what’s in the best interests of the members of the team, whether they want you to or not.

Kidder also lays out the nominal and actual rewards of engineering work. The members of the Eagle team (that was the code name for the computer they were building) were ostensibly motivated by the pinball rule – if they won, their reward was getting to play again. The members of the team toiled in anonymity, even within Data General, and weren’t going to get big bonuses no matter how well the project did. In theory, they did what they did in hopes of getting the opportunity to work on even bigger and better projects in the future. In reality, they did it because they were a team, and because they were committed to their craft. This is a set of values deeply understood by anyone who takes pleasure in building things. The building of new things is both the job and the reward. If you do well, you may get to build bigger things. More importantly, though, at the end, you brought forth order from chaos. What else does a person need?

All great books on history both illuminate the past and highlight the universal, and Kidder’s book meets that standard. I found it to be an incredible page turner. I don’t want to spoil the story, so I’ll say no more. As soon as I finished the book, I wanted to get out my computer and start writing some code.

The other book I just finished is Andrew Hodges’ Alan Turing: The Enigma, about which I have so many thoughts that I’m finding them difficult to organize. I’ll write more about it later.

The magnitude of Adobe’s data breach
1

The magnitude of Adobe’s data breach

I didn’t really pay much attention when Adobe’s massive data breach was first reported, but now that all of the details have emerged, we know that the scope of the breach is truly spectacular. The Naked Security blog has the details. This episode is particularly sad because the best practices around password storage are well understood. Even though practices like using slow hashing algorithms are pretty new, and I wouldn’t have expected Adobe to have adopted them, the basic approach of storing a salted hash has been in wide use for quite some time.

I hope Adobe conducts a productive investigation of the incident and shares the systemic failures that led to the breach — not just the user database being stolen, but also the decision not to migrate to a more secure method of password storage over time. My guess is that Adobe not only has many Web properties, but also native applications that need to authenticate, and that they probably weren’t abstracted cleanly from the database used to store the encrypted passwords, so migrating to a new system was always deemed to be too low priority to be worth the extensive effort required.