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.

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.

Picking communication tools for your community

Communication is key to the success of any project. The tools we use to communicate play a part in how effective our communication is. Recent discussions in Fedora and other projects have made me consider what tool selection looks like. Should Discourse replace mailing lists? Should Telegram replace IRC? I’m not going to answer those questions.

There’s no one right tool, just a set of considerations to think about in selecting communications tooling. Each community needs to arrive at a consensus about what works best for their workflow and culture, and keep in mind that the decision may attract some contributors while driving others away.

In this post, I’m going to broadly lump tools into two categories: synchronous and asynchronous. Many tools can be used for both to a decent approximation, but most will pretty obviously fall into one category or the other. Picking one tool to rule them all is a valid option, but be aware that it immediately favors one category of communication over the other. And keep in mind that for large projects, some sub-teams may choose different platforms. That’s fine so long as people who want to participate know where to look.

Considerations for all tools

Self-hosted or externally-hosted. Do you have the resources to maintain the tool? If you do, that’s a way to save money and maintain control, but it’s also time that your community members can’t spend working on whatever your community is doing. Externally-hosted tooling (either free or paid) might give you less flexibility, but it can also be more isolated from internal infrastructure outages.

Open source or proprietary. This is entirely a value judgement for your community. For some communities, anything that’s not open source is a non-starter. Others might not care at all one way or another. Most will fall somewhere on the spectrum between.

Federated or centralized. Can the community connect their own tools together (e.g. like with email) or is it a centralized system (like most social media platforms)? The trend is definitely toward centralized systems these days, so you may have to work harder to find a federated system that meets your needs.

Public or private. Can outsiders see what you’re saying? For many open source projects, public visibility is important. But even in those communities, some conversations may need to take place in private or semi-private.

Archived or ephemeral. Do you want to be able to go back and see what was said last month, last year, or last decade? Some conversations aren’t worth keeping, but records of important decisions probably are. Does your tool allow you to meet your archival needs?

Considerations for synchronous tools

Sometimes you really need to talk to people in real time.

Mobile experience. It’s 2019. People do a lot on their phones, especially if their contribution to your community happens during their workday or if they travel frequently. What is the mobile experience like for the tools you’re evaluating? It’s not just a matter of if clients exist, but what’s the whole experience. If they disconnect while on an airplane, do they lose all the messages that were sent in their absence?

Status and alerting. What happens if someone stays logged in and goes away for a little bit? Do they have the ability to suppress notifications? Is there any way to let others know “I’m away or busy, don’t expect an immediate reply”?

Audio, video, and screen sharing. Sometimes you need the high-bandwidth modes of communication in order to get your full message across (or just shortcut a lot of back-and-forth). Does the tool you’re looking at provide this? Is it usable for those who can’t participate due to bandwidth or other constraints?

Integrations. Can you display GIFs? The ability to speak entirely in animated images can be either a feature or a bug, depending on the community’s culture. But if it’s important one way or another, you’ll want to make sure your tool matches your needs. Of course, there are other integrations that might matter to. Can your build system post alerts? Does the tool automatically recognize certain links and display them in an particular manner?

Considerations for asynchronous tools

Of course, you’re not all going to be sitting at your computer at the same time. People go on vacation. They live in different time zones. They step away for 10 minutes to get a cup of coffee. Whatever the reason, you’ll need to communicate asynchronously sometimes.

Push or pull. Email is a push mechanism. Your message arrives in my inbox whether I’ve asked it to or not. Web fora are a pull mechanism. I have to go check them (yes, some forum tools provide an email interface). Which works better for your workflow and community? Pull mechanisms are easier to ignore when you want to step away for a little while, but they also mean you might forget to check when you do want to pay attention.

Is it a ticket system? I haven’t really talked about ticket systems/issue trackers because I don’t consider them a general communication tool. But for some projects, all the discussion that needs to happen happens in GitHub issues or another ticket tracker. If that works for you, there’s no point in adding a new tool to the mix.

Thought Leaders™ versus thought leaders

My friend Tom wrote a Twitter thread last week about how thought leaders are often derided in the tech industry.

I agree with Tom’s point that people — both in an out of the tech sector — value doing over thinking. It’s why we differentiate “talking the talk” and “walking the walk”. But I think it’s important to distinguish between people who are advancing the state of the field by visionary work and people who are trying to draw attention to their expertise. “Thought leaders” versus “Thought Leaders™”.

I’m of the mind that there’s a list of attributes where if you have to tell people you are that, then you aren’t. Someone who is always talking about how honest they are? Probably not trustworthy. Similarly, someone who describes themselves as a thought leader is probably not as influential as they’d like to think. (Full disclosure: I sometimes refer to myself as a thought leader, but I do it ironically.)

James Cuff gave me a certificate for being a “total thought leader” when he was still an Assistant Dean at Harvard.

I would argue that true thought leadership is an act of doing in itself. It’s taking experience gained from being a practitioner in the field and using that to inform a vision of the future. Thought leaders lead not by saying what the future is, but by showing what the future is. They don’t have to tell people that they’re thought leaders because the evidence is plain to see.

Most people can probably name at least a handful of people in their field that they think are always on the cutting edge. And they probably think highly of those people. It’s not being a thought leader they object to, just the self-applied label.

Is there a marketing person leading the IT team?

Seth Godin is a well-known figure in technology marketing. And it’s no surprise that he thinks marketing is a pretty important function. Last month, he wrote a blog post with the same title as the one you’re reading right now. In it, he argues that marketing is more than advertising and the innate customer focus of marketers means they’re a good fit to lead IT teams.

Maybe Seth is being a little self-important here. I’m sure many IT teams would not be pleased to learn someone from marketing is being put in charge. But there’s something to Seth’s case.

I worked in marketing for two years. I don’t think I’d want to make a career of it, but I consider it valuable experience. Working in marketing gave me a lot of practice communicating concisely and effectively to audiences who might not want to listen to what I have to say. And it made me consider the optics of how actions and decisions may be received.

I’ve long believed that the best sysadmins and technical support people don’t come fro a strictly technical background. Knowledge of other business areas or even other academic domains gives a broad background for connecting with the customer as a fellow human. And successful IT leadership means being able to work with other parts of the organization and meet their needs.

So maybe IT teams don’t need a marketing person in charge. But it doesn’t hurt to think like a marketer sometimes.

A new triple constraint

The idea of a triple constraint is well-known, even if people don’t think of it by that name. “Fast, easy, and cheap: choose two. In project management, the relationship between scope, cost, and schedule is sometimes called the “iron triangle”. But recently Seth Godin published a blog post that got me thinking about a new triple constraint.

Profitable, difficult, or important?” Godin asks.

Profitable, difficult, or important—each is an option. A choice we get to make every day. ‘None of the above’ is also available, but I’m confident we can seek to do better than that.

Godin never says this, but success generally means sacrificing one of those three for the other two. Of course, you can be successful with one or none, but not more than three.

Where’s your evidence, Ben? I have none; this is a hunch. In an ideal world, your work would be all three. But the reality is that doing all three of them is exceedingly difficult. Sometimes the best way to win is knowing what you can lose.

“You’ve been hacked” corrects behavior

Part of running a community means enforcing community norms. This can be an awkward and uncomfortable task. I recently saw a Tweet that suggests it might be easier than you thought:

It’s nice because it’s subtle and gives people a chance to self-correct. On the other hand, there’s some value in letting community members (and potential community members) see enforcement actions. Not as a punitive measure, but as a signal that you take your code of conduct seriously.

This won’t work for every case, but I do like the idea as a response to the first violation, so long as it’s a minor violation. Repeated or flagrant violation of the community’s code of conduct will have to be dealt with more strongly.

Date-based conditional formatting in Google Sheets

Sometimes a “real” project management tool is too heavy. And spreadsheets may be the most-abused software tool. So if you want to track the status of some tasks, you might want to drop them into a Google spreadsheet.

You have a spreadsheet with four columns: task, due, completed, and owner. For each row, you want that row to be formatted strikethrough if it’s complete, highlighted in yellow if it’s due today, and highlighted in red if it’s overdue. You could write conditional formatting rules for each row individually, but that sounds painful. Instead, we’ll use a custom formula.

For each of the following rules, apply them to A2:D.

The first rule will strike out completed items. We’ll base this on whether or not column C (completed) has content. The custom formula is =$C:$C<>"". Set the formatting style to Custom, clear the color fill, and select strikethrough.

The second rule will highlight overdue tasks. We only want to highlight incomplete overdue tasks. If it’s done, we stop caring if it was done on time. So we need to check that the due date (column B) is after today and that the completion date (column C) is blank. The rule to use here is =AND($C:$C="",$B:$B<today(),$A:$A<>""). Here, you can select the “Red highlight” style.

Lastly, we need to highlight the tasks due today. Like with the overdue tasks, we only care if they’re not done.=AND($C:$C="",$B:$B=today(),$A:$A<>""). This time, use the “Yellow highlight” style.

And that’s it. You can fill in as many tasks as you’d like and get the color coding populated automatically. I created an example sheet for reference.

You don’t need to have an answer to report a problem

When Alex Hinrichs retired from Microsoft, he wrote the traditional goodbye email. It was so well received that he decided to post it to LinkedIn. In his letter, Hinrichs shares 11 lessons he learned over the years. Most of the advice he shares is good, but he also included something I strongly disagree with:

If you bring a problem to your boss, you must have a recommendation. When presenting solutions to your boss, give them a menu and tell them your recommendation. “Hey boss, choose solution a, b, c, or d… I recommend a”.

​Hinrichs is not the first person to share this advice. I see it all over the place, and I hate it. I get the intent. If nothing else, coming up with the list of options and your recommendation forces you to think through the problem. It’s good practice and it makes you look good.

But it’s also a good way to suppress red flags. This is particularly true for early career and underindexed employees. For them, reporting a problem can be intimidating enough. The pressure of having to figure out a solution means they might just stay quiet instead.

Now it may turn out that what a junior employee sees as a problem that they don’t have an answer to really isn’t a problem. On the other hand, some problems are much easier to identify than they are to fix. This is particularly true with ethical and cultural problems. If your policy is “don’t come to me until you have a solution”, you’re opening yourself up to letting bad culture take root. And you’re depriving your junior employees a chance to learn from you and your team.

If someone is constantly reporting problems but not showing any willingness to address them, that’s an issue. But saying you must have a recommendation is a good way to not learn about problems until it’s too late.