Strong opinions, weakly held

Page 4 of 989

Links for January 26

Look, it’s a blog post full of links!

In the New York Times, Scott Shane reviews Guantánamo Diary, which is in fact the diary of Mohamedou Ould Slahi, who has been detained at Gitmo without charges since 2002.

An attempt to definitively answer the popular interview question, What happens when you enter an address in your browser?, by Alex Gaynor.

For some reason, it never occurred to me that YouTube’s massive audience equates to massive power. Zoë Keating reports on the onerous terms YouTube is requiring her to accept in order to publish her YouTube channel.

A collection of spreadsheet horror stories from the European Spreadsheet Risks Interest Group.

My coworker Brad Greenlee has created a Mac Menu Bar App to monitor the status of running Hadoop jobs.

Luke Plant reviews iPython Notebook Essentials by L. Felipe Martins. iPython Notebook is on my list of things to spend more time with.

Paul Ford, Greg Knauss, and Kim Kardashian’s butt – you’ve probably already read this, but if not, you should.

Falling oil prices can be looked at as an interesting natural experiment in economic stimulus.

The antidote to an inflated sense of self-importance.

Let’s make link blogging a trend

I have a couple of long posts in the works. The first is some thoughts on Peter Seibel’s essay on feedback from a manager’s perspective. The other is a post that I started writing on Martin Luther King Day but didn’t finish.

Today I caught Jason Kottke’s post on link blogging, and it got me thinking about links as well. While I don’t publish as many posts as I once did, for a number of reasons, I do still churn through a lot of interesting links every day, and there a variety of places you can go to see them.

I have a link blog of sorts in the right sidebar, which just republishes my shared items from NewsBlur, my newsreader of choice. (They’re also published at rafeco.newsblur.com.) I also share a fair number of links on Twitter, and on Pinboard as well. To make things more confusing, Pinboard also scrapes all the links I publish on Twitter, and all the stories I save on Readability as well.

Maybe it’s time for me to get back to republishing those links here on the main blog.

Social skills matter for remote workers too

Everybody is talking about the New York Times op-ed, Why Some Teams Are Smarter Than Others, because everybody wants to talk about the fact that it says research shows that teams with more women perform better. My anecdotal experience aligns with the research, but I want to talk about another point that the article makes. Here’s a snippet:

Online and off, some teams consistently worked smarter than others. More surprisingly, the most important ingredients for a smart team remained constant regardless of its mode of interaction: members who communicated a lot, participated equally and possessed good emotion-reading skills.

I think that the biggest mistake people make when hiring remote workers is in thinking that remote workers don’t need to be as social as people who work in the same office. The research seems to confirm what I already thought, which is that people working remotely need to be even more communicative than people in the office. In the office, there’s really no place to hide, even people who don’t communicate that much are still in the physical presence of their colleagues. If you’re remote, it’s much easier to disappear, so it is more important to find remote workers who strongly prefer to be present in whatever medium the team uses to communicate.

Why not just hire more remotes?

Matt Mullenweg of WordPress on Paul Graham’s argument that we the government needs to grant far more U.S. visas for software engineers:

I agree that the US deserves dramatically better immigration policies, but in the meantime I’m confused with the head-in-the-sand approach most tech companies are taking simultaneously complaining that there are lots of great people they can’t bring into the US, but being stubborn on keeping a company culture that requires people to be physically co-located.

Recruiting is about tradeoffs. One of the easiest ways to expand your pool of potential applicants is to remove the requirement for physical proximity. Managing a fully or partially remote team is a different and in some ways more difficult job than managing a group of people who all show up at the same office every day, but seems more feasible than changing U.S. immigration policy to make it easier to bring more engineers from overseas to the Silicon Valley.

Glenn Greenwald in U.S. TV Provides Ample Platform for American Torturers, But None to Their Victims:

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.

Hiring the next engineer, not the best engineer

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 on Go and Swift

Code of Ages

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.

Read the rest.

Playing with Vagrant

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.

The future prospects of comments

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.

« Older posts Newer posts »

© 2016 rc3.org

Theme by Anders NorenUp ↑