Delete the last sentence

Over the years, I’ve received a lot of feedback on my writing. Some of it has been helpful, some less so. Little of it has coalesced into rules that I could easily share, but once piece of advice stands out: delete the last sentence.

I first received this advice when I was in high school. A young and idealistic NJROTC cadet ensign, I wrote several memos to our commanding officer about various incidents. I had a tendency to close with a request that he take the action I desired. Ryan Brown was remarkably kind and mature for a high school senior — instead of ignoring it or getting angry and dismissing me out of hand, he took me aside. “Cotton,” he told me, “the next time you write a memo, delete the last sentence.”

I thought of this again recently when I was replying to a message on a community mailing list. I don’t remember what the person wrote, but it was off-topic. I was going to say “This is off-topic for the devel list”, which is benign on its face, but didn’t really add anything except an implied “fuck you, go away”. My experience is that the last sentence in a reply like that is almost always inflammatory.

I get it. When you’re writing something, you want to have a good close that really drives your point home. I catch myself doing that all the time. But if you’re writing well, particularly in email, you don’t need a punchy ending because you’ve already made your point. In the above, other parts of my reply already indicated that the message wasn’t suitable for the list, and I explained why. Repeating myself there didn’t add any value to my reply, it was just repeating myself for the sake of repetition.

Google product shutdowns: a forest fire for the Internet

Google has a problem. Well, Google probably has many problems. But in a recent Ars Technica article, Ron Amadeo points out a particular problem: shutting down products frequently is harming the Google brand. Google killing off products is nothing new; some people are still mad about the death of Google Reader nearly six years ago.

Are we reaching an inflection point, though? I don’t know. I lived in fear of Google ending Google Voice, but that managed to survive despite languishing for a long time. But when I saw that T-Mobile offered a service that (somewhat poorly) replaced the Google Voice features I actually used, I switched. With the exception of Reader, none of the product retirements have affected me personally very much. I wanted to like Google+, but it never caught on. I liked iGoogle, but once it went away, I was fine without it.

Even though I haven’t personally been affected too much by Google’s ruthless culling of the portfolio, I’ve found that I’m becoming more likely to consider alternatives to Google services when they exist. Certainly if I were running a business, I would be very wary of relying on any software-as-a-service (SaaS) offering apart from the Gmail/Google Drive core.

I get that Google is trying different things and there’s a lot to be said for cutting off a project (particularly a popular one), when it’s not meeting whatever measure of success you set for it. Doing this in public is even more challenging. I don’t think this will end up causing too much harm to Google, despite mounting dissatisfaction. As long as search (and ads, of course) remain strong, these consumer services exist only as experiments in finding new ways to get ads in front of eyeballs.

What does concern me is Google’s ability to suck the oxygen out of the room. By creating a reliable, easy-to-use product, Google can eliminate the competition. Then when they shut it down, destruction is left in the wake. I’m thinking in particular of the diminished role of RSS after Google Reader’s shutdown and the drop in instant messaging (at least among my friends) after Hangouts removed XMPP support and essentially went on life support.

Neither of these can be entirely attributed to Google. The rise of Facebook as a behemoth helped, too. But the fact that Google weakened the ecosystem made it easier, I’d argue, for Facebook to swoop in and finish the job.

All told, I think Google’s product retirements are a good thing, as dysfunctional as they may be sometimes. They clear the underbrush of product offerings like a forest fire. Some of the strongest survive and the rest is made ready for new life to spring forth.

Protecting the privacy interests of others

Every so often, I think about privacy. Usually because Facebook or another large company has acted stupidly again. And I’ll admit that despite the lousy track record that many companies have, I make the choice to use their services anyway because I determine the value to outweigh the negatives. But not everyone makes that choice.

When we talk about protecting privacy, we generally talk about protecting our own privacy. But our privacy impacts the privacy of others. I got on this line of thought a while back while listening to This Week in Law (RIP) episode 440. They were talking about what happens to your digital property (e.g. email and social media accounts) after you die. While I won’t particularly care about what is said about me after I’m dead — I’ll be dead after all — it’s not just my content there.

Sometimes my friends tell me things about their lives. The most convenient way happens to be email or instant messaging. Now you can argue that these sorts of things should be discussed in a more secure manner, but that ignore the way people live their actual lives. Anyway, sometimes my friends tell me things that they wouldn’t necessarily want others to know. Secrets about relationships, desires, worries, etc.

If my accounts become available to someone else after my death, then so do the messages sent in confidence to me. And just because my friend felt comfortable confiding in me, that doesn’t necessarily mean they’ll feel comfortable with my estate knowing their secrets.

It’s a tricky situation. A generation or two ago, these sorts of things would be communicated in person, over the phone, or by written letter. Only the last of these would leave a record of the content, and even then they’re likely destroyed fairly soon. The ability to cheaply store communications en masse is both a blessing and a curse. Neither law nor societal norms have yet come to terms with this new world.

Product roadmaps are inferior to product forecasts

“It’s on the roadmap” was a common expression when I worked in customer-facing roles. That statement is a delightfully vague response to feature requests. It might mean “it will be in the next release.” More often, it was as close as I could get to saying “yeah, there’s no way in hell we’ll ever get around to implementing that” without getting myself in trouble. Cowardly? Probably. But at least it was tactful.

At a previous company, we did actually have a product roadmap. It looked forward through the next year, broken down by quarter. The first quarter was generally pretty accurate, even if some of the work slipped a bit. The second quarter was okay. The third and fourth quarters? Well they didn’t really reflect anything approaching reality.

I suspect we were not unique in that regard. Perhaps that’s why it’s so easy to find product managers breaking up with their roadmap. It’s why roadmaps became a metaphor for an Uber ride in a Denver blizzard. It’s why a two month project that ships three years later makes an instantly-relatable comic.

But for me, it’s all about how the road map is used. “Road map” is a pretty lousy term, when you think about it. I spent a lot of time looking at road maps as a kid (I’m so cool!) and they almost always gave an accurate representation of what was coming a mile or a hundred miles ahead. Product road maps, if taken that way, lead to lies and broken promises.

For me, a better framing is a product forecast. When the National Hurricane Center forecasts hurricane tracks, they don’t just draw a line and call it a day. The forecast graphic shows an area of uncertainty that expands with time. When a storm is a few hours offshore, you can generally be fairly certain where it will make landfall. When it is days away, the potential landfall area is much larger.

Example hurricane forecast graphic from the National Hurricane Center

The analogy isn’t perfect, of course. Products can pivot much faster than hurricanes can. And storms are things that just happen to us, whereas the product is something we can consciously effect. But in general, I like this idea. In the short term, you know what you’re working on and what you’ll be able to deliver. Beyond that, you know where you’d like the product to go, but something may happen between now and then to change it.

I like the “Yes, No, Maybe” model that Ben Balter wrote about last year. In his post, Ben limits the roadmap to the next three months and categorizes work as “yes we’re doing that”, “no we’re not doing that”, and “maybe, but we need more information”.

The advantage of the three-month window is that it prevents the roadmap from becoming a giant lie. But extending a product roadmap (or forecast) beyond three months helps give some context to the work being done in the short term. People benefit from having a longer-term vision, even if they change direction before they ever reach it. Forecasts are wrong sometimes, but they represent the view of the future from the best information available at the time.

Other writing: March 2019

What was I writing when I wasn’t writing here?

Stuff I wrote

Fedora/Red Hat

Opensource.com

Lafayette Eats

  • Bru Burger Bar — Lafayette’s newest burger restaurant is off to a great start.
  • Fishya — Lafayette has more sushi restaurants than you might expect.

Stuff I curated

Fedora/Red Hat

Where to file an issue?

Recently, the Fedora Engineering Steering Committee (FESCo) entertained a proposal to allow people to file issues in the repo where Fedora RPM spec files live. They ultimately rejected the proposal in favor of keeping those issues in Red Hat Bugzilla. I didn’t weigh in on that thread because I don’t have a set opinion one way or another, but it raised some interesting points.

First, I’d argue that Bugzilla is hostile for end users. There are a lot of fields, many of which aren’t meaningful to non-developers. It can be overwhelming. Then again, there probably aren’t too many end users filing bugs against spec files.

On the other hand, having multiple places to file bugs is hostile for users, too. “Where do I file this particular bug? I don’t know, I just want things to work!”

Having multiple places for bugs can be helpful to developers, so long as the bugs are filed in the right place. Spec file bugs make sense to be filed in the same place as the spec files generally. But they might make more sense elsewhere if they block another bug or fit into another workflow. And the odds of a bug being filed in the right place isn’t great to begin with.

This is a question for more than just Fedora though. Any project that has multiple pieces, particularly upstream dependencies, needs to think about how this will work. My take is that the place the user interfaces with the code is where the issue should be filed. It can then be passed upstream if appropriate, but the user shouldn’t have to chase the issue around. So if an issue manifests in my project, but the fault lies in upstream code, it’s my responsibility to get it fixed, not the user’s.

So now that I’ve typed all this out, I suppose I would argue that issues should be enabled on src.fedoraproject.org and that it’s the package maintainer’s responsibility to make the connection to Bugzilla where required.

Book review — Bobby Kennedy: A Raging Spirit

Who was Robert Francis Kennedy? To me he was always primarily JFK’s brother. That’s not fair, of course. Bobby Kennedy was an accomplished man — campaign manager, Congressional counsel, attorney general, senator, and presidential candidate. Fortunately for me, I recently grabbed Chris Matthews’ Bobby Kennedy: A Raging Spirit (2017) from my local library.

In A Raging Spirit, Matthews explores what made Bobby Kennedy the man he was. Matthews explores how Bobby related to his parents and to the other Kennedy kids, particular older brothers Joe, Jr. and John. What I found missing was his other family relationships. His wife Ethel and their 11 children make only minor appearances in this book. While we know Kennedy’s professional life, we’re left to know what kind of husband and father he was.

It’s clear that Matthews has a deep respect for this subject, but the book is not a hagiography. We see how Kennedy’s desire to support the civil rights movements was tempered by his disagreement with Dr. King’s non-violent protests and his concerns for the political impacts in southern states. His caring and empathetic nature — perhaps a surprise given the wealth and privilege he was born into — often appeared after his fierce and tempestuous side. Matthews gave several examples of times when Kennedy would initially react with anger, only to soften over the next few days as he gave further consideration to a matter.

Bobby Kennedy: A Raging Spirit is a fascinating look at an influential figure of the mid-century who is too often overshadowed by his brother. It is a well-researched book that nevertheless reads lightly and quickly. The main narrative weakness is the occasional interjection of personal anecdotes from the author. Nevertheless, I recommend this book to anyone who is interested in learning more about the man some have called America’s greatest attorney general.

Open Source Leadership Summit 2019

Ed. note: my employer is a member of the Linux Foundation. The views in this post are — as are all posts on this site — my personal views and do not represent my employer or any other organizations. You knew this already, but I thought it would be good to remind you.

Last week, after leaving SCaLE, I headed to Half Moon Bay, California for the Open Source Leadership Summit. It’s an invitation-only conference run by the Linux Foundation. This year it was held at the Ritz-Carlton Half Moon Bay, a very nice resort hotel with an ocean view. This was dramatically different from most tech conferences I’ve attended previously. That difference was the source of some internal struggle I wrestled with. I’ll get to that momentarily, but first my more general thoughts.

This is clearly not a typical tech conference. The number of technical sessions was pretty low, with a greater focus on topics like marketing, balancing corporate & community interests, mentoring, et cetera. Given that the target audience is leaders of corporate open source efforts, this makes sense. The talks I attended were good, with Jim Perrin’s “Damaging your project with management (and leadership)” as my clear favorite. The downside is that with 30-minute time slots, I didn’t feel like there was ever enough time to really get deep into any of the topics. That might be better for the state my attention span was in after over a week of travel and conferences, but it’s not great for getting a lot of value out of the talks.

The marketing panel that I was on was well-received. I thought we did well. Panels can be terrific or terrible and I’d like to think we were closer to the terrific end of the spectrum. All of the panelists had different, complimentary experience, so we were able to give non-repetitive answers. And we all kept our answers pretty short so that the conversation could flow. The audience was into it, as well, which always helps. And I’m glad to say that “Jennifer”s outnumbered men.

So now for my internal struggle. I saw the conference referred to as “open source Davos” and it’s hard to disagree with that. Jessie Frazelle was unrestrained in her criticism:

Coming on the heels of Bradley Kuhn’s “It’s a Wonderful Life” analogy at SCaLE, this criticism really stuck out to me. Yes, I get paid well to work on an open source project, but I still live in a world where staying at a resort like the Ritz-Carlton Half Moon Bay leaves me wide-eyed. How many tech conference travels could we have funded with the budget for lunches? How much test gear could be provided for the cost of the evening socials? Why is it called “Open Source Leadership Summit” when the leaders of major open source projects aren’t invited to attend?

Well the answer to that question is “this isn’t the sort of leadership we meant”. A friend said this is the sort of event that corporate execs and senior management attend. If you want to get your message to them, that’s what you have to do. I understand that argument, and the practical side of me gets it. The ideological side of me says “well then we’ll do it without them!”

The Linux Foundation and similar foundations are trade associations, not charities. They’re not obligated to act in the public good. Maybe they could stand do to a little more of that, obligated or no. But ultimately, they’re doing what trade associations do. They advance their corporate interests in the way they see fit. If we want to redirect them toward community benefit, maybe pitching talks that give the message we want them to hear is the approach to take. Or maybe that’s just what I’ll tell myself to justify going on a junket.

SCaLE 17x

Last week, I attended the 17th annual Southern California Linux Expo (SCaLE 17x). SCaLE is a conference that I’ve wanted to go to for years, so I’m glad I finally made it. Located at the Pasadena Convention Center, it’s a short walk from nearby hotels, restaurants, and a huge independent bookstore. Plus the weather in southern California almost always beats Indiana — particularly in March.

Having done this a few times before, the SCaLE organizers know how to put on a good event. Code of Conduct information, including contacts, is prominently posted right as you walk in the door. Staff walk around with t-shirts that sport the WiFi information. The break between sessions is 30 minutes, which allows ample time to get from one to another without having to brush people aside if you meet them in the hallway. It was an incredibly-well run conference.

I ended up in the “mentoring” track most of the weekend, which I suppose indicates where I am in this point of my career. “Mentoring” may not be the right word, though. The talks in that room covered being a community organizer, developer advocacy, and a lot about mental health. Quite a bit about mental health, in fact. It’s probably a good thing that we’re discussing these topics more openly at conferences.

The talk that stuck with me the most, though, was one I saw on Sunday afternoon. Bradley Kuhn wondered “if open source isn’t sustainable, maybe free software is.” Bradley compared the budgets and the output of large corporate-backed foundations and smaller projects like phpMyAdmin. I’ll go deeper on that later, either when I recap the Open Source Leadership Summit or in a standalone post.

Bradley also used an “It’s a Wonderful Life” analogy, which is very much my kind of analogy. This may become a longer post at some point, but the general idea is that we have a lot of Sam Wainwrights in the world: people who are willing to throw money at a problem (perhaps with strings attached). Despite being well-meaning, they’re not actually doing that much to help. What we need is more George Baileys: people doing the small but critical work in their communities to help them thrive.

SCaLE was a terrific conference, and I’m looking forward to going back in the future. Especially now that I’ve learned my way around the food scene a little bit.

Don’t celebrate feeling stupid

I recently saw a tweet that offered advice to new Microsoft employees:

My initial reaction was that this is very true and also bad. I said it was a sign that the onboarding process is broken. But there’s more nuance to it. I want to draw a distinction between not knowing all of the pointy ends of a job and not knowing how to do the tasks necessary.

The former is good for personal growth. I wouldn’t want to take a job that I already know exactly how to do; I won’t learn that way. And even when you’ve done the job somewhere else, each organization has unique nuances that it takes time to learn.

Where it gets troublesome is when the difference between what you’re asked to do things you haven’t been taught how to do. Here I mean the internal processes and tooling, not the general act of doing it. It’s reasonable to expect a marketing person to know how to write a blog post; it’s not reasonable to expect them to know how to submit it through your internal tooling.

Perhaps that’s not what Carmen meant, but it’s certainly what came to mind for me. When I joined Microsoft, we had no documentation for what was expected of people in my role and no documentation for how to execute those tasks. So I would have people coming to me for things that I had no idea how to do — or even what they were. In my time there, I tried to document as much as I could so that the next person who joined the team would have a less stressful onboarding experience than I did.

But even if Carmen was talking more about the “not knowing the pointy ends” scenario, it occurs to me that this may not be healthy. Personal growth is great, but if the difference between what you know how to do and what you’re expected to do gets too large, it’s no longer growth — just stress. People I spoke to at Microsoft seemed to embrace the “you’ll feel stupid” part, and maybe that’s unavoidable, but it’s not a good thing to embrace.

In a talk at the Southern California Linux Expo last week, Jono Bacon said something that really stuck out to me. “[Burnout and stress] is a topic that isn’t talked about enough. In our industry, particularly in Silicon Valley, stress is glorified and that’s stupid.” If you’re in a position to help with onboarding new hires, give them the tools to know how to do their job so they can learn how to do their jobs.