The Daily Beast reports on Uber’s argument that it is exempt from disability laws, because it’s a tech company rather than a transportation company. The other day I wrote about Uber, and I still have complicated thoughts about the company. What I think is that the market is full of companies that seek to save money by evading regulation, and it’s up to us as voters to elect politicians who are serious about enforcing them.
Trevor Timm tells the media to quit dismissing Seymour Hersh and to start following up on his reporting on the holes in the official account of how the CIA found Osama Bin Laden. While there are many elements of Hersh’s story that seem implausible, some details of the official account are implausible as well. The implications of the differences between the official’s account and Hersh’s reporting are important:
Hersh’s assertion, which has by now been at least partially confirmed by multiple news organizations, that bin Laden was found thanks to a “walk-in” tip—rather than by tracking his courier as the government has claimed—should be a major scandal. For years, the CIA has said it found bin Laden thanks to information about his personal courier—information that was obtained by means of torture.
There’s much in the story that Hersh reported that seems likely to be wrong to me, because it just doesn’t make sense. What I wish, though, is that reporters would dig into the story itself rather than going all in on the top item on this list of fallacious arguments.
This week’s don’t miss article is Emily Guendelsberger’s look at what Uber drivers really make for the Philadelpha City Paper. The article is well-researched and well-reported. It’s also an entertaining read. Even if you don’t use Uber at all, its business model is being emulated throughout the service industry, and the company’s future is tightly entertwined with the future of ground transportation in general.
The article also captures the conundrum that transportation consumers face. It’s very convenient to land in a strange city and know that you an get a ride wherever you want to go using the Uber app, and that successfully communicating with the driver about where you’re going is not necessary. There’s no excuse for ever drinking and driving if you are in a city where Uber is available. And, of course, thanks to cutthroat price competition, Uber is cheaper than ever in most places.
On the other hand, Uber’s management is pretty revolting, and their relationship with their drivers becomes more and more exploitative over time. They company also ignores the law in many cities, and is encouraging large scale insurance fraud. Knowing that taking an Uber car means supporting Uber the company offsets the convenience that they offer.
It remains true, though, that for the most part, taking a regular cab often isn’t any better. The work of a traditional cab driver is also full of exploitation across the board. A cab driver in San Francisco told me that he pays to rent his cab, tips the guy who runs the garage to put him in a decent car, tips the dispatcher to send fares his way, and generally tips one or more hotel doormen so that they call him instead of other cab drivers.
Finally, if you care about the environment and quality of life in urban areas, you have to hope that it becomes easier and easier for people to live without owning their own car. Bike lanes, better public transportation, and walkable, mixed-use neighborhoods are all part of it, but cabs are a part of it as well, and for the most part, taking an Uber is a much more pleasant experience than taking a traditional cab from the moment you decide to take a cab until the car drops you off.
I hope that Uber changes its business practices, either voluntarily, or because the government compels it to do so, but I am certain that Uber (or other companies like it) are a big part of the future. With some changes, I think that’s a good thing.
Here’s one thing I think about when I’m evaluating candidates after interviewing them – do I want to have 100 one on ones with this person? One hundred one on ones is roughly two years, which is probably roughly the minimum amount of time you’d expect someone to work with someone, assuming it isn’t a disaster. To me, this question is a reminder of the commitment one makes to a person’s professional well being when they hire them.
The catch, of course, is that there’s some overlap here with the idea of hiring for “culture fit.” There are a lot of ways to think about culture fit, and that many of them amplify the patterns that limit diversity in the tech industry. However, when you hire someone for your team, it’s the beginning of what will ideally be a long relationship, one that requires good communication and trust on both sides to be effective, and some personal chemistry really helps.
This thought experiment works both ways. When you’re interviewing for a job, if you meet your future manager, how do you feel about the idea of having 100 one on ones with them? It doesn’t matter how great a company is, reporting to a bad boss is going to ruin your experience there. Is this someone you can trust? Is this someone you can stand? Think about what you’re signing up for.
Here’s the answer to a question I always had, what shows like The Daily Show use to catalog the video clips they use. Their ability to put together segments containing salient clips from years of past footage consistently amazes. Turns out, there’s a server appliance called SnapStream that records and organizes the content.
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.
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.
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.
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.
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.