Ever since the torture report was released last week, U.S. television outlets have endlessly featured American torturers and torture proponents. But there was one group that was almost never heard from: the victims of their torture, not even the ones recognized by the U.S. Government itself as innocent, not even the family members of the ones they tortured to death. Whether by design (most likely) or effect, this inexcusable omission radically distorts coverage.
I’ve read two really excellent posts about hiring engineers lately. Both of them are aimed at adding nuance to the discussion of “hiring the best.” The first, from Cate Huston in Model View Culture takes this on directly in her essay, We Hire the Best. Here’s her rephrasing of “hiring the best”:
Among people we know, we hire “the best” (as determined by our subjective process), who are willing and able to work in a specific place (or remotely), and who accept our offer.
She then goes on to survey the space that exists between “the best” as defined by the company itself and the candidates who wind up accepting offers. That space also happens to be where most of the industry’s worst hiring practices live.
Jocelyn Goldfein’s piece, How To Hire Engineers: Step 0, What To Look For, goes on to demolish the idea there’s a definition of the “best engineer” that works for choosing who to hire in the first place. There are a large number of positive characteristics an engineer might have, and some of them are in opposition with one another. Building a good team is about assembling a group of people that collectively exhibit all the strengths you’d hope to see.
The risks of emphasizing a few strengths to the exclusion of others are high. Here’s one end state:
If you elevate your “hiring bar” to religious status, and represent, say, coding speed, not as a means to the end of shipping great software, but instead as the gold standard of What It Means To Be A Rockstar, you’re going to have a lot of trouble hiring for anything else. Your existing team (who have all been selected for coding speed) will view this as “lowering the bar” and the consequences could be severe — anything from griping and loss of morale, to blocking or undercutting new hires, to quitting.
I have seen this happen, and it’s not pretty.
As a manager, I think it’s important to think about the next hire rather than the ideal engineer. What does your team lack right now, and how can you address it by hiring someone? Maybe you need someone who’s more collaborative, or maybe you need someone who really likes to dig into deep problems. Maybe you need to hire a more junior person to take some work off of a senior person’s plate, or maybe you need to hire a senior person to tackle big projects. When it comes to hiring, you have to blend these requirements with the attributes that you consider to be non-negotiable and then apply those wishes to the pool of candidates who are available.
It is incredibly tempting to think about hiring the way colleges think about admissions – ranking the candidates and hiring the “best.” This is a very common approach to scaling up the hiring process at tech companies. I don’t think that it’s the path to building solid teams as opposed to groups of solid individuals.
Scott Rosenberg talks about Go, Swift, and how big companies bring new programming languages into the world. If nothing else, worth reading as an excellent example of how you write about software development for a non-technical audience.
Luke O’Neal in the Washington Post on Black Friday and how it is advertised:
It’s hard to avoid the message of those ads. We’ve been bombarded with them for weeks now, from corporations eager to entice shoppers with so-called “door-buster” deals. And then, once the shopping public falls for them, a privileged segment of the population sits back and dehumanizes them for its collective amusement. Look at these hilarious poor people, struggling to take advantage of a deal on something they might not otherwise be able to afford on items that we take for granted, we joke on Twitter. The message is the same: this is shameful, materialistic behavior. And by pointing it out, we differentiate ourselves, reaffirm our class status as being above the fray of the lowly and desperate.
Vagrant is one of those things I hear people talking about but that I’ve never gotten around to playing with, or hadn’t gotten around to playing with until today. Vagrant is a solution to the problem of setting up a local development environment for Web development. Depending on the platform you use, this can be rather difficult. I don’t even want to think about Windows development, but even in a Unix-like environment (OS X or Linux), you can still run into problems.
Basically, your system probably has some version of the language runtime you’re using that doesn’t match the server’s, and reconciling the difference is painful. I’ve always hated solutions like virtualenv and dvm. Vagrant works by running a full-blown virtual machine somewhat transparently. Helpfully, the virtual machine mounts one of your local directories so that you can edit files in your tool of choice but run your development server on the development machine, which should match your server pretty closely. For example, to experiment with Google App Engine development, I created a Vagrant instance using
ubuntu/trusty64 (the latest Ubuntu LTS release), then I provisioned it using the following file:
apt-get update apt-get install -y unzip cd /vagrant curl -s -O https://storage.googleapis.com/appengine-sdks/featured/google_appengine_1.9.15.zip unzip -n -q google_appengine_1.9.15.zip
When the instance is provisioned, it automatically downloads the Google App Engine SDK and extracts it. Then I can dig in.
This is a super-simple application. Next I want to try setting up a Vagrant instance that’s provisioned using the chef server at work with our production Hadoop configuration so that I can easily launch Hadoop jobs from my laptop rather than logging into a remote machine to do it.
Re/code made news this week by eliminating comments on the site, noting that most of the discussion about their articles was happening elsewhere. In the larger scheme of things, “Don’t read the comments” is widely regarded as universally good advice. This makes me more interested in sites with healthy communities of commenters.
As far as I can tell, comments are as good as the people running sites want them to be. If they invest in building a community, healthy comment sections tend to spring up. If not, they don’t. Fred Wilson makes the same argument in Comments Are Dead, Long Live Comments, and of course his site has one of the most active (and generally constructive) comment sections of any blog you’ll read.
I’ve had comments enabled on rc3.org for a long time, but I police them pretty heavily, both for spam and for idiocy. Lately posts don’t get too many comments, probably because I don’t post as much as I’d like. I’ve always been proud of the comments here, though. They make the site better.
I’m not terribly interested in this argument.
If you care about the longevity of your work, you will publish it on Web pages that can be rendered in a browser. Nobody knows what will happen with apps or app stores in the future. If you publish something and want to make sure people can view it in 10 years, it needs to have a URL that works in a browser. If you want to make your work available to as many people as possible right now, you’ll publish it on a Web page. If you go with apps only, you exclude every desktop user and everyone who won’t bother to install your app. Maybe that’s fine for some companies, but for most it is not. Ignoring Web browser is not a realistic option for most people building on the Internet. That’s not going to change any time soon.
At the same time, if you are trying to build an Internet business, you have to strongly consider writing iOS and Android apps. Web usage is rapidly migrating to tablets and handsets. Often, users are less engaged on these devices, especially handsets. This presents an existential threat to some companies. In the world of analytics, everybody talks about conversion rate. This is basically the percentage of users who perform an action that’s desirable to the business when they visit the site. Mobile users generally convert at a lower rate than desktop users. Businesses are betting that they can raise conversion rate through mobile apps, that’s why so many sites that look just fine in the browser are releasing apps and nagging users to download them.
Neither Web pages nor native apps are going anywhere anytime soon. The content that has traditionally been on the Web will always be on the Web. Lots of companies are going to build native apps in hopes of making their users happy. And, of course, some companies that are building software for mobile devices are going to do so without building Web pages, which is not worrisome.
What I do dislike about native apps is that they are a very real threat to the way we develop software for the Web. The great thing about the Web is that if there’s something wrong with my Web site, I can fix it whenever I like. I can update my Web applications every day, or 100 times a day if it behooves me to do so. It’s easy to launch experiments and turn them off. Thanks to app stores and software distribution challenges in general, native apps are a huge threat to everything we’ve learned about delivering software on the Web. Of course we can put as much of the application on the server side as possible, but even so, we can’t iterate on native apps the way we can on Web applications.
For this reason, in the end, I’m rooting against native apps. I enjoy the benefits of Web development too much to root for an approach to software development and distribution that I find to be backward and frustrating. I love well-made native applications as much as anyone, but I’m hoping that mobile browsers improve enough to make it seem silly for most sites to build native applications.
This article in Business Insider is the first media mention I’ve seen discussing the disappearance of referrers on inbound traffic to Web sites. For people who work in analytics, especially on sites that make money by selling advertising, this is a really big deal. In many cases, analytics can be invasive from a privacy standpoint, but referrers generally don’t contain any information you’d just as soon not disclose. Hopefully this will spur a wider discussion of this change.
For what it’s worth, the article is wrong about why browsers strip referrers from traffic that originates on HTTPS sites. When you are viewing an encrypted page, browsers want to make sure that none of the encrypted information is sent over a non-encrypted link. So when you click on a link on an encrypted page that points to a non-encrypted page, the browser strips the referrer to avoid sending information that was encrypted over the non-encrypted connection. Referrers are not stripped when you click on a link from one encrypted page to another, even if they’re on different domains. Sites can get potentially get referrers back by switching to HTTPS, but only if people link to the HTTPS URLs. So if I have a site that accepts HTTP and HTTPS, and all of the links indexed by Google are HTTP links, the referrers will be stripped even if the user ultimately lands on a secure page. So in this case, it’s not really a choice on the part of browser vendors to protect user privacy, but rather one to respect the sanctity of encrypting information.
Update: Also, apparently this discussion of traffic has been going on for awhile.
John Gruber has a piece up about retailers disabling NFC at checkout to prevent customers from checking out using Apple Pay. Retailers are intentionally degrading the customer experience in order to retain the ability to collect data about their customers’ habits. This tradeoff is near and dear to me, as analytics is currently a huge part of my job.
What I’d like to know is, what’s the return these companies are getting from tracking the behavior of specific users? For one thing, the work to build systems to exploit this data is resource intensive, and often results in failure. Companies are risking hurting their business by inconveniencing customers in exchange for the opportunity to make more money by exploiting the purchase history of their customers. I’d be really, really surprised if the economics actually work.
These days, if you want attentive customer service from most companies, the most direct route is to complain about the company on Twitter in such a way that your tweet shows up in the company’s mentions. It doesn’t matter whether your cable is working poorly, you had problems rebooking a flight, or your iPhone app didn’t work as well as you expected, Twitter is the place to seek relief.
This is a problem, mostly for the companies people are complaining about. They’re teaching their customers that the only way to get responsive customer service is to embarrass them publicly. What these companies fear most is that a complaint on Twitter will inspire an avalanche of “me too” retweets and responses that ultimately has a measurable negative impact on their business. That gives every customer who happens to be on Twitter the opportunity to be an amateur extortionist.
Here’s the thing, though. I don’t want to have to threaten a company to get decent customer service. If that’s what it takes, I don’t want to do business with the company at all. This is on my mind, of course, because there’s a company out there that I am having a bad customer service experience with, and I’m frustrated by the fact that griping about it on Twitter would almost certainly make it better.
What I’ve done instead is look at the company’s replies on Twitter to see what they suggest to other people who go to Twitter with their complaints, and follow those instructions. We’ll see how it works out.