Strong opinions, weakly held

Page 4 of 989

Don’t pile on

Originally I was just going to post a link to Jon Ronson’s New York Times piece on the tendency of people on the Internet in general and Twitter in particular to pile on. His piece is mostly about Justine Sacco, who famously posted an offensive (and possibly widely misconstrued) tweet before her 11 hour flight took off, and landed to potentially the most epic pile on in recent memory.

I had lots of thoughts when reading the piece, but one of those thoughts was that Sam Biddle is an irresponsible jerk. In fact, when I was done reading the piece, I wanted to tweet that Sam Biddle is an irresponsible jerk. The truth is that I don’t know whether he’s a jerk or not, and my opinion of him and his work is ill-informed and irrelevant. I didn’t even read the Gawker posts that were referenced in the article, and yet I was eager to pile on Sam Biddle to call him out for piling on Justine Sacco. I’m not sure what impulse that would have satisfied, but it wasn’t a healthy one.

This week, everybody’s piling on Vivek Wadhwa. I can see why, too. I agree with just about everything everybody who’s piling on is saying. I don’t think it’s healthy, though. Stating your principles and defending them is difficult and meaningful. Joining a herd of people piling on the jerk of the day is cheap and easy. Let’s not.

Engineering management homework: define CTO

Two attempts to define the job of a CTO, one by Camille Fournier, from Rent the Runway, and one from Greg Brockman, from Stripe.

The bottom line from Camille:

My advice for aspiring CTOs is to remember that it’s a business strategy job, first and foremost. It’s also a management job. If you don’t care about the business your company is running, if you’re not willing to take ultimate responsibility for having a large team of people effectively attacking that business, then CTO is not the job for you.

Greg’s post is more about how to adapt within your job to say happy and productive in a rapidly changing company. One thing’s for sure, it sounds like Camille is probably writing a lot less code than Greg.

I think that Camille’s description of a CTO is actually a solid description for any engineering management job, at the scale at which the manager works. Managers should be thinking about the business strategy for their team, and should take responsibility for applying the resources they can muster toward that business.

Links for January 28

(by way of @scienceporn)

The news story of the week is the Greek elections that put the left wing anti-austerity Syriza into power. The Economist has a useful article on the implications for the broader Euro-zone. As Paul Krugman explains, the austerity measures Greece has imposed at the behest of the institutions that bailed it out have been ruinous for the Greek people. The best overall article I’ve read on what happens next is from the New Yorker’s John Cassidy.

SoundCloud has released a new, open source timeseries database and monitoring system called Prometheus. It’s an interesting amalgam of Graphite, Statsd, Nagios, Grafana, LogStash, and probably other things as well. It will be interesting to see if such a comprehensive tool will catch on.

For the record, poor people taking out mortgages they couldn’t afford were not responsible for the housing crisis.

Judging from what I’ve seen on Twitter, the McSweeney’s bit Reasons You Were Not Promoted That Are Totally Unrelated To Gender is resonating for a depressingly large but not unsuprisingly large number of women.

Article I wish someone would write – a think piece on weather forecasting, hype, and cynical reactions to missed forecasts. This blog post by Washington Post weather editor Jason Samenow gets pretty close, just ignore the inflammatory headline.

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.

« Older posts Newer posts »

© 2017 rc3.org

Theme by Anders NorenUp ↑