Fighting for the Web we should have
0

Fighting for the Web we should have

If there’s one person who I feel really said the things that need to be said in 2015, it was Maciej Cegłowski. He gave a number of talks last year, and posted transcripts of them so that we can all read them and get smarter. The theme is common across all of them – that preserving a Web we can be optimistic about is going to take work and directed effort.

Here are the three talks from last year:

  • The Website Obesity Crisis – why Web pages have gotten so huge, and why slow download speed isn’t the only reason this is a problem
  • Haunted By Data – why collecting tons of data about your users’ activities and storing it forever is a bad idea
  • What Happens Next Will Amaze You – privacy and corporate surveillance on the Web
  • Special bonus: Web Design: The First 100 Years – this one is actually from 2014, but don’t miss it. “What if instead of dreaming about changing the world with tomorrow’s technology, we used today’s technology and let the world change us?” Sounds pretty great.

Working “in the industry” these are the oftentimes unacknowledged challenges we face every day – it’s easy to discount the total impact of the decisions we make about how to build Web pages, or how long we retain behavioral data, or what kinds of advertising we choose to purchase. I’m glad somebody brought it up.

Answering the question: should managers code?
0

Answering the question: should managers code?

One question I’ve been grappling with lately as we’ve been interviewing manager candidates has been, how much programming do we expect an engineering manager to do? It’s an important question, because most engineering managers started out as engineers, and most engineers got into the profession to write code. In a recent post, Cate Huston gets at why it’s difficult letting go:

There’s something we all talk about in becoming a manager – and that’s the process of writing less code. We bemoan it because it’s hard to let go of that part of our identity. But also because it’s so quantifiable. Today I wrote X lines of code. Today I deleted Y lines of code. Today I implemented feature Z. Concrete achievements are reassuring. Today I left the codebase better than I found it. Good job.

Read the whole post, it’s really good.

One interesting part of being a manager of managers is that it’s part of your job to set the larger team’s expectations around managers writing code. When you’re hiring managers, it’s also really important to give candidates a proper sense of what will be expected of them on the job. Some candidates really want to keep writing code, and others may not have the coding skills to be hired as an individual contributor on the team any longer. It’s up to the hiring manager to figure out what will work for the team.

What individual contributors really want is someone who could probably do their job and who can help them solve hard technical problems one on one, but will embrace the role of facilitator and avoid creating situations where their desire to code is a blocker. Perhaps most importantly, they don’t want a micromanager who will second guess all of their decisions but they do want someone who can help them improve their craft.

It’s also true that understanding the stack is really useful for managers as well. It helps to be able to explain your team’s work effectively when working with other teams. It’s fun and useful to help individual contributors solve technical problems as well as people problems. As a manager, you also have the privilege of working really closely with excellent engineers. It would be unfortunate not to learn from them.

So I’ve been working out a rule of thumb that captures how a manager (or would-be manager) should think about programming as part of their job, if that job is managing one of the teams that ultimately reports to me. That rule is:

A manager actively avoids creating situations where their coding is necessary for the success of the project.

That leaves a lot of leeway for managers to pick up technical skills and do some coding within the confines of their schedule. There’s always a long list of things that would be nice to have or tasks that crop up that aren’t project work and if managers want to do some of this work, so much the better. It’s a great way to learn and it helps the team focus on the big stuff. At the same time, it establishes a clear line between a manager, even a “technical” manager, and a tech lead. It should also keep the manager out of the way of the individual contributors.

Regardless of your philosophy, as a manager of managers, if the teams that report to you don’t have a clear understanding of what’s expected of managers as technical contributors, it’s going to become your problem at some point, and will end with people being profoundly unhappy with their jobs.

I should also add that one skill really good managers have is knowing how to surf this wave – applying their technical skills when it really counts and keeping their distance when that’s what the team needs. If things are really working, maybe it’s best for you not to be a micromanager and to let the team work it out among themselves. Nobody ever said this job is easy.

What’s up with the blog?
0

What’s up with the blog?

Have I really not written a blog post since October?

It’s probably worth discussing what’s been going on with my blog for the past four years or so, and why I’ve been so much less prolific in recent years than I was in years prior.

One answer came to me not long ago when one of my colleagues asked on Twitter about the value of blogging. After thinking about it, I realized that one of the big reasons is that I was trying to generate the kinds of conversations I wanted to participate in. I hadn’t found a venue for these conversations in the offline world, so I wound up trying to create it online.

These days, I have the benefit of having a job at Etsy where many of the technical conversations I once had to go online to find are happening every day. If I want to talk about the ins and outs of engineering management, or the difficulties of releasing an internal tool as open source, or the pros and cons of typesafe languages, I can just grab someone at work and hash it out. Talking about this stuff in the offline world has consumed some of the energy that I once channeled into the blog.

Another complication is that as a manager, management is one of the topics I really want to write about. Unfortunately, it takes extra care to write about management in a way that doesn’t generate anxiety at work. I don’t want to air people’s dirty laundry here, even anonymously, and more importantly, I don’t want to give people them impression that I’m writing about them when I’m not. The person who was the subject of this post read the post, and it wasn’t hard for them to figure out it was about them. Oops. I probably should have told them about that in person rather than blogging about it.

Finally, over a very long period of time, as blogging has become more popular and more professional, I’ve become less willing to air my dilettantism publicly. I once wrote frequently about ecomics and politics without self-consciousness, but I don’t feel very comfortable doing so any more. The world is full of too much armchair analysis by the underinformed. I don’t enjoy feeling like another noisemaker.

There’s plenty of room out there, though, to write about things I do know about, and I do plan to write more. I just thought you might be interested in why I haven’t written as much lately.

Further reading on just culture and blameless post mortems
1

Further reading on just culture and blameless post mortems

Here’s the reading list to accompany my Monktoberfest talk on just culture, blameless post mortems, and local rationality.

The talk was very much inspired by Sidney Dekker’s fantastic book The Field Guide to Understanding Human Error. Here’s a short video where he explains Just Culture. There’s also a PDF of an old edition of the book available online.

The rationale and methodology for post mortems at Etsy are explained in Blameless PostMortems and a Just Culture, written by John Allspaw in May 2012.

Daniel Schauenberg, an engineer at Etsy who serves as a post mortem facilitator, wrote up our process in Practical Postmortems at Etsy for InfoQ.

The source code for Morgue, Etsy’s post mortem tracker, is available on GitHub.

This talk was in part based on a post I wrote last year, also entitled Management is not about sorting apples.

Other links:

The theoretical underpinnings of Etsy
0

The theoretical underpinnings of Etsy

Kellan Elliott-McCrea, the CTO of Etsy for my entire time at the company, writes about the theories under which Etsy’s engineering team, as we know it, was constructed. It has traveled a whole lot further than he could have predicted:

Five years ago, continuous deployment was still a heretical idea. The idea you could do it with over 250 engineers was, to me at least, literally unimaginable.

Etsy has been the validation of many theories that still must seem heretical to many people, and I want to thank Kellan for the part he’s played in formulating them and seeing them tested in production.

Better interviewing through psychology
1

Better interviewing through psychology

If you are a person who is responsible for interviewing engineers, or more importantly, running an interview process for engineers, you should drop everything and read Ann Harter’s discussion of interviews through the lens of research psychology. It’s also useful for people who are the subjects of interviews and are surprised by the way their brains work in interview situations. As an industry we are shockingly bad at evaluating candidates for engineering jobs and the Dunning-Kruger effect is rampant. Let’s get better.

Critiquing Amazon’s corporate culture
0

Critiquing Amazon’s corporate culture

Here in management-land, the New York Times story on workplace culture at Amazon has been the talk of Twitter for the past few days. The story paints an ugly picture of hyper-competitiveness, unreasonable demands, and exploitation that have caused many people to recoil (and some others to applaud).

I’m certain that the article isn’t comprehensive. It probably isn’t even fair. It’s a critique, and should be taken as such. I really liked Ellen Chisa’s explanation of why Amazon and Jeff Bezos should not take it personally.

Update: Ezra Klein’s followup is noteworthy:

But it’s important not to lose sight of a more urgent reality: As bad as white-collar workers may have it at Amazon and elsewhere, their blue-collar brethren have it much, much worse, and have much less power to negotiate better conditions.

APIs and accountability
0

APIs and accountability

I love Twitter, but I’ve been unhappy with the company since they made the decision to stop supporting third party clients that compete with their own native clients. There are still some good ones available, but Twitter has actively discouraged the development of new clients by not adding third party API support for many new features, and by limiting the supply of API keys to client developers.

In the meantime, Twitter has let the native OS X Twitter application languish. Here’s Jason Snell:

If Twitter doesn’t have the resources or inclination to properly support platforms like the Mac (or, quite frankly, iOS and Android), perhaps it should rethink the decisions made by the prior regime and find a way to let other developers apply their expertise to the problem. Alternately, maybe Twitter should figure out how to use its huge team of app developers to create first-class native apps for not just iOS and Android, but the Mac and Windows too.

It’s not a coincidence that Twitter’s updates to its OS X slowed when they decided to cut off third-party clients. The third-party client market provided two things Twitter desperately needs, competition and free research and development. When the Twitter client market was healthy, there were dozens of development teams coming up with cool new Twitter features that the company could roll into its platform. Many of the features that are core to Twitter now originated in the Twitter community.

A fully functional API that third parties can use imposes a sort of accountability on a company’s engineering team. Giving users a choice of clients or tools demands that the product team at Twitter builds applications that can succeed on their own merits. Competing with third-parties on their own platform is the sort of exercise Twitter needs to stay in shape for the bigger fight with Facebook, Instagram, and whatever else comes along in the future. Killing off that competition has enabled Twitter to be lazy and complacent.

A counterargument one might make is that supporting a full-featured API for third parties is expensive, but I’m not sure that’s the case. Twitter already has, in addition to its Web site, iOS and Android apps, and an OS X app as well. What this means is that Twitter already provides private APIs for all its features that support multiple independent client implementations. In other words, the hard work is already done. Given Twitter’s size, chances are they’ve already put a lot of thought into API usability and written decent documentation for these APIs as well.

The risks of providing robust APIs are minimal. A relatively small number of users are going to seek out and install third-party applications even if they are great. The tangible and intangible benefits are large. Twitter needs to get back into being a platform provider for its own sake.

This Is My Jam is shutting down gracefully
0

This Is My Jam is shutting down gracefully

I’m sad to see the site This Is My Jam shut down, I found it to be a pretty fun way to share a little music with people you know from Twitter and to be a good source of inspiration for new music to try. In shutting down, they are setting the standard for how social sites should be taken offline in an ideal world. The details:

This Is My Jam will become a read-only time capsule in September. This means you won’t be able to post anymore, but you’ll be able to browse a new archive version of the site. You’ll be able to explore all the people and music that made Jam, and listen to everyone’s jams as Spotify playlists as well. Think of it as the best record collection you’ve ever walked through, like this, curated by some of the best tastemakers we know (aka you!).

You can also export your data or opt out of the archive. Companies shut down all the time, or just retire old features. This Is My Jam is establishing a pattern for how this can be done in a thoughtful way that shows respect for the contributions of users over time.

Why are they shutting down? Here’s a big reason:

But keeping the jams flowing doesn’t just involve our own code; we interoperate with YouTube, SoundCloud, Twitter, Facebook, The Hype Machine, The Echo Nest, Amazon, and more. Over the last year, changes to those services have meant instead of working on Jam features, 100% of our time’s been spent updating years-old code libraries and hacking around deprecations just to keep the lights on.

Unfortunately, everything has to be maintained. Even if you’re not adding new features, there’s work to be done, especially when you’re integrating with third parties. This is why features on sites that aren’t actively maintained get worse over time rather than staying the same. Designs get stale, shared dependencies get upgraded, and things break in subtle ways. Entropy is real. This is no knock on This Is My Jam, it’s a reminder to everyone else in the Web business that ongoing maintenance can’t be avoided, even if a feature or site isn’t under active development.

I’ll miss This Is My Jam, but I’m grateful for their leadership and openness.

The expansiveness of YouTube
5

The expansiveness of YouTube

Last fall, when I was interviewing intern candidates, one thing I noticed was that many of them told a similar story – when they needed to acquire a new skill, they watched tutorials and lectures on YouTube. One had an internship the previous summer working on a C++ project, and she told me that she watched C++ videos every morning before work in order to get up to speed quickly.

I’m also interested in the phenomenon of unboxing videos. These seem to serve two purposes, the first is to provide a vicarious thrill to watchers. People record themselves opening packs of baseball cards or other collectibles with the hopes of getting a rare item. The more practical purpose, though, is showing people exactly what they get when they make a purchase. Product photos can be deceptive, and unboxing videos can give you a better idea of what a product is like.

Finally, there are huge numbers of conference talks and lectures available online. If you want an intro to Docker, or an interesting scaling case study, or a survey of the current state of application security, the talks are out there.

I lead a text-oriented life, but while I was reading, a huge amount of compelling video was produced and published. I find that when I watch video, it’s easier to avoid distraction than it is when reading big chunks of text. Besides, even if I switch away from a video for a few seconds to catch up on Twitter, the audio still continues in the background, so maybe even the distractions are less distracting.

Now I’m trying to retrain myself to search for video first as an information source. As a member of the generation that was raised by television, you’d think this would come to me more naturally.