technotestechnotes - Tumblr blog

technotestechnotes · 6 years

Link

A Guide to Mindful Communication in Code Reviews

Code reviews are a core part of being a software engineer. Most of us review code every day. Technical skills are needed to review code thoroughly and quickly. But beyond that, reviewing code is also a form of communication, teaching, and learning. Either as the author or the reviewer of code, being mindful in your communications can make code reviews more valuable for everyone.

Mindful communication

First of all, what does it mean to be mindful in your communication? Mindful communication is a term that means to listen and speak with compassion, kindness, and awareness of yourself and others. This perspective is the basis of most of the tips in this guide, so let’s dive into it a bit more.

Here are some general guidelines for practicing mindful communication:

Put yourself in the other person’s shoes.

Listen to hear what’s actually being said.

Let go of what you think the outcome should be.

These things are easier said than done! So I’ll break down how these guidelines apply specifically to reviewing code and having your code reviewed.

Tips for everyone

A crucial skill to learn for practicing mindful communication is a self check-in. This means taking a moment to see how you’re feeling and take a step back from what you’re communicating.

When you’re doing code reviews, you’ll want to check in with yourself to see if you’re following the guidelines. Good times to check in are right before you start or reply to a review, if you’re feeling frustrated, or right before you hit “submit” on that comment.

When you’re checking in, also consider how you’re feeling in general. Giving kind and considered feedback takes time and energy. If you’re hungry, tired, in a hurry, have a lot of meetings, etc., don’t review code or send out a review. You need to fix those things first. If you don’t care for yourself, you can’t take care of others.

Here are some good questions to ask yourself when you check in:

Why did this person write this code the way they did?

Is the tone and wording of my feedback something I would feel good hearing?

Do I fully understand where they’re coming from?

Do I think I know the “right” way to write this code? Am I allowing space for a solution I haven’t thought of?

Do I have all the information I need to understand this issue?

Have I eaten lunch?

Do I have enough time right now to give thoughtful feedback?

Am I feeling upset/nervous/anxious about something else?

Tips for the reviewer1. Don’t jump to conclusions

Assume the author did what they did for a reason. Put yourself in their shoes. When you make a code change you likely consider a few options, and go with one that fits the needs and constraints of the problem you’re solving. They likely did the same thing.

Instead of telling the author they did something wrong, try:

“What about this other option? It might make xyz better!”

“What happens in abc situation?”

This also hits on letting go of the outcome. You might not have the right answer. You might not have all the information you need to understand why the author took the approach they did. If you step back and try to understand where they’re coming from, it might surprise you!

2. Ask open questions

Listen! Don’t assume. If you think something is 100% off the wall, check in with yourself. You respect your co-workers, so ask them to explain their thinking. You might learn something, or get a glimpse into someone else’s thought process.

Try these formats:

“This part is a little confusing. Could you walk me through what it’s doing?”

“I’m having a hard time following this section. How does it work?”

“What other options did you consider for this part?”

3. Leave out the nits

There’s no need to call out nits or small things that maybe aren’t your style. Linters are great for catching small issues or keeping a code base consistent, so there’s no need for a human to call those sorts of things out. If a linter could catch what you’re about to point out (even if your current setup doesn’t), think hard about whether it’s worth everyone’s time to discuss.

Labeling a comment a “nit” is also to be avoided because it minimizes your feedback. Your input is valuable, so leave out the caveats. If you don’t feel your comment is worth adding without a caveat, consider leaving it out completely.

Avoid starting comments with these:

“Nit: …”

“This is a nitpick …”

“Tiny nit: …”

“This is slightly nit-picky, but…”

(All pulled from real PR comments 😱)

4. Call out if things could be fixed later

So you’ve left out the nits, but there are still things you think could be improved that aren’t strictly necessary. Let the author know you don’t mind if they’re updated in a later or follow-up PR. You might not be aware of a deadline for the team or that there are a lot of changes still coming.

Here are some phrases that acknowledge iterative work:

“This could cause x problem later, but I think it’s fine to fix in the next iteration”

“Can we make a ticket to come back to this section? It might cause x issue down the road!”

“Have you thought about how this will generalize to what we’re working on next?”

“How are you planning to handle this other situation that’s coming up?”

5. Be biased towards approving

Our work is iterative and subjective so don’t be a gatekeeper. Try to approve reviews even if you disagree with the style or approach. People write code differently, and come from different perspectives.

Though I advocate for not blocking PRs on reviews, often the author must get your approval before moving forward. This creates a power imbalance. Avoid abusing that power and approve it unless you’re worried a change will cause major problems. If you’re that worried about something, another option is to go talk in person or use some of the open questions from my earlier tips.

An exception to this is if the change is very large or includes an architectural decision. When a decision is being made that will have long-term consequences, it likely warrants a larger conversation than a code review. After that conversation the review will likely be a quick 👍.

6. Give example code

Particularly when reviewing code for someone more junior, giving a specific example in the review comment can be helpful. This saves them time, and makes it really clear what you’re proposing. Also, you already thought through it, so why make them figure it out on their own?

Here are some examples:

“This section might be more clear if you switch the order like this: if (true) { return “this is an example”; }”

“You might be able to replace this part with a utility we have! I think this would do the trick: const x = utily_thing(y, { a: true })”

7. Link to documentation

Linking to documentation or files you referenced shows the author where to find the information next time. This is particularly good to do if you looked it up while writing the comment. You already have the link, so you might as well. Sharing is caring! But acknowledging that you needed to look something up can also help fight imposter syndrome.

Calling out that you learned something new in the review can have a similar effect. If you come across a new method or syntax that you need to look up, leave a “TIL” comment and include the link that explains what was new to you.

8. End with “What do you think?”

Ultimately the author of the code will be making and owning the change. If you have a more fundamental or big piece of feedback, end the comment with “What do you think?”

This goes back again to letting go of the outcome. Maybe you don’t have all the context — maybe the author already thought about the approach you’re suggesting and there are issues with it that you missed.

You can also ask for history about how the decision was made. If you weren’t part of conversations about the approach, getting some history can be helpful before suggesting a different one. Sometimes junior engineers are following the advice of another more senior engineer, so if you disagree it likely makes more sense to talk to the senior engineer.

Hopefully large or fundamental changes aren’t needed by the time code is reviewed, which leads me into tips for the author.

Tips for the author

If you review code, you likely have your code reviewed also, so think about what makes a PR easier or harder to review.

1. Make small iterative changes

It is so much easier to review small changes — the smaller the better. Smaller changes are less risky, and take less time to review. Reviews with many hundreds of lines changed take much longer to review than several small ones with isolated changes. If each PR maps to one piece of work, it’s easier to understand what the code is doing. The reviewer doesn’t have to pull apart which changes are needed for each task.

2. Link to documentation

Sound familiar? This is a tip for both reviewers and authors! Linking to documentation in your review description or comments can make it easier for the reviewer to understand what’s being changed or implemented. If you’re implementing an interface or using a new library, link to the documentation you referenced while doing your work.

This is particularly helpful for seemingly small changes in things like configuration. Have you ever received a one-line change and had no idea what it meant? A link to the documentation is so helpful in these cases.

3. Assume the reviewer has the best intent

Even if a reviewer follows all the tips above, they can still make mistakes or get careless. Try to keep in mind that we’re on the same team and they likely had good intentions behind whatever feedback they gave. It’s easy to get defensive, but remember, as the author you have to let go of the outcome just like the reviewer. Maybe the reviewer has some knowledge or expertise you were missing, or saw a blind spot you missed because they came from a different perspective.

A major exception to this is if the reviewer legitimately doesn’t have the best intent. If someone is being actively malicious or hostile in a code review, that’s harassment and you should speak to your manager and HR about it.

4. Think about the readability of your diff

Your diff itself is a kind of communication. Make sure it’s well written!

Here are some things to think about when cleaning up a diff:

Don’t refactor in addition to new changes.

Check that your PR doesn’t have unnecessary changes or unrelated files.

As mentioned above, each PR should be one logical unit of work.

If you find yourself leaving explanatory comments on your own code review, those might be better as code comments.

Sometimes diffs are more easily viewed with no white space. You can see a diff without whitespace changes on GitHub by checking “Hide whitespace changes” under “Diff settings” or by adding w=1 to the url. On the command line you can use git diff -w. You can call out that a particular change might be better to view that way in your PR description.

5. Get feedback early and often

Having a quick chat about some implementation options with someone who’ll review your code is a great way to avoid stress when the review comes around. Reviews are usually not the time to work out architectural decisions since the work has already been done.

This sounds like hard work

If this all sounds like a lot of hard work, that’s because it is. Like I said earlier, giving kind and considered feedback takes time and energy. But luckily it gets easier.

You can build up muscle memory of actively giving kind feedback and it will become natural. At first it might feel uncomfortable to ask a question when you think you can just tell someone the answer, or it might feel slow to write out a code example. You might have to stop, check in with yourself, and do it anyway. This is a learning process and learning new things is uncomfortable.

Lastly, keep in mind that every team is different, so these specific tips might not all apply to your team. If you come up with other ways to apply mindful communication to code reviews or building software in general, I’d love to hear about them!

0 notes

technotestechnotes · 6 years

Link

I’m going to tell you about how I took a job building software to kill people.

But don’t get distracted by that; I didn’t know at the time.

Even before I’d walked across the stage for graduation, I accepted an offer for an internship. It paid half again as much as the most I’d ever gotten in the highest paying job up to that point. Not to mention that I’d spent years in college with low paid student jobs or living only on student loans.

I’d be joining a contracting company for the Department of Defense. The Department of Defense, or DOD, is the part of the government made up by the military in the United States. The DOD outsources all sorts of things, from P-8A Multi-mission Maritime aircraft to blue, shade 451, Poly/wool cloth.

At the time, I thought nothing of the fact that I’d be supporting the military. Besides, they’re the good folks right? My dad was in the military. So was my grandfather. It was good money, a great opportunity, and a close friend of mine had gotten me the gig. Life was good.

I showed up for my first day of work in North Virginia, or NoVA as the industry likes to call it. I met the team of other interns, then learned what the team would be building: a tool to use phones to find WiFi signals.

It seemed pretty cool compared to what I’d built to up that point. The most complicated thing was an inventory management system. It didn’t concern itself overmuch with persistence. Who needs to stop and restart a program anyhow? The data was right there in memory and if you forgot how many Aerosmith CDs you had, who cares? It got me an A on the assignment, and that was all that mattered.

Honestly, the idea of finding WiFi routers based on the signal strength seemed pretty intimidating at the time. The idea impressed me.

But don’t get distracted by all this; the software was intended to kill people.

I joined the team after they’d already gotten started on the project. The gist of the tool was that it would look at how WiFi signal strength changed as your phone moved around. If the signal strength got stronger, you were getting closer. If it got weaker, you were moving away. To find this information, we’d collect two pieces of information for each WiFi access point in range. The phone’s geolocation information and the WiFi signal strength.

To predict the actual location of the WiFi signal, we used a convolution of two algorithms. Both of them relied on the Free Space Path Loss equation. For our purposes, FSPL calculates how far away a phone is from a WiFi signal based on loss in signal strength. It assumes that there is only empty air, or “free space”, between the access point and the phone.

The first algorithm was R^2. It measured the difference between the signal strength we’d observed and the expected signal strength at each distance in a search grid based on Free Space Path Loss. Locations with the lowest R^2 error rate were the most likely location.

We’d combine that calculation with a Gaussian estimate. Now I spent two or three days last week trying to understand Gaussian estimates for this talk and couldn’t. The best documentation on them are still research papers. I do know that it creates a probability curve. The high points of the curve are distances where the access point is likely to be, and low points are unlikely. The curve started with a probability hole of low values. They represented low likelihood that the phone is standing right next to the signal. The curve then increased to high probabilities further out. It decreased to near zero even further. The algorithm adjusted the width and height of these two curves by consulting past measurements. It created a heat map of probabilities for the signal source.

We’d normalize the probabilities for each location in the search grid. A combination of probabilities was more correct than either algorithm itself.

We stored this probability matrix for each location a phone collected from. Using these, if we collected readings while moving in a straight line, we could tell you how far away the WiFi was. If you turned a corner, we could also add direction, so you could find it in 2D space. If you climbed some stairs, we’d show you altitude as well. The technology was the most interesting project I’d ever worked on.

But don’t let that distract you; it was designed to kill people.

I mentioned that I had a software engineering degree at this point. My teammates were earlier in their education careers. Most of them were a year or two into their four year programs, also a mix of Computer Science and Math majors. My expertise was in the design and process of building software, while theirs was more in high level mathematics or the theory of computer use.

I helped to translate the working algorithms they’d designed in MatLab to the Java code we needed to run on the phones.

And let’s be honest, we spent plenty of time deciding whether we preferred Eclipse or NetBeans. Can I say how happy I am that as a Ruby developer, I’ve not had to figure out where to put a .jar file in over half a decade?

One such example is calculating distance between two points. As these things go, it was in the deepest level of each loop. We were using great circle distance, which is the way you measure the shortest distance between two points on a sphere, such as Earth. Did we need to use this complicated measurement over the meager distances a WiFi network can operate over? Absolutely not. Did I mention this was over half a decade ago? We weren’t always making the best choices. Anyhow, we needed to calculate these distances. The function doing it was being hit hundreds of thousands of time for each collection point, often with the same two locations. It was a very slow process.

We solved that by implementing a dictionary of latitude/longitude pairs to distances. This at least meant we didn’t re-do those calculations. This and other optimizations we made sped up the performance from seven minutes to a few seconds.

But don’t get distracted; that performance increase made it faster to kill people.

The accuracy of the locations wasn’t fantastic. I don’t remember exactly what it was before we focused on improving this, but an average error about 45 feet sticks in my head.

That’s a little longer than a Tyrannosaurus Rex nose to tail, or more concretely the length of a shipping container.

That’s significant when the WiFi range for 802.11n is only about 100 feet. That means we could be up to almost half the range of the router off from where it was.

I talked about the Gaussian estimation, the two curves from the second algorithm. We hard-coded numbers that defined this curve. They were only starting points, but they were starting points every time we made the calculation.

A Genetic Algorithm is a type of program that produces a set of values that optimize for a desired result. It’s a perfect fit for tuning these hard coded values to get more accurate results.

Each of the Gaussian estimation values will is a gene. The set of values is a genome in Genetic Algorithm parlance. The genes were our 3 constants.

A fitness function is what Genetic Algorithms use to measure performance of a genome. For the dataset of readings I was using in the GA, I knew the actual location of the access points. That meant I could run the geolocation algorithm with each genome’s values in place as the fitness function. The result would be the distance between the actual location and the one calculated by the GA-derived values.

Genetic Algorithms take a set of genomes, called a generation, and keep a certain percentage of top performers.

These top performers “survive” to the next generation as copies. Sometimes the algorithm mutates these copies by adding a Gaussian random value to each gene. This means that there was a chance that any of the copied genomes would have each gene changed slightly. That way they would have a chance of performing better or worse. New random genomes are created for the remaining spots in the new generation.

We saved the top performers across all populations. When the GA ended I could take a look at the values and select the best performer.

I let this genetic algorithm run over the weekend. It was able to increase the accuracy from 40-odd feet to about 10.3 feet, 25% of the error from the original. That is less than the GPS accuracy on the smartphones collecting data (which is about 16 feet according to GPS.gov). This is too accurate, so it may have over-optimized against the test data and might not be as accurate against other data sets. This is called overfitting and the way around it is to have separate sets of training and test data. Did I mention this was five years ago? I didn’t even know what overfitting was back then.

I loved this. Genetic algorithms, R^2, and Gaussian estimation are the kind of thing that they tell you you’ll never need to use again once you graduate. But we were using them for a real world project! It was great.

But don’t let that distract you; this accuracy made it easier for the software to help kill people.

The tracking now worked accurately and quickly. The next feature was to add tracking a moving WiFi access point. I briefly wondered why an access point would be moving, but that question wasn’t as interesting as figuring out how to track it.

We made use of Kalman Filters to observe state variables: the position, velocity, and acceleration of the WiFi signal. Given these and the time since the last measurement, a Kalman Filter is able to improve the current prediction with surprising accuracy, filtering out “noise” data automatically.

Each time we ran the real time algorithm, we’d also feed this to the Kalman Filter. With only that information, it was able to produce an estimate that is a weighted average of previous data. A new predicted location that was more accurate than the calculated value.

At the same time, we added the ability to track more than one WiFi signal. We’d filter our collection of readings by the unique identifier of each access point. The filtered datasets each went through the full algorithm to produce predictions.

We used the APIs on the phone to read the signal strength of all WiFi access points in range. We were able to track multiple hotspots, basically whatever we could see in the WiFi network list. It was all very exciting. These seem like academic problems, but we were getting to use them in a real project! Being a programmer was going to be great.

But don’t let that distract you; this meant we could kill multiple more accurately people.

We’d been working with the project owner throughout this process.

He was laissez-faire about most things. He might check in once a day then going back to his main job in the area of the building dedicated to classified work.

Whenever we hit one of these milestones, we’d tell him. He’d be happy about it, but a question always came up. He wanted it to sniff for the signals put out by phones in addition to WiFi hotspots. This is a much harder problem from a technical perspective. The functionality necessary to do this is “promiscuous mode”, a setting on the wireless network controller. Neither iPhone nor Android supported that option. We’d need to jailbreak or root the phone regardless of the platform. We looked for packages that we could use that would let us do this to “sniff” the packets that devices sent back to routers. The closest we ever found was a SourceForge project that seemed promising. We didn’t fully understand its use and it wasn’t well documented.

We told the project owner that we’d get to it later. None of us thought it was that important: we had the technology to find WiFi Access Points working. That was the goal right? Each time we’d demonstrate the new exciting tech we’d built though, the same question came up.

We got WiFi hotspots located! Great, does it find phones?

It’s taking seconds instead of minutes! Great, does it find phones?

We looked into it finding phones, it seems unlikely but maybe! Ok, we’ll come back to it.

We got moving targets working! Great, does it find phones?

I had been distracted.

All of the cool problems we were solving: finding nodes, speeding things up, making more accurate predictions. It was all so cool, so much fun. I hadn’t thought about why we were putting all this work into finding a better place to sit and get good WiFi. That doesn’t even make sense if you look at it for more than a few seconds.

Does it find phones.

This was never about finding better WiFi. We were always finding phones. Phones carried by people. Remember I said I was working for a Department of Defense contractor? The DoD is the military. I was building a tool for the military to find people based on where their phones where, and shoot them.

I tried to rationalize this then. The military is in place to protect Truth, Justice, and the American Way. But this was the same time that we found out the government had been spying on Americans in the US with drones. They’d also lent out that technology to federal, state, and local law enforcement agencies nearly 700 times to run missions. The military and government do things that I know I don’t agree with pretty often. I didn’t want to be a part of building something used to kill people, especially since I knew I’d never know who it was killing, let alone have a say.

I rationalize it now too. We were interns, and we didn’t even have clearance. The projects this company did for the government were classified Top Secret. I wasn’t allowed to know what they were. My code probably got thrown away and forgotten. Probably.

This was an extreme example of code used in a way that the creator did not intend it. The project owner conveniently left out its purpose was when explaining the goals. I conveniently didn’t focus too much on that part. It was great pay for me at the time. It was a great project. Maybe I just didn’t want to know what it would be used for. I got distracted.

There are other examples of when code is used in ways it wasn’t intended, and of code that does bad things.

A year and a day ago, a developer named Bill Sourour wrote a blog post. It opened with the line: “If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little deceitful – if not outright unethical.”

Bill had been asked to create a quiz that would almost always give a result that benefitted his client. Bill worked in Canada, and in Canada there are laws in place that limit how pharmaceutical companies can advertise prescription drugs to customers. Anyone could learn about the general symptoms a given drug addressed, but only patients with prescriptions could get specific information about the drug.

Because of this law, the quiz was posing as a general information site and not an advertisement for a specific drug. If the user didn’t answer that either they were allergic to the drug or already taking it, every quiz result suggested this specific drug. That’s what the requirements said to do, and that’s what Bill coded up.

The project manager did a quick test before submitting the website to the client. She told Bill that the quiz was broken: it always had the same answer. “Those were the requirements,” Bill responded. “Oh. Ok.”

A little while later, Bill got an email from a colleague that had a link to a news article. A young woman had taken the drug that Bill had built this quiz for. She had killed herself. It turns out that one of the main side effects of the drug were severe depression and suicidal thoughts.

Nothing Bill did was illegal. Like me, Bill was a young developer making great money. The purpose of the site was to push a particular drug - that’s why it was being built. He chalked it up to marketing. He never intended for this to happen. Maybe Bill got distracted too.

As his conclusion, Bill writes:

As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices.

We’re approaching a time where software will drive the vehicle that transports your family to soccer practice. There are already AI programs that help doctors diagnose disease. It’s not hard to imagine them recommending prescription drugs soon, too.

The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code.

Since that day, I always try to think twice about the effects of my code before I write it. I hope that you will too.

Bill’s story isn’t that far off from mine, but there are still other examples.

Earlier this year, a story came out that Uber had built into its ridesharing app code they call “greyball”. It’s a feature of their VTOS (or violation of terms of service) tool that can populate the screen with fake cars when the app is opened by users in violation of the terms of service.

In a statement, Uber said, “This program denies ride requests to users who are violating our terms of service — whether that’s people aiming to physically harm drivers, competitors looking to disrupt our operations, or opponents who collude with officials on secret ‘stings’ meant to entrap drivers.”

In practice, as The New York Times reports, it was used in Portland to avoid code enforcement officers working to build a case against Uber for operating without a license. When triggered by Uber’s logic, it populates the app with cars that don’t exist, with fake drivers who quickly cancel after accepting a ride.

I am not a lawyer, but it seems like this is likely an obstruction of justice, itself a crime outside of Uber’s unlawful operations in Portland. Greyball is used even today, though mostly outside the United States. I’m a huge fan of ridesharing - though I use a competitor in Austin and Boston called Fasten rather than the much larger Uber or Lyft. But it’s not uncommon to see in the news these days articles about heinous things these drivers are doing. Greyball may have enabled some of those.

Again, it’s an unintended consequence of a tool built. Maybe the greyball internal pitch was to “greyball” users who were in violation of the terms of service. People who were under 18, or who didn’t pay to clean up their late night explosive accidents one too many times for example. Rather than block them, probably causing them to create a new account, they could be put into an alternate dimension where for some reason they just couldn’t ever get a ride. That’s fine, right?

If these developers had thought about the worst possible case for how this could be used, maybe obstruction of an investigation into Uber’s shady dealings would have come up in that conversation and it could have been addressed early on. Maybe they were distracted by the face value of the request from looking deeper at the purpose and uses.

There’s all sorts of things as well that aren’t as black and white (if you’ll excuse the pun). Apps that always listen to the microphone to tailor ads to you based on what you say near your <phone, websites designed to exploit psychology to take up as much of your time and attention as <possible, and any number of apps that opt you into mailing lists when you sign up or purchase something. These aren’t nearly as obviously bad, but at least in my opinion they’re still kind of shady.

This value system is different for others. We don’t always agree as individuals what is right and wrong, or even with what should be legal or illegal.

There are actually words for things that society decides are good or bad versus what you or I individually believe: ethics and morals. While modern philosophy more or less uses these terms interchangeably, a common understanding at least between us will be important later.

Ethics are imposed by an outside group. A society, a profession, a community such as ours or even where you live. Religions provide ethical systems, as do groups of friends. Societies in whatever form define right and wrong, good and bad, and imposes those on its members. Ethics in societies such as local, state, and national groups are often, but not always, coded into laws.

Morals are a more personal version of the same thing. Society as a whole imposes its mores on smaller communities, and all of that trickles down to the individual level. That’s not to say that your morals can’t conflict with the ethics of society. For example, you might think that freedom of speech is a basic human right, but live somewhere that defacing religious or political objects is considered wrong.

Let’s not get distracted by morals and ethics yet, though. We’ll come back to them.

The unifying factor in all of the stories I’ve told is that a developer wrote the code that did these unethical or immoral things. As a profession, we have a superpower: we can make computers do things. We build tools, and ultimately some responsibility lies with us to think through how those tools will be used. Not just what their intention is, but also what misuses might come out of them. None of us wants to build things that will be used for evil.

The Association for Computing Machinery is a society dedicated to advancing computing as a science & profession. ACM includes this in their Code of Ethics and Professional Conduct:

Well-intended actions, including those that accomplish assigned duties, may lead to harm unexpectedly. In such an event the responsible person or persons are obligated to undo or mitigate the negative consequences as much as possible. One way to avoid unintentional harm is to carefully consider potential impacts on all those affected by decisions made during design and implementation.

So how can we “carefully consider potential impacts”? Honestly, I don’t have any answers to this. I don’t think that there really is a universal answer yet, because if we had it I have to believe we’d not be building these dangerous pieces of software.

I do have a couple of ideas though. One I got from my friend Schneems is to add to the planning process a step where we come up with the worst possible uses of our software. In opting in folks to an email list by default, the worst case might be that we send them a bunch of unwanted email and they unsubscribe. Maybe they even stop being a customer. As Schneems said: “Am I willing to sell my hypothetical startup’s soul for a bigger mailing list, when that might be all that keeps the company afloat? Yeah, no problem.” That makes sense to me. I don’t think it’s the best practice, but in the end it’s not physically hurting anyone. If I had sat down and thought about what the WiFi location app could be used for in the worst case, I would have come to a very different conclusion.

Actually, thinking about the worst possible uses of code could probably be a fun exercise. You might come up with some pretty wacky examples like “If we send Batman an email and he happens to have notifications on his iPhone for new emails, he might be looking at the notification when the Riddler drives by in the Riddler Car and he might not catch him before he gets off his witty one liner at the crime scene. Riddle me this, riddle me that, who’s afraid of the big, black bat?.” This isn’t so plausible, but it shows that these exercises can go down all sorts of different paths that aren’t obvious at a glance.

Another, the thing that I think I should have done, and that we can all do more of, is to simply not take requests at face value. The project owner at the Defense contractor I worked at didn’t spell out what the reason for the code was. But at least in retrospect, it wasn’t a big leap of logic. “We’re going to build an app to find WiFi signals” is all true, but it’s not the whole truth. Asking them, or myself, “why” enough times probably would have led me to a much earlier understanding. Why? To find the sources. Why? To go to them. Why? Why? Why?

Comedian Kumail Nanjiani, best known for the TV show Silicon Valley and his recent film The Big Sick, took to Twitter recently on this subject.

I know there's a lot of scary stuff in the world right now, but this is something I've been thinking about that I can't get out of my head.

As a cast member on a show about tech, our job entails visiting tech companies, conferences, etc. We meet people eager to show off new tech.

Often we'll see tech that is scary. I don't mean weapons. I mean altering video, tech that violates privacy, stuff with obvious ethical issues.

And we'll bring up our concerns to them. We are realizing that ZERO consideration seems to be given to the ethical implications of tech.

They don't even have a pat rehearsed answer. They are shocked at being asked.

Which means nobody is asking those questions.

"We're not making it for that reason but the way people choose to use it isn't our fault. Safeguards will develop." But tech is moving so fast.

That there is no way humanity or laws can keep up. We don't even know how to deal with open death threats online.

Only "Can we do this?" Never "should we do this?" We've seen that same blasé attitude in how Twitter or Facebook deal with abuse and fake news.

Tech has the capacity to destroy us. We see the negative effect of social media. No ethical considerations are going into dev of tech.

You can't put this stuff back in the box. Once it's out there, it's out there. And there are no guardians. It's terrifying. The end.

It’s a major problem when we’re given so much power in tech, but we’re not doing anything to ensure that we use it safely. Thinking about what we’re doing and being careful not to build things that can be used maliciously is really important.

Make your own decisions. Make your own choices. Make your own judgement.

For engineers in particular, we develop systems. But the systems we develop can be used for different things. The software that I was using in Iraq is the same you’d use in marketing. It’s the same tools. It’s the same analysis.

I guess technologists should realize that we have an ethical obligation to make decisions that go beyond just meeting deadlines for creating a product. Let’s actually take some chunks of time time and think ‘what are the consequences of this system? How can this be used? How can it be misused?’ Let’s try to figure out how we can mitigate a software system from being misused, or decide whether or not you want to implement it at all. There are systems that if misused can be very dangerous.

Don’t get distracted by deadlines and feature requests. Think about the consequences of what you’re building. Build in safeguards to prevent misuse, or don’t build it at all because it’s too dangerous.

I’m asking you to do something about this. Well, I guess I’m asking you to not do something because of this. It’s only fair that we talk a bit about how and when to take a stand.

Let’s say I had a time machine and could go back in time to 2011 and do it all over again. I already have the foreknowledge that this tool is unethical. I’ve accepted this job. I’ve moved across the country from Tempe, Arizona to Brookville, Maryland. I’ve driven the two hour commute to Sterling, Virginia, home of 395 defense contractors awarded 16.8 trillion dollars in contracts over the past 16 years. It’s my first job out of school, and it’s my first day. I don’t have my clearance so I’m an intern. My new project owner introduces me to the team then pulls me into a side room to give me an overview of the project. What do I say?

I think the first thing is to establish a mutual understanding of the task. It’s entirely possible at this point that I don’t understand what the actual thing is, and that I’m overreacting. I ask “Why are we finding these signals” and the project owner says “We want to find people’s cell phones.” “Who’s finding them, and why?” I ask. “I don’t know, probably some soldiers in the Middle East.” “Why?” I repeat. “I can’t tell you that.”

“I can’t tell you that” is something I got a lot from this project owner. It’s code for “I have clearance and I know things about this project. I know what you’re asking and I know the answer but I am not allowed to tell you.”

At this point, I think we have a mutual understanding. The task is to help soldiers find people’s phones, probably attached to those people. The reason is left unsaid but we both know.

This organization is a defense contractor. They build things for the military. It is their core competency. They’re not not going to do this…. On the other hand, I care a lot about not killing people. The company’s goal is to build things for the military. If my goal is not to let this happen, then there isn’t a good fit for me at this company. This probably means that the worst case here is that I’m going to leave today without a job. Either I’ll say no and they’ll fire me, or I’ll say “that’s not something I’m comfortable with, best of luck” and quit. These are the worst case scenarios, not necessarily what will happen.

Before saying no then, I need to consider: Can I afford to leave here without a job financially? Am I likely to be able to rely on my network to get me another job? Have I built up a trust with my employer where I can go to them with this type of thing and feel confident that I’ll be heard out? The answer to these questions was no for me in 2011. Sometimes, something is important enough that you should still do something, but there’s a lot that goes into these decisions. I’d like to think that I would still say no.

Let’s look at another situation, where someone did the ethical thing. A developer we’ll call Alice received a strange request. We want to identify weak passwords in the system to notify users to change them. We’d like you to run a password cracking program on the very, very, large password database.

This was a long time ago, before aged passwords were common. Expiring old passwords wasn’t a straightforward option. Alice thought this was a weird request, but said that if the appropriate paperwork was completed she would be willing.

Alice received the completed paperwork and ran the password crack. The next request was “We’d like the list of users along with their weak passwords”. Alice knew that her coworkers had a valid desire to help customers improve their passwords. She also knew that users often re-used passwords. Combining the email and password into one report could allow someone to log into the customers’ accounts on other websites.

Alice pointed this out to her manager, and together they worked with the CSA team to design an email that didn’t include the password. Customers received notifications about their weak passwords, and there was less risk of the report falling into malicious hands. No one was fired and Alice built up trust within her team.

Different scenarios need different ways of analyzing what you should do. In some cases, the right thing to do say nothing and build the product. It isn’t a simple thing to make this decision.

But don’t get distracted by having to think through it. Sometimes your code can kill people.