The pleasure of building big things
0

The pleasure of building big things

Accomplishing big things takes a long time, even in the modern world of software. I was reminded of that today when I read Mike Kruzeniski’s post Jony’s Patience. Here’s the crux of it:

I doubt that it took 20 years for Ive to come up with the idea for the Watch, or to find the right design for it. For the past two decades, Apple and Ive have been carefully building a company that’s capable of building the Watch. That’s 23 years of finding talent, hiring the right people, building the right teams, developing relationships, investing in skills and technologies, establishing manufacturing and distribution, and proving out the products and business models. Ive’s patience to grow with Apple over the last two decades allows him to design the greatest products in the world today.

In a world of accelerators and frameworks and cloud services, the reminders that you can build significant companies and products very quickly are all around us. It’s worth taking a step back to remember that the really big jobs take a long time. Soon we’re going to launch a big infrastructure project at work that has been about a year in the making. In December, I gave a talk on the years of foundational work that put us in a position to even start on this project. After we launch, we’ll have a number of new capabilities that will enable us to build some stuff that has been on the drawing board for years.

Quick wins are great, but there’s something uniquely satisfying about companies, teams, products, and infrastructure evolving together into new things that can only be created with years of effort.

A hiring process that doesn’t suck
0

A hiring process that doesn’t suck

One thing that becomes apparent as you progress through a career in software engineering is that the hiring process for software engineers is pretty bad across the entire industry. Some companies are vastly better than others, but in general, most don’t even do much work to evaluate the overall effectiveness of their hiring process.

What I liked most about Thomas Ptacek’s post on what they’ve learned about recruiting at security consulting firm Matasano is that they have taken a deliberate and thoughtful approach to building a hiring process. You may disagree with some of the things that they do, but you have to respect their efforts to design a process that works for them.

He makes plenty of trenchant obseverations about the problems with hiring as it is traditionally approached. For example, his reminder that being good at interviews is a skill unto itself, separate and distinct from the skills associated with being a good software engineer is often forgotten when candidates are evaluated. The goal of the recruiting process is to hire people who will be good team members, but it’s very easy to wind up hiring people who are just good at getting hired instead. The ideal processes discovers the true capabilities of the candidates regardless of how proficient the candidate is at bringing them up on their own.

Another factor that, if left unaccounted for in the hiring process, vastly reduces the quality of the outcome is unconscious bias. Not only does it lead to poorer hiring in general, it has a devastating effect on diversity. He doesn’t mention diversity in the post, everything in section 7 of the post should mitigate against the effects of unconscious bias when evaluating candidates.

His approach to phone screens is really smart. Rather than using the phone screen to try to assess the technical abilities of the candidate, he suggests using it to talk to the candidate about the team, the company, and the job, and to give them a clear impression of what subsequent interviews will be like. Personally, I hate asking programming questions over the phone, and never ask them during phone screens. I can generally get what I need from the candidate to figure out whether to proceed without doing so.

Finally, I just want to applaud the approach of structuring the interview process to reduce its adversarial nature. Obviously, the goal of the interview process is to explore a candidate’s knowledge, skills, and demeanor, but the best way to do that effectively is to make them comfortable and enable them to present themselves at their best. All too often, interviewing can be about the ego of the interviewer rather than learning about the person being interviewed. I’m glad when anyone takes steps to stamp this out.

Links for February 28
1

Links for February 28

It’s been a month since my last link blog post. That’s terrible.

Why is Google interested in owning the entire “.dev” top level domain?

Business Insider has a long piece on the downfall of Fab and its CEO. He turned a bad idea (yet another social network) into a good idea (flash sales of interesting goods) and then implemented a strategy that wasted tons of money and ultimately killed the company. Strategy matters.

It seems like everyone in the analytics infrastructure world is talking about stream processing. Martin Kleppmann’s post is a good starting point.

Will Yager explains why Go is not a good programming language. My main takeaway was that I don’t know or use any good programming languages.

The government can compel companies to disclose information about users and then prohibit them from reporting that they have done so. However, they are able to report that they have never been subjected to such a request. Such statements are referred to as “warrant canaries.” The EFF’s Canary Watch tracks companies that have issued these warrant canaries.

Jocelyn Goldfein explains how to ask for a promotion. Her blog is an excellent resource for all things HR-related in tech.

Branko Milanovic explains why human capital is not actually a kind of capital, and why the use of the term is harmful.

Jason Punyon’s explanation of what went wrong on the Providence project at Stack Exchange is a useful dose of reality for people making technology choices. The kinds of mishaps he describes are incredibly common and rarely discussed openly.

Don’t pile on
1

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
0

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
1

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
1

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
0

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
1

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.