rc3.org

Strong opinions, weakly held

Author: Rafe (page 20 of 989)

Interviewing is just a model of employment

Etsy has gotten a lot of attention for its efforts to increase the gender diversity of its engineering team in the past year. The short version of the story is, Etsy made a concerted effort to recruit more female engineers, and made some changes to its hiring model that led to positive changes there. For more details, see First Round Capital’s coverage of a talk on how we did it by Kellan Elliot-McCrea, our CTO.

Unsurprisingly, this effort has drawn criticism. The most visible example is a blog post from Meghan Casserly from Forbes, which accuses Etsy of instituting a double standard, undermining female engineers even as it attempts to add more to its staff. Here’s the crux of her post:

In other words, hiring women engineers is hard. Especially if you hire them like men. “Don’t lower standards,” Elliott-McCrea says, but isn’t exempting women from the same brutal challenge-based interviews their male colleagues undergo doing just that? While I applaud Etsy for its single-minded dedication to increasing gender diversity in its ranks, instead of feeling uplifted by Elliott-McCrea’s presentation I find myself stuck on the question: Is hiring women as women just PC pandering?

There’s a lot that’s wrong with this blog post, starting with the assertion that Etsy has exempted women from anything. For example, “brutal challenge-based interviews” were never a standard part of the interviewing process at Etsy.

The post serves to illustrate a larger point that I want to make. The reason companies interview engineers at all is that they need to assess what kind of team member they’ll be. Can they write code? Can they deliver results in a timely fashion? Will they drive everyone nuts? Are they capable of learning? Interviewing is one way to get the answers to those kinds of questions.

The hiring process is about creating a model of a potential employee that the employer hopes accurately represents what kind of employee they will be. These models are not terribly accurate, and there is a huge amount of space within which a company can experiment in order to refine that model.

Nobody has convinced me that stressful “challenge” style interviews accurately model the work of software developers. People who do well at them are not necessarily more qualified than people who do poorly at them. Answering interview questions is itself a skill, and being good at it doesn’t mean you’ll necessarily be good at the job. Etsy is iterating on how it builds a model of software engineers through the hiring process. Every company should be.

Fetishizing interviewing, or a specific style of interviewing, betrays the same sort of lazy thinking that I wrote about the other day. I’ve seen great engineers turned down for jobs due solely to the fact that the entire panel of interviewers all took the same approach. The model was broken, but the interviewers thought that the problem was that the candidate wasn’t up to the challenge. The Forbes blog post falls prey to the same problem.

Lauren Bacon makes a related point in her response to the same Forbes blog post.

The wrong way to put up a maintenance page

Everybody with a Web site or service occasionally has to put up a maintenance page. Maybe you’re doing database maintenance that requires downtime, maybe you had a hardware failure, maybe Amazon Web Services is having some kind of outage.

You can either set up your application so that the page is displayed instead of what the customers expected to see, you can have a status page that shows whether the service is running, or you can redirect the user to the permanent URL where the maintenance page always lives. The latter approach is the wrong one. Here’s why.

Let’s say your service has a scheduled maintenance window that starts at midnight and ends at four in the morning. Your customers are most likely going to have to put up a maintenance page of their own and turn off the code that connects to your service while it’s down. Somebody is going to have to set their alarm, make sure the page is back up, and then reenable the service, update their own maintenance page, and so forth.

When said person gets up early in the morning, there’s a good chance they’ll go to the browser tab that’s displaying the state of your service and hit reload to see whether it’s back. If you have redirected them to a maintenance page that’s always around, they’re going to see that your site is down for maintenance even if it’s back up. At worst, they’ll assume your service is still down and not turn things back on at their end. At best, they’ll still have to finish waking up and actually investigate further.

Sure, putting a static page up somewhere and redirecting to it is easy, but it’s lazy and wrong. Don’t do it.

This message is brought to you by someone who had to set their alarm on a Sunday morning so that they could verify that a third party vendor had successfully completed scheduled maintenance and got confused after reloading the maintenance page in their browser.

Tim Bray wishes XML a happy 15th birthday:

When XML was in­vented, it was the world’s only use­ful cross-plat­form cross-lan­guage cross-char­ac­ter-set cross-data­base data for­mat. Where by “use­ful” I mean, “came with a pretty good suite of free open-source tools to do the basic things you needed.”

That’s why it ended up being used for all sorts of wildly-in­ap­pro­pri­ate things.

Why should we take the stock market seriously?

I generally find the way stocks are priced to be a joke, and press coverage of the stock market to be an even bigger joke. My favorite recent example is today’s New York Times’ Common Sense column, which talks about herd mentality in analysts rating Apple’s stock as a Strong Buy right up until the shares fell off a cliff recently.

Notice the lack of coverage of Apple’s business fundamentals — the discussion is of the performance of the stock compared to the predictions. That’s topped off by extensive quoting of an analyst who did pick against Apple, without any kind of data-founded discussion of his performance overall. He was right about Apple’s recent share value, but we have no idea whether he’s right or wrong about anything else.

Corporate management at public companies is judged based on stock performance, but except in extreme cases, both stock prices and the coverage of them is almost completely divorced from the actual performance of these businesses.

I think a more interesting column would take a more data-centric approach. How does Apple’s share price compare to its financial results? How does that compare to other companies in the same business? How have the various analysts discussed in the article performed over time in terms of stock predictions? The column asks low quality questions and thus yields uninteresting answers.

Your dogma is already obsolete

Last week’s New York Times included a book review of defense reporter Fred Kaplan’s book “The Insurgents,” which covers General David Petraeus, counterinsurgency doctrine, and the wars in Iraq and Afghanistan. It explains well how falling in love with your ideas can get in the way of success.

Kaplan writes about how proponents of counterinsurgency doctrine in the military worked the media, defense scholars, and the defense establishment to replace the existing Cold War doctrine with their own ideas. Here’s how the reviewer, Thanassis Cambanis, describes their better days:

President Bush had promoted the COINdinistas because they were flexible, pragmatic problem solvers and because he had a nagging problem on his hands: how to get out of Iraq without looking defeated. Counterinsurgency was just one part of the fortuitous mix that yielded a just-good-enough resolution for Iraq. Petraeus and the officers and experts had been right about how to fight in Iraq and reached plum positions in the Pentagon.

And here’s the conclusion:

The COIN brigade forced the Army to adapt, to become what one officer called “a learning organization,” but the Pentagon failed to grasp the most important lesson of the decade: that the military does best when it can learn new types of missions quickly, whether delivering aid after a tsunami, stabilizing a failed state or running covert missions against international terrorist rings. Instead, it exchanged an old dogma for a new one. Once persuaded that the military could do counterinsurgency, few in Washington stopped to think about when it should do it.

This story reminded me a lot of the tech industry. Last year, GitHub’s Ryan Tomayko wrote a “here’s what works for me” blog post about his management style, which was fantastic. Here’s the crux of it:

It’s often cited that GitHub doesn’t have managers. In my opinion, a better way to describe the phenomenon would be to say that everyone at GitHub is a manager. Instead of assigning 100% management duties to individuals, the basic role of management is spread between 1.) every single employee, and 2.) a set of custom in-house tools that serve to keep everyone in the know with regards to other projects.

I think this is a pretty brilliant philosophy, and my impression is that it works very well for them. That article changed the way I think about my work as a manager.

This weekend I listened to a presentation from a developer at GitHub about their “no managers” corporate structure. This presentation essentially argued that the GitHub approach is indisputably the best way to run a company, and that all other corporate structures are broken.

This is exactly the trap that the military officers Fred Kaplan wrote about fell into. It’s a form of lazy thinking. Every problem and situation is unique. Nearly all people are naturally inclined to cling to heuristics rather than thinking deeply about problems and adapting to solve them.

This is one of the great penalties of success. People try something, meet with success, and then attempt to apply that formula over and over again, failing to recognize that new problems require new solutions. Often the real reasons for success go completely unexamined, because people are so eager to embrace it as proof of their own brilliance.

To the proponents of counterinsurgency doctrine, every war looks like an opportunity to apply counterinsurgency doctrine. To the GitHubber, every corporation should work like GitHub.

When people propose that all problems look the same, or even worse, that problems look different but that old solutions are still ideal, it’s a strong sign that they’re operating from within their dogma rather than starting with the problem and working their way out. There’s nothing that invites disaster more than falling in love with your own good ideas.

The state of blog comments in 2013

It seems like the recent trend has been toward publishing blogs without public comment sections. For one thing, people are sick of spam, Internet cranks, and the work required to have a comments section that adds to the site rather than detracting. As an example, here’s Matt Gemmell explaining why he turned off comments. At the same time, many writers are using static publishing engines or sites like Tumblr that don’t even support comments. (I know you can use third party commenting tools like Disqus, but most people don’t.)

Here’s a chart that shows the comments per post broken down by month going back to the first month that I added comment support to the blog. As you can see, the number of comments per post has dropped, even though I’m publishing fewer posts. That said, the variability has been pretty high, and the months with high averages are a result of extreme outliers — blog posts that got tons of traffic and comments. A real statistician would also share the standard deviation for each data point.

Comments per post

So I think that not only has publishing a blog that includes comments gone out of fashion, but commenting has as well. It’s easier to link to a post from Twitter or Google Plus and just discuss it in those venues, or respond to the author of a post on Twitter rather than in the comment section. I understand the impulse, but these venues are especially ephemeral as compared to blogs or even blog comments.

I used to be pretty reluctant to comment on blog posts on other blogs, but these days if I have something to say and I’m not going to write a post about it of my own, I generally post a comment, especially if the publisher moderates the comments effectively. I do this because I see it as a way to signal my respect for the writer. I also think it’s more social.

Those of us with blogs have also always had the option of responding to posts on other blogs with posts on our own blogs. The upside is that you hopefully deliver some readers to the blog you’re linking to. The downside is that unless the writer links back to you, your commentary is probably lost on everyone who finds the blog post that is the subject of your comments later.

Maybe it’s the Twitter effect, but I find that I crave more discussion when I post something. Looking at traffic numbers is far less interesting than having a productive or enlightening discussion. For that reason, I hate that commenting appears to be on the wane.

Why’s SQL injection so prevalent?

Why are SQL injection vulnerabilities so prevalent? Because most of the PHP/MySQL documentation uses examples with SQL injection vulnerabilities and no discussion of the potential risks.

John Carmack’s beautiful code

One of my coworkers sent this Kotaku article by game developer Shawn McGrath to our internal code readers mailing list. It’s a review of the Doom III source code, describing the beautiful coding style of Id Software founder John Carmack, one of the programmers who I most respect.

It’s a thoughtful article about thoughtfully written code, and really shows the value of reading code for the practicing programmer.

One of my favorite things about John Carmack is that he has always been more of a craftsman than a theoretician when it comes to developing software. To get an idea of what I mean, take a look at his blog post on functional programming in C++, which he linked to in his comment on the Kotaku article. Carmack’s post is a far better introduction to the benefits of functional programming than the one I linked to the other day.

Aaron Swartz’s Wikipedia analytics

One less remarked upon contribution Aaron Swartz made as an engineer was his 2006 post Who Writes Wikipedia? Having heard that around 500 editors made over 50% of the edits to Wikipedia from Jimmy Wales, Aaron performed his own analysis and found that while a core group of editors made most of the edits, a much larger group of people did most of the actual writing.

In the days before it was common for every site to perform quantitative analysis user activity and publish the results, Aaron embarked on what was for its day a Big Data project, and published a surprising and interesting result that vastly changed people’s understanding of Wikipedia. This is the sort of work everyone in analytics aspires to do.

The world will miss Aaron Swartz

Add Aaron Swartz to the list of people I wish I’d met before it was too late. Cory Doctorow has written a great remembrance. When I was younger, I was obsessed with this famous George Bernard Shaw quote:

The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

I never really lived it, though. Aaron Swartz did. The world never treats those people especially well.

Older posts Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑