What’s routine to you is interesting to others

One thing about humans is that we’re really good at habituating. It doesn’t take long for something new to become normal. This really came to mind last month when I presented a pair of talks at the DevConf.cz conference in Brno, Czech Republic.

One of my talks was a 25-minute presentation on project management in community projects. As I was putting the talk together, I started thinking “this is a nothingburger.” Twenty-five minutes isn’t enough to give any useful depth of information. So all I’m doing is giving a basic description of my job.

As it turns out, “nothingburger” was the exact hunger level of the audience. When I asked the room, only three people or so said they were professional project or program managers. An intro-level talk was exactly the right target. Doing the work every day, I forgot that it’s not everyday for other people. Even people who do related work might find something worthwhile out of it.

l should have known better. Even in my own company, I’m the only program manager who works directly in upstream projects. The rest are focused on the company’s products. Unless they served in my role previously, the people on my team don’t necessarily know how my job is different from theirs.

I left DevConf.cz feeling inspired to seize the momentum and keep moving on some things I’ve wanted to do. And it’s a good reminder to myself and others that we’re not the best judges of what others will find interesting.

Can your bug tracker and support tickets be the same system?

I often see developers, both open source and proprietary, struggle with trying to use bug trackers as support tools (or sometimes support tools as bug trackers). I can see the appeal, since support issues often tie back to bugs and it’s simpler to have one thing than two. But the problem is that they’re really not the same thing, and I’m not sure there’s a tool that does both well.

In 2014 (which is when I originally added this idea to my to-do list according to Trello), Daniel Pocock wrote a blog post that addresses this issue. Daniel examined several different tools in this space and looked at trends and open questions.

My own opinions are colored by a few different things. First, I think about a former employer. The company originally used FogBugz for both bug tracking and customer support (via email). By the time I joined, the developers had largely moved off FogBugz for bug tracking, leaving us using what was largely designed as a bug tracker for our customer support efforts. Since customers largely interacted via email, it didn’t particularly matter what the system was.

On the other hand, because it was designed as a bug tracker, it lacked some of the features we wanted from a customer support tool. Customers couldn’t log in and view dashboards, so we had to manually build the reports they wanted and send them via email. And we couldn’t easily build a knowledge base into it, which reduced the ability for customers to get answers themselves more quickly. Shortly before I changed jobs, we began the process of moving to ZenDesk, which provided the features we needed.

The other experience that drove this was serving as a “bug concierge” on an open source project I used to be active in. Most of the user support happened via mailing list, and occasionally a legitimate bug would be discovered. The project’s Trac instance required the project team to create an account. Since I already had an account, I’d often file bugs on behalf of people. I also filed bugs in Fedora’s bugzilla instance when the issue was with the Fedora package specifically.

What I took away from these experiences is that bug trackers that are useful to developers are rarely useful to end users. Developers (or their managers) benefit from having a lot of metadata that can be used to filter and report on issues. But a large number of fields to fill in can overwhelm users. They want to be able to say what’s wrong and be told how to fix it.

In order for a tool to work as both a bug tracker and ticket system, the metadata should probably only be visible to developers. And the better solution is probably separate tools that integrate with each other.

Other writing: January 2019

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

Stuff I wrote

Fedora/Red Hat

Opensource.com

Lafayette Eats

Stuff I curated

Fedora/Red Hat

AccuWeather’s new hurricane scale

It’s no secret that the Saffir-Simpson scale, used to rate the strength of hurricanes, is inadequate. It is based solely on wind speed, which does a poor job of communicating the potential impacts. I wrote just a few months ago that it’s time to consider retiring it. So when I heard that AccuWeather rolled out a new hurricane scale, you might think I’d be in favor of it.

You would be wrong.

It’s not that I think AccuWeather’s leadership is awful. I do, but that’s not the point here. The AccuWeather RealImpact Scale for Hurricanes does not address the fundamental weakness of the Saffir-Simpson scale because it still produces a single number. That this number is produced from more inputs isn’t novel (the original Saffir-Simpson scale included other aspects of a hurricane threat) nor is it better at explaining the threat. You still need to tell the public why it received a particular rating, and the preparation for wind damage may be different from storm surge may be different from inland flooding.

Not to mention the fact that the scale is opaque. It cannot be reviewed by researchers and meteorologists outside of AccuWeather. There’s no indication that it’s had any input from social scientists and science communication experts to make sure it even accomplishes the stated goal of improving communication to the general public. In short, it’s just AccuWeather acting on its own and pretending there’s value.

After insulting National Weather Service employees by falsely implying that forecasts are degraded during this government shutdown, AccuWeather would do well to shut up for a little bit and work with the meteorological community.

Dr. King is not a marketing campaign

Last Monday was Martin Luther King, Jr. day in the United States. It’s a day to honor the life and legacy of the famed civil rights leader who was assassinated in 1968. Because it’s a national holiday, some businesses try to use Dr. King or his work as part of their marketing.

Take, for example, Snarky Tea. Snarky Tea is a retailer of herbal teas with profane names. We have several in our house, including “Get Your A** in Bed”. Which, I assume, is what they were trying to sell when they sent this email on Monday.

Screencapture of an email with the subject "He had a dream... and you can too"

Oh no. This is a very bad look. What does the rest of the email say?

Screencapture of an email that reads in part "We were trying to think of a way to honor the great Martin Luther King, Jr but we're a profanity-laden tea company and this is the best we could come up with. Please don't judge us — we're doing our best over here."

Somehow, I don’t think tacitly admitting you knew this was a bad idea is the right thing to do. As I said on Twitter, if you’re thinking about using Dr. King in your marketing, just fuckin’ don’t.

Despite what Boston Globe columnists think, racism is still a problem in the United States. Dr. King was perhaps the best known civil rights activist and it got him killed. To use his most iconic speech as a way of selling tea is problematic.

Fifty-one years after his death, white America is happy to celebrate the parts of Dr. King’s legacy that we are comfortable with. Even Steve “What’s so bad about being a white supremacist?” King (no relation) is quick to jump on the bandwagon. But the reality is that we have not yet reached Dr. King’s dream. To use his legacy in this context is awful. We can do better. We must do better.

Update: if you can’t take the heat, stay out of the tea kettle

SnarkyTea blocked me on Twitter because of this post. They can be snarky, but they can’t handle being told they’re wrong.

GitHub’s new status feature

Two weeks ago, GitHub added a new feature for all users: the ability to set a status. I’m in favor of this. First, it appeals to my AOL Instant Messenger nostalgia. Second, I think it provides a valuable context for open source projects. It allows maintainers to say “hey, I’m not going to be very responsive for a bit”. In theory, this should let people filing issues and pull requests not get so angry if they don’t get a quick response.

Jessie Frazelle described it as the “cure for open source guilt”.

I was surprised at the amount of blowback this got. (See, for example the replies to Nat Friedman’s tweet.) Some of the responses are of the dumb “oh noes you’re turning GitHub into a social media platform. It should be about the code!” variety. To those people I say “fine, don’t use this feature.” Others raise a point about not advertising being on vacation.

I’m sympathetic to that. I’m generally pretty quiet about the house being empty on public or public-ish platforms. It’s a good way to advertise yourself to vandals and thieves. To be honest, I’m more worried about something like Nextdoor where the users are all local than GitHub where anyone who cares is probably a long way away. Nonetheless, it’s a valid concern, especially for people with a higher profile.

I agree with Peter that it’s not wise to set expectations for maintainers to share their private details. That said, I do think it’s helpful for maintainers to let their communities know what to expect from them. There are many reasons that someone might need to step away from their project for a week or several. A simple “I’m busy with other stuff and will check back in on February 30th” or something to that effect would accomplish the goal of setting community expectations without being too revelatory.

The success of this feature will rely on users making smart decisions about what they choose to reveal. That’s not always a great bet, but it does give people some control over the impact. The real question will be: how much do people respect it?

Inclusion is a necessary part of good coding

Too often I see comments like “some people would rather focus on inclusion than write good code.” Not only is that a false dichotomy, but it completely misrepresents the relationship between the two. Inclusion doesn’t come at the cost of good code, it’s a necessary part of good code.

We don’t write code for the sake of writing code. We write code for people to use it in some way. This means that the code needs to work for the people. In order to do that, the people designing and implementing the technology need to consider different experiences. The best way to do that is to have people with different experiences be on the team. As my 7th grade algebra teacher was fond of reminding us: garbage in, garbage out.

But it’s not like the tech industry has a history of bad decision making. Or soap dispensers not working with dark-skinned people. Or identifying black people as gorillas. Or voice recognition not responding to female voices. What could go wrong with automatically labeling “suspicious” people?

I’ll grant that not all of these issues are with the code itself. In fact a lot of it isn’t the code, it’s the inputs given to the code. So when I talk about “good coding” here, I’m being very loose with the wording as a shorthand for the technology we produce in general. The point holds because the code doesn’t exist in a vacuum.

It’s not just about the outputs and real world effect of what we make. There’s also the matter of wanting to build the best team. Inclusion opens you up to a broader base of talent that might self-select out.

Being inclusive takes effort. It sometimes requires self-examination and facing unpleasant truths. But it makes you a better person and if you don’t care about that, it makes your technology better, too.

Tech is a garbage industry filled with people making garbage decisions

I work with some great people in the tech space. But the fact that there are terrific people in tech is not a valid reason to ignore how garbage our industry can be. It’s not even that we do bad things intentionally, we’re just oblivious to the possible bad outcomes. There are a number of paths by which I could come to this conclusion, but two recent stories prompted this post.

Can you track me now?

The first was an article last Tuesday that revealed AT&T, T-Mobile, and Sprint made it really easy to track the location of a phone for just a few hundred dollars. They’ve all promised to cut off that service (of course, John Legere of T-Mobile has said that before) and Congress is taking an interest. But the question remains: who thought this was a good idea? Oh sure, I bet they made some money off of it. But did no one in a decision-making capacity stop and think “how might this be abused?” Could a domestic abuser fork over $300 to find the shelter their victim escaped to? This puts people’s lives in danger. Would you be surprised if we learned someone had died because their killer could track them in real time?

It just looks like AI

And then on Thursday, we learned that Ring’s security system is very insecure. As Sam Biddle reported, Ring kept unencrypted customer video in S3 buckets that were widely available across the company. All you needed was the customer’s email address and you could watch their videos. The decision to keep the videos unencrypted was deliberate because (pre-acquisition by Amazon), company leadership felt it would diminish the value of the company.

I haven’t seen any reporting that would indicate the S3 bucket was publicly viewable, but even if it wasn’t, it’s a huge risk to take with customer data. One configuration mistake and you could expose thousands of people’s homes to public viewing. Not to mention that anyone on the inside could still use their access to spy on the comings and goings of people they knew.

If that wasn’t bad enough, it turns out that much of the object recognition that Ring touted wasn’t done by AI at all. Workers in the Ukraine were manually labeling objects in the video. Showing customer video to employees wasn’t just a side effect of their design, it was an intentional choice.

This is bad in ways that extend beyond this example:

Bonus: move fast and brake things?

I’m a little hesitant to include this since the full story isn’t known yet, but I really love my twist on the “move fast and break things” mantra. Lime scooters in Switzerland were stopping abruptly and letting inertia carry the rider forward to unpleasant effect. Tech Crunch reported that it could be due to software updates happening mid-ride, rebooting the scooter. Did no one think that might happen, or did they just not test it?

Technology won’t save us

I’m hardly the first to say this, but we have to stop pretending that technology is inherently good. I’m not even sure we can say it’s neutral at this point. Once it gets into the hands of people, it is being used to make our lives worse in ways we don’t even understand. We cannot rely on technology to save us.

So how do we fix this? Computer science and similar programs (or really all academic programs) should include ethics courses as mandatory parts of the curriculum. Job interviews should include questions about ethics, not just technical questions. I commit to asking questions about ethical considerations in every job interview I conduct. Companies have to ask “how can this be abused?” as an early part of product design, and they must have diverse product teams so that they get more answers. And we must, as a society, pay for journalism that holds these companies to account.

The only thing that can save us is ourselves. We have to take out our own garbage.

Burnout as small task paralysis

If you’re an Online Person of a certain age, you probably have seen Anne Helen Petersen’s article in Buzzfeed “How Millennials Became The Burnout Generation“. And maybe you’re like me and said “yeah, I really identify with this.” Or maybe you’re not like me and you said “this doesn’t capture my experience.” But however you connect with this article, one part stood out to me.

None of these tasks were that hard: getting knives sharpened, taking boots to the cobbler, registering my dog for a new license, sending someone a signed copy of my book, scheduling an appointment with the dermatologist, donating books to the library, vacuuming my car. A handful of emails — one from a dear friend, one from a former student asking how my life was going — festered in my personal inbox, which I use as a sort of alternative to-do list, to the point that I started calling it the “inbox of shame.”

It’s not as if I were slacking in the rest of my life. I was publishing stories, writing two books, making meals, executing a move across the country, planning trips, paying my student loans, exercising on a regular basis. But when it came to the mundane, the medium priority, the stuff that wouldn’t make my job easier or my work better, I avoided it.

A little over a year ago, when I was overwhelmed in a new job and dealing with anxiety of an intensity I’d never felt before, I noticed that I was unable to do some thing. But it wasn’t the big and important tasks that I couldn’t do. It was the small, often trivial tasks that I couldn’t bring myself to do. Especially if it was not immediately rewarding or involved doing something I hadn’t done before.

My job had the possibility of occasional foreign travel, but to do that, I’d need a passport. I’d never bothered getting one before because I didn’t need it. Now I had some incentive. But the paperwork sat on my desk for months because I couldn’t bring myself to go to the post office and submit it.

There were so many emails that I put off sending as long as I could because I was worried that they’d get a negative reply. Nevermind that they were often just telling people about something else that happened. Or that the most likely outcome would be that my recipients wouldn’t even read it.

Redesigned pitch decks? No problem. New content for the website? Easy. Planning a major conference presence? Stressful, but manageable. But the easy stuff? Couldn’t do it.

When I first started experiencing this, I was really surprised. Why isn’t the easy stuff easy for me to do? Why can I do the hard stuff without too much worry?

For all the criticisms of it’s general applicability, Petersen’s article gave me a framework to understand this. And I felt seen.

Say “no” to advance your career

A few months ago, Bridget Gelms shared the worst professional advice she has heard:

Early-career people in particular are encouraged to take on all tasks in order to prove themselves and — to a lesser extent — discover what they do and don’t like to do. I suspect this is more true for women. I understand why people give that advice, and I understand even more why people take it. But it turns out, saying “no” can do more to advance your career than saying yes.

One thing I’ve observed is that over time, people who say “yes” to every request get a bunch of requests dropped on them. Some of them are good, but many are a waste of their talents. Being able to say “no” when the situation warrants can establish that your time — and thus you — are valuable.

Consider this: you’re asked at the last minute to fly to another continent to be in a meeting with a potential customer for a couple of hours. The potential customer is pretty unlikely to actually sign up, or they represent a small and not-strategic gain. You could go. Or you could find another way for the customer to get the 5 minutes worth of information that you’d end up providing. By not going, you save your company a few thousand dollars in airfare and you don’t lose two days to travel. What else more valuable can you do in that time?

The example above isn’t contrived. I’ve seen it play out, and the person who said no established themselves as someone of value in the company. Of course, you can’t say “no” to everything. Sometimes a task has to be done and you’re the one that will do it, whether you like it or not. But knowing when to say “no” is a valuable skill for improving your career.