To understand why the notion of a profession is ethically significant, we first investigate what it means for an occupation to be a profession. Greenwood (1957) proposes five core characteristics of a profession.

First, a profession has a core body of theoretical knowledge. While a practitioner of a nonprofessional trade (e.g., a mechanic or plumber) may be highly knowledgeable from practical training and experience, professional work requires a combination of practical skill and academic study.

Second, this deep specialized knowledge gives professionals authority. Or, as Greenwood paraphrases, a nonprofessional has customers; a professional has clients. In the former relationship, the customer holds a lot of power; the customer decides what they want, and if the worker cannot meet the demand, the customer can simply look for someone else. In the latter relationship, though, the client depends on the professional to make judgments that the client is not qualified to make for themself; the client’s ability to “shop around” is limited to deciding who can be trusted to act in the client’s best interests. Note that this form of authority is not moral authority, of the sort that matters in deontology, but rather is a matter of in-field expertise and financial relationships.

Third, a profession is given special and often unique privileges by the community. A common example of this is licensing requirements in order to practice the profession. An organization establishes licensing procedures for a profession and persuades legislators to pass laws mandating the licensing, in essence giving the organization authority over who is and is not legally allowed to practice the profession. An organization may also develop certifications, which are not legally mandated like licenses but likewise serve as markers of confidence and may be expected or preferred by employers. Additionally, when a profession develops standards of what constitutes a properly educated professional, an accrediting body (such as ABET for science and engineering disciplines) may adopt those standards for giving a mark of approval to college degree programs. Although licensing is enforced by the law, certification and accredited degrees are only “enforced” by the market. All three serve a similar purpose: they give a professional organization the power to set entry barriers to the profession.

Fourth, a profession regulates itself with a code of ethics. This serves as a counterbalance to the previous point—the community grants the professional organization a monopoly on a particular type of business, and like any monopoly, it could easily be exploited. For instance, suppose the members of a professional organization decided to charge unreasonably high prices for their services. With nobody outside of the organization legally able to set up a competing business and drive prices back down, clients would be forced to pay the demanded amount or else go without a critical service. To prevent such scenarios, a code of ethics states the organization’s commitment to use its privileges in a way that aligns with the community’s well-being.

Finally, a profession has its own culture. Beyond the technical competencies of the job, a new professional learns how to fit in among other members—their common language and lore, social conventions, and ways of viewing the world and the profession’s role within it.

In short, a profession provides a service that is needed by the rest of society, but the deep expertise needed to understand the profession means that it is not easily controlled by nonexpert regulators or market forces. Because of this, the profession and the community establish a sort of social contract in which the profession is granted special authority in exchange for an expectation of self-regulation. Ethics, therefore, is a fundamental part of the concept of a profession.

Throughout this book we discuss the individuals responsible for making technology in very broad terms. They may be the networking experts who make systems communicate or the electronics designers who lay out the newest smartphone, but what parts of technology development and deployment are proper professions and what parts are not?

One part of the process of technology development involves writing software for a smartphone, an embedded device, or a website, among many other options. Let us focus on the experts in this part of development—to what extent are they professionals? We typically call people software engineers if they write software, but what are the parallels to traditional engineering fields like mechanical or civil engineering, which have established themselves definitively as professions?

During the late nineteenth century there was a growing tension between engineers and the firms for which they worked. Many engineers envisioned themselves as practitioners of a technical profession instead of simply employees in large enterprises. The early formation of many of the professional societies for engineers can be viewed as a first step toward the establishment of engineering and technology development as a profession (Layton 1986).

There were four founding engineering societies: The American Society of Civil Engineers (ASCE), founded in 1851; The American Institute of Electrical Engineers (AIEE, later the IEEE), founded in 1884; the American Society of Mechanical Engineers (ASME), founded in 1880; and the American Institute of Mining Engineers (AIME), founded in 1871 (Wikipedia 2022a). The AIEE included some of the most famous technological innovators of the time, including Thomas Edison, Nikola Tesla, and Alexander Graham Bell. In 1963 the AIEE merged with the Institute of Radio Engineers (IRE) to become the IEEE (IEEE 2022b).

A motivation for much of the formation of these professional societies came as fallout from a number of major failures of civilian infrastructure including bridges and roadways, as well as mining and other manufacturing facility accidents. These high-profile failures of engineering and technology, along with a growing class of engineers that increasingly viewed themselves as individual professionals and not simply workers for large firms, spawned the creations of the first engineering codes of ethics. The AIEE adopted its first code of ethics and standards of practice in 1912, followed shortly thereafter by the ASCE and the ASME in 1914 (Layton 1986).

One of the oldest codes of ethics still used in the United States comes from the National Society of Professional Engineers (NSPE). In 1934, the NSPE was founded as an organization for professional engineers with the goal of providing licensure and formalizing the profession. Over the years, professional licensure has become required for undertaking or bidding on certain types of contracts and technology development, including offering “engineering services.” Indeed, the NSPE now administers the professional engineering (PE) exams that are required to practice certain types of engineering and contracting services for things like buildings, bridges, airplanes, cars, and electrical infrastructure. As we will see later, licensure is not as well established or enforced for things like software services and other small technology products.

The Code of Ethics for Engineers was first adopted by the National Society of Professional Engineers in 1964, replacing a previous code dating to 1947. Much of the code, which has undergone revisions throughout the years, focuses on ethical trade practices such as rules on bidding on contracts, a moratorium on accepting bribes, and other standards governing acceptable behavior as a service provider. The code also discusses how to deal with conflicts of interest and balancing objectives of various parties when providing services. The document continues to go through changes, being updated to reflect changing societal values (NSPE 2022b). For instance, earlier iterations prohibited engineers from participating in “collective coercive action” like strikes, but in 2001 that clause was removed. In 2003, a clause was added that engineers should “continue professional development throughout their careers.” In 2006, a clause was added that engineers should practice “sustainable development,” the first time that environmental concerns appeared in the code. And in 2019, a clause was added that engineers “shall treat all persons with dignity, respect, fairness and without discrimination.”

As we have seen throughout this book, many ethical considerations that engineers and technology development professionals encounter do not have easy answers. The NSPE runs a board of ethical review that has over 600 advisory opinions on topics ranging from conflicts of interest to public health and safety (NSPE 2022a). A board such as this represents an effort to continue to stay ahead of changes in the impacts of technology and development to provide guidance to practitioners. Other efforts in this vein include more focused professional organizations like the ACM and the IEEE, which we discuss next.

As we saw in the history of engineering, professions can begin as nonprofessionalized occupations; the transition is gradually brought about by a conscious effort from members of that occupation. The status of “profession” is not a clear-cut category but rather a spectrum.

Many technology-related jobs outside of the traditional engineering disciplines occupy a hazy place on the spectrum of professionalization. In computing, for instance, there are professional organizations such as the ACM, but those organizations’ power extends only as far as the people who join them or otherwise voluntarily follow their standards. According to Johnson (2008), nonprofessionalized computing puts workers in the role of “guns for hire”; when a computing worker is asked to work on a legal but morally questionable task, they are under pressure to either fulfill the request or cede their job to somebody else who will fulfill it. Johnson argues that increased professionalization is needed “to take certain issues out of the marketplace.” That is, in a well-established profession like law or medicine, it is difficult to simply threaten to replace a worker who refuses a request based on the profession’s ethical standards, because the workers who would be hired as a replacement are beholden to the same standards.

On the other hand, a profession relies on higher barriers to entry and stricter specifications for training and practice than do traditional occupations, and these traits come with some risks (National Research Council 2013). Professionalization can place a greater burden on workers to acquire training at their own expense, rather than receive on-the-job training from employers. The profession’s standards can be slow to adapt to changing technologies; these standards can limit innovation by reinforcing older practices and by keeping out unconventional thinkers who do not fit within the profession’s rigid entry requirements. In a rapidly changing field, the roles for which people are hired may themselves evolve so quickly that the profession’s official definition of its job may not match the jobs that are actually in demand.

These factors suggest that professionalization is most effective when a field has developed a stable, widely agreed-upon set of practices; debates about how much to professionalize (especially regarding features like legally mandated licensing) often revolve around whether a field is “mature enough.”

We have seen that software engineering is a prominent example of a technology field in the limbo between profession and nonprofession. Its status has been shaped by professionalization proponents who cite the potential for public harm from faulty software and thus the need for a high standard of competence, and by skeptics who argue that software engineering practices are evolving too rapidly for a fixed set of practices to be reasonable. In the 1990s, the IEEE and the ACM formed the Software Engineering Coordinating Committee (SWECC) to advance software engineering as a profession. One of the first products of this collaboration was a series of reports aiming to articulate a core body of knowledge for software engineering and to establish a consistent definition of the field (Duggins and Thomas 2002). The 1990s also saw efforts to establish licensing for software engineers, with Texas becoming the first US state to require the same licensing for software engineers as for traditional engineering fields. However, the ACM withdrew from the SWECC and announced its position that licensing would be premature and counterproductive. Nonetheless, the licensing movement in the United States continued into the twenty-first century, with the National Council of Examiners for Engineering and Surveying developing a software engineering examination intended specifically for engineers in public service or safety-critical applications. This examination was discontinued in 2019 because there were too few examinees. Despite the relative failure of licensing efforts, though, software engineering has made noteworthy strides in other areas, such as the growth of accreditation for software engineering degree programs (Mok 2010).

We have discussed how professions, as organized institutions, exist in part to moderate the needs of practitioners with the needs of the public. The public wants to receive high-quality, trustworthy services through fair business practices. Practitioners typically want a degree of autonomy in their work that could be sacrificed if too much of the oversight is done by people who lack expertise in the area they are regulating. Hence, while most practitioners are not opposed to all regulation, they are sometimes opposed to regulations that they perceive as being inappropriate, overbearing, or onerous. Professional organizations offer a compromise by regulating from within the community of experts. From this perspective, professional ethics serves as a supplement to the law in response to the limitations of public regulation.

Consider the handling of medical negligence suits in courts in the United Kingdom (Jones 2000) and the United States (Gossman et al. 2020). These cases involve evaluating whether a physician or other healthcare professional harmed a patient by failing to follow appropriate standards of care. Such standards are not necessarily codified into law—instead, the courts often call upon “expert witnesses” from the medical community to help determine what the appropriate standards are.

Why rely on expert witnesses to articulate the standards in each case, rather than writing those standards into comprehensive laws? As mentioned above, one argument is that only people with deep expertise are qualified to set the standards, and the people with the expertise are different from the people in charge of making laws. Additionally, standards can evolve quickly; when researchers discover an important new technique or invalidate a technique that was previously accepted, practitioners may need to change faster than the law can adapt.

Many technical professions share a critical feature: often the rate of change in technology outpaces the rate of change in the legal system, leaving a “policy vacuum” (Moor 1985) in which current regulations do not prescribe a way to handle the newest developments. Recent examples include the standard practice of collecting data and cookies about every user that comes to a website without requiring explicit permission, a practice largely shaken up by the introduction of the General Data Protection Regulation (GDPR) and other data processing and notification requirements passed in 2018 in the European Union. Likewise, in the early years of AirBnB, many cities did not have particular legislation in place about renting out one’s own apartment. In the ensuing years there have been numerous legal battles attempting to clarify the legality of renting out one’s home, who’s responsible, and how its insurance works. In technical research, advances are made at the pace of dissemination of advances that, with modern platforms, can be days after an innovation is made. Likewise, within the business domain, the mantra of “move fast and break things” (Vardi 2020) often does not leave room to wait for regulation to catch up to the technology being developed.

Technology is developing rapidly, and the law is shifting constantly to try to accommodate these advances by refining existing language to include new technologies, or by finding new legal frameworks that offer precedents that can guide the legislation of technology. Just as important as the changes in technology itself are the changes in how technology is conceptualized and understood both in the law of the land and in the minds of the public that uses it. For example, after the advent of online mail (email) being run by third-party companies, it was unclear to many that email is actually more similar to a postcard, where the contents are plainly visible to the entity passing it around, than to a post in a sealed envelope. This lack of nuance in the distinction laid the foundation for questions such as “Who or what is allowed to analyze email that passes across a server? ”

In many online email platforms, the email is read by algorithms, not real people, but before the rise of third-party email providers, it was not anticipated that a program would read your email in order to serve advertisements. However, once this became a reality, a legal interpretation was created that still protected a user’s right to privacy from the government, even though a commercial algorithm was reading their mail. Many of our notions of privacy for email rely on resoning based on the metaphor that mail to our home and mail to our computer are similar. However, in thinking about privacy, this metaphor fails us: sealed physical mail is afforded many more legal protections than online mail. Indeed, most online mail is typically read by algorithms for target advertising and user profiling (Gould 2014). However, even this landscape is rapidly changing as services such as Gmail and others attempt to turn what was once consumer facing free products into productivity tools for large corporations. Within the realm of corporate productivity, there is often a much more rigid expectation of privacy on the part of the corporation purchasing the tool, and this has required a change in how these tools handle data (Wakabayashi 2017). Here we can see that a technology (email) is interpreted through the metaphor of an older law (private mail), but not always strictly.

Unexpected effects of new technologies can take regulators by surprise. For instance, companies such as Bird Rides, which allow freestanding electric scooters to be rented via mobile app, deployed their scooters in many cities suddenly and with little warning to local governments. Unanticipated issues arose, including high rates of accidents, unclear liability for accidents, and parked scooters obstructing walkways; this prompted some cities to temporarily ban the scooters until regulatory questions were resolved (Herrman 2019). Another example from the early 2010s are ride-sharing companies such as Uber and Lyft. Both of these companies operate under the idea of a “cab service” or “giving a ride to a friend,” and the specifics of legal liability and even local licensure for cabs has been bitterly contested in courts since the beginning, with some cities completely banning Uber and Lyft (Ongweso and Koebler 2019). These examples illustrate how law can lag technology development, and why professional ethics codes such as the ACM’s encourage developers to take a proactive role in how technology is integrated into existing societal structures.

Despite the distinction we have made between regulation by lawmakers and self-governance within a profession, these realms do not exist in isolation from one another; dialogue between lawmakers and professionals helps to shape the law. When both parties prioritize the public interest, this interaction can benefit consumers. For instance, many of the fundamental rules for governing traffic and regulation on the internet were written in collaboration between the public, private companies, and academics in the World Wide Web Consortium (W3C) and governing bodies at the Federal Communications Commission (FCC) and other regulatory bodies.

On the other hand, in some cases professionals’ influence over the law has undermined consumer welfare. For instance, in 2018 and 2019, a new software system that was omitted from manuals caused two fatal crashes by Boeing 737 MAX airliners. Remarking that the United States Federal Aviation Administration (FAA) had been unusually slow to ground any further flights by these planes, commentators suggested that close relationships between FAA inspectors and Boeing’s own safety experts may have contributed to this regulatory delay (The Economist 2019). Other examples of the complex interplay between technology professionals, the public, businesses, and governments include the history of safety belts (Nader 1965) and stock market trading (Lewis 2014).

In addition to thinking about the impacts of your own work, we encourage you to think about the ways in which the laws and regulations related to technology could be better, and what part you can play in improving them. This is not dreamy idealism! Both the law and professional codes of conduct are works in progress, and as citizens with specialized knowledge, you play an active role in helping to build or revise these statutes. Part of what you are doing, when you make choices about how to act, is participating in the ongoing civic discussion of how technology should be used and regulated. Beyond your everyday practice of technology development, you may very well be in a position to have an impact on the direction that the law takes. These impacts can be made through professional organizations and standards which either inform or become the law, such as IEEE open requests for comment on standards from image exchange to responsible algorithms. As we discuss in the next section, the rules and guidelines from these professional organizations are living documents and professionals are actively encouraged to refine these rules. Likewise, even as an individual you are empowered through commenting, blogging, public talks, testifying in a court or to a legislature, teaching, or petitioning, to name only a few avenues of public engagement.

Prioritizing the public good. The codes quoted below emphasize this as one of their most important concerns by placing it as one of the first clauses and by using strong wording such as “hold paramount.” This echoes the idea of a profession being a sort of contractual exchange with society, with practitioners gaining special privileges and owing special duties to humanity in return. Both the IEEE code (via “sustainable development” in the main clause) and the ACM code (in the elaboration, not shown) group environmental concerns with the public good, suggesting a utilitarian view of nature as a contributor to human welfare.

• ACM 1.1: “Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing.”
• IEEE 1: “To hold paramount the safety, health, and welfare of the public, to strive to comply with ethical design and sustainable development practices.”
• SECEPP 1.02: “Moderate the interests of the software engineer, the employer, the client and the users with the public good.”

Avoidance of harm and disclosing risks thereof. Along with the general directive for the public good, these codes specifically emphasize care when building safety-critical systems in which flaws could lead to tangible damage (think of the computer systems that control an airplane, a medical device, or a nuclear power plant). The ACM’s version is much more broadly worded than the others, but its elaboration emphasizes “unintended” and “unjust” harm; the code is carefully phrased so that it does not necessarily prohibit society members from working in areas like weapons development or cyberwarfare.

• ACM 1.2: “Avoid harm.”
• IEEE 1: “To disclose promptly factors that might endanger the public or the environment.”
• SECEPP 1.03: “Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. The ultimate effect of the work should be to the public good.”
• SECEPP 1.04: “Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents.”

Honesty. These codes cover avoiding deception in a variety of forms, from untruthful personal statements to dishonest business practices.

• ACM 1.3: “Be honest and trustworthy.”
• IEEE 4: “To reject bribery in all its forms.”
• SECEPP 1.06: “Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools.”
• SECEPP 4.04: “Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices.”

Accurate assessment. Besides negative mandates against intentional deception, these codes include positive mandates for making sure claims are well supported.

• ACM 2.5: “Give comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks.”
• IEEE 3: “To be honest and realistic in stating claims or estimates based on available data.”
• SECEPP 6.07: “Be accurate in stating the characteristics of software on which they work, avoiding not only false claims but also claims that might reasonably be supposed to be speculative, vacuous, deceptive, misleading, or doubtful.”

Avoidance or disclosure of conflicts of interest. A conflict of interest is a situation in which a professional is serving multiple parties (possibly including the professional themself) and acting in the interest of one party may harm another. For instance, suppose a client hires a consultant to help decide whether the client’s business should purchase a certain software suite. There could be conflict of interest if the consultant also works for, or owns stock in, the company who makes the software. In both cases, it would be difficult for the consultant to make an unbiased judgment, because there are incentives (either benefit to the other client or personal profit) to treat the software suite favorably.

• ACM 1.3 elaboration: “Computing professionals should be forthright about any circumstances that might lead to either real or perceived conflicts of interest or otherwise tend to undermine the independence of their judgment.”
• IEEE 2: “To avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist.”
• SECEPP 4.06: “Refuse to participate, as members or advisors, in a private, governmental or professional body concerned with software related issues, in which they, their employers or their clients have undisclosed potential conflicts of interest.”

Nondiscriminatory treatment. In the ACM elaboration, sexual harassment and bullying are regarded as forms of discrimination. This recognizes that the effects of harassment go beyond the experience of the victims of the individual acts; the mere possibility of harassment creates a pervasive climate that discourages participation by those most likely to be targeted.

• ACM 1.4: “Be fair and take action not to discriminate.”
• IEEE 8: “To treat fairly all persons and to not engage in acts of discrimination based on race, religion, gender, disability, age, national origin, sexual orientation, gender identity, or gender expression.”
• SECEPP 8.07: “Not give unfair treatment to anyone because of any irrelevant prejudices.”

Education of the public. No technical field exists in isolation; ultimately, nonexperts will need to interact with, and help regulate, the technology created by the experts. This requires the professionals to develop a common language with the rest of society.

• ACM 2.7: “Foster public awareness and understanding of computing, related technologies, and their consequences.”
• IEEE 5: “To improve the understanding by individuals and society of the capabilities and societal implications of conventional and emerging technologies, including intelligent systems.”
• SECEPP 1.08: “Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline.”

Working only in areas of competence. In other words, the codes quoted below urge computing professionals to only accept tasks for which they have the appropriate skills. They have this principle in common with the National Society of Professional Engineers, whose code of ethics lists it as one of the “fundamental canons” of engineering. However, for many computing workers, their areas of competence are less clear-cut than for engineers: Practicing engineering in many jurisdictions requires a license that establishes specific competencies, while there is less regulation around what competence means in most computing fields. In both engineering and computing professions, though, the principle implicitly asks the professional to understand the limits of their own skill set in addition to having the required degrees and certifications.

• ACM 2.6: “Perform work only in areas of competence.”
• IEEE 6: “To undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations.”
• SECEPP 2.01: “Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education.”

Credit-giving and respect for intellectual property. If you are a student, the violation of this principle you may have heard about most is plagiarism, the direct reuse of others’ work without giving credit. This is distinct from infringement of intellectual property such as copyrights, trademarks, and patents; plagiarism is about attribution of the work, and intellectual property infringement is about permission to use the work.

• ACM 1.5: “Respect the work required to produce new ideas, inventions, creative works, and computing artifacts.”
• IEEE 7: “To credit properly the contributions of others.”
• SECEPP 2.02: “Not knowingly use software that is obtained or retained either illegally or unethically.”
• SECEPP 7.03: “Credit fully the work of others and refrain from taking undue credit.”

Professional development. In each of the codes below, this includes both self-improvement and helping colleagues, and both technical and ethical development. The principle recognizes that computing is a rapidly changing field, so quality work requires continued education throughout a professional’s career.

• ACM 2.2: “Maintain high standards of professional competence, conduct, and ethical practice.”
• ACM 3.5: “Create opportunities for members of the organization or group to grow as professionals.”
• IEEE 6: “To maintain and improve our technical competence.”
• IEEE 10: “To assist colleagues and coworkers in their professional development and to support them in following this code of ethics.”
• SECEPP 7.02: “Assist colleagues in professional development.”
• SECEPP 8.01: “Further their knowledge of developments in the analysis, specification, design, development, maintenance and testing of software and related documents, together with the management of the development process.”
• SECEPP 8.06: “Improve their knowledge of this Code, its interpretation, and its application to their work.”

Accepting and giving review. Professional engineers are often called on to review drawings and other technical work which needs peer review before being deployed or sold to the public. Similarly, it is common in software development to use peer review to ensure good programming practices. This requirement is also especially prominent in academia, where a paper is traditionally expected to undergo peer review, with other researchers acting as gatekeepers, before being published and accepted as credible. The purpose of these review processes is not to ensure politeness, but rather to ensure that the work of any individual within the profession is of high quality. Poor work by any member of the profession jeopardizes the entire community, hence it is the responsibility of every member of the community to ensure these standards through the review process.

• ACM 2.4: “Accept and provide appropriate professional review.”
• IEEE 7: “To seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors.”

Workplace confidentiality. Professional work sometimes involves being entrusted with sensitive information; for instance, a company developing an innovative product may expect (or mandate, via a “nondisclosure agreement”) its software engineers not to discuss the design with parties outside of the company, to avoid competitors copying the idea and undermining the product’s profitability. Societies like the ACM generally tell their members to honor these expectations. However, unlike in some professions such as law, this guideline is not absolute. A defense lawyer, at least in the United States, has special legal protections and obligations to keep their client’s admissions of criminal activity confidential because the lawyer-client relationship depends on the client’s willingness to speak freely; meanwhile, a computing professional who learns of lawbreaking by a client might be legally compelled by a subpoena to share this information with the court, and the codes quoted below would make an exception to confidentiality for someone obeying this subpoena. These codes also recognize that confidentiality sometimes conflicts with other principles, like protecting the public good.

• ACM 1.7 elaboration: “Computing professionals should protect confidentiality except in cases where [the information] is evidence of the violation of law, of organizational regulations, or of the Code. In these cases, the nature or contents of that information should not be disclosed except to appropriate authorities.”
• SECEPP 2.05: “Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law.”

Equitable design. This encompasses themes of accessibility: on an individual level, design of systems with disabled users in mind, and on a societal level, consideration of whether less enfranchised people stand to benefit from a technology as much as more enfranchised people. The ACM text was added in the 2018 update, reflecting increased public consciousness around these issues; for instance, machine learning was increasingly used to supplement or replace human decision making in areas such as loan approval and criminal sentencing in which there was a history of racial bias, with infamous cases of those machine learning systems replicating the patterns of bias.

• ACM 1.4 elaboration: “Technologies and practices should be as inclusive and accessible as possible and computing professionals should take action to avoid creating systems or technologies that disenfranchise or oppress people.”
• SECEPP 1.07: “Consider issues of physical disabilities, allocation of resources, economic disadvantage and other factors that can diminish access to the benefits of software.”

Privacy-protecting design. We discuss the meaning and moral significance of this concept in chapter 4.

• ACM 1.6: “Respect privacy.”
• SECEPP 3.12: “Work to develop software and related documents that respect the privacy of those who will be affected by that software.”

The principles discussed above have been present in codes of ethics for decades; for instance, the SECEPP text (Gotterbarn et al. 2001) was adopted in 2000. New principles are emerging as the profession adopts new priorities, however. After previously being updated in 1992, the version of the ACM Code of Ethics reviewed here (Gotterbarn et al. 2018) was updated in 2018 in an iterative drafting process by a task force of computing, philosophy, and policy experts adding the equatiable theme and updating others (Association for Computing Machinery 2018). The drastic change in the ubiquity of the Internet and other computing technologies since then is reflected in the new clause: “Recognize when computer systems are becoming integrated into the infrastructure of society, and adopt an appropriate standard of care for those systems.” Clauses were also added about the previously unaddressed principles: to design systems with security in mind, and to “retire legacy systems with care.” To avoid the code becoming dated quickly as technologies change, the authors avoided references to specific technologies; even machine learning was considered too specific to mention specifically, although some text was added about the extra care needed in managing self-modifying systems. Addressing the ethics of specific technologies was left to additional ACM initiatives outside of the code; we discuss an example in the next subsection.

Sometimes a professional association will have guidelines for certain issues, in addition to the more general principles outlined in a code of conduct. Starting in 2016 both the ACM and the IEEE began to turn their attention to the specific issues surrounding how deeply algorithms have become a part of our daily lives. The IEEE established the standards working group SA 7003 which is specifically focused on developing its Standards on Algorithmic Bias Considerations, dedicated to examining and averting the often-unintentional phenomenon of prejudiced decision-making (e.g., racial discrimination) by machine learning algorithms trained with biased data, as we discuss in chapter 3.

This effort has expanded into a set of IEEE Standards on Ethically Aligned Design efforts (IEEE 2022a) that include starting multistakeholder conversations to create standards and best practice documents for topics including Transparency of Autonomous Systems, Data Privacy, and even Emulated Empathy in Autonomous Systems. Various academic conferences have also sprung up around these efforts including the ACM FaccT Conference on Fairness, Accountability, and Transparency in Machine Learning, Natural Language Processing, and Computer Vision Conference and the ACM/AAAI (Association for the Advancement of Artificial Intelliegence) Conference on AI, Ethics, & Society. Finally, since 2015 there have been numerous white papers and statements of ethics released by governments, academia, and businesses. A critical look at the similarities and differences in these guidelines can be found in Fjeld et al. (2020), who find a “normative core” of principles including concerns for privacy, accountability, safety, transparency, explainability, fairness, human control, professional responsibility, and promotion of human values.

Most directly, the ACM has outlined seven principles for designing and deploying algorithms in order to maximize transparency and accountability. This set of principles, according to the ACM, is intended to support algorithmic decision making while minimizing the potential for harm. These principles are an interesting starting point to think about what issues are important when creating, deploying, and maintaining systems that make decisions with little to no human intervention. We reproduce these principles below with some additional commentary.

1. Awareness: Owners, designers, builders, users, and other stakeholders of analytic systems should be aware of the possible biases involved in their design, implementation, and use and the potential harm that biases can cause to individuals and society. This directive is designed to reinforce the idea that one should consider where, how, and under what considerations algorithms will be deployed. While this may seem obvious to some it is important to remember that this may mean seeking outside consultation or help when creating and deploying systems.

2. Access and redress: Regulators should encourage the adoption of mechanisms that enable questioning and redress for individuals and groups that are adversely affected by algorithmically informed decisions. This is aimed at a notion of legal transparency; people should be able to appeal the decisions of algorithms and institutions. We will see this more explicitly pointed out in some later principles like accountability and explanation. However, the goal of access and redress is an interesting one. For instance, some social networks do not include mechanisms to appeal or recover deleted content. Should all businesses that use algorithmic decision making for moderation and ad placement be required to allow inquiry? The GDPR has recently enacted ideas like this into law. What about algorithmic sentencing, credit approval, or loan approval? For some of these cases (i.e., sentencing) there is an established process for access and redress (appeals), however, with respect to financial credit decisions, there is no universal legal standard. Here we can start to see the tension between professional society directives and established law.

3. Accountability: Institutions should be held responsible for decisions made by the algorithms that they use, even if it is not feasible to explain in detail how the algorithms produce their results. This is a strong statement with an ambitious goal: that organizations and institutions should stand by the decisions of their algorithms. This principle can become murky when one extends the logic to, for instance, driverless cars. Should a company be responsible for every crash an autonomous vehicle has? Think about what accountability means in all the domains where algorithms are used; is it possible to always have a person or corporation be accountable for the algorithms they deploy?

4. Explanation: Systems and institutions that use algorithmic decision-making are encouraged to produce explanations regarding both the procedures followed by the algorithm and the specific decisions that are made. This is particularly important in public policy contexts. Again, in many contexts this explanation is required by law. However, it is an interesting question to consider at what level of detail this explanation must be provided. Does source code always count as a sufficient explanation, or in some cases must data be provided as well?

5. Data Provenance: A description of the way in which the training data was collected should be maintained by the builders of the algorithms, accompanied by an exploration of the potential biases induced by the human or algorithmic data-gathering process. Public scrutiny of the data provides maximum opportunity for corrections. However, concerns over privacy, protecting trade secrets, or revelation of analytics that might allow malicious actors to game the system can justify restricting access to qualified and authorized individuals. Here we can see a tension between the need to disclose information and keeping some things secret. This specific example is interesting in an era when Google and Facebook (among others) are collecting more data about users than ever before. How much of this data should be made public and auditable? What about the data that credit card companies or banks collect?

6. Auditability: Models, algorithms, data, and decisions should be recorded so that they can be audited in cases where harm is suspected. This is a principle that many professional programmers, academics, and system designers, no matter the domain, should follow as it ties into the need for reproducibility. This is again enshrined in legal standards for areas like accounting and safety-critical systems (e.g., airplane autopilots) but has yet to be rigorously enforced across all algorithmic decision-making systems.

7. Validation and Testing: Institutions should use rigorous methods to validate their models and document those methods and results. In particular, they should routinely perform tests to assess and determine whether the model generates discriminatory harm. Institutions are encouraged to make the results of such tests public. This principle is interesting when one thinks about an age of continuous deployment and ever-changing code bases. Should models and algorithms be tested before deployment? What about the results of A/B testing, where two different versions of a service or interface are shown to different people, or live bucket testing in which tests are performed on users without their knowledge? Many companies participate in this type of testing without their users being aware in order to test algorithms with “real users.”

We have noted that professional societies often have their own codes of ethics; in fact, we have seen that having a code of ethics is an essential part of some definitions of a “profession.” Professional ethics can be divided into two types. One type consists of those rules and guidelines that govern behavior and are aimed at preventing cases of professional misconduct and particular disasters—as Harris et al. (2013) refers to them, preventive ethics. Other parts of professional ethics precepts are aimed at positive, or aspirational ethics, aimed at using technology for the betterment of humankind.

Technology businesses have taken an increased interest in promoting ethics at an organization-wide level. But a company’s claim of ethical consciousness deserves scrutiny. One possible trap is conflating regulatory compliance with ethics. Not only have there been innumerable cases throughout history of the law failing to protect certain vulnerable populations, but also, recall that regulators cannot always anticipate the situations that technology developers will encounter, leading to a “policy vacuum.” A code’s guidance can help fill this vacuum, but another possible trap is making only shallow appeals to ethics (Gotterbarn 2020). Lining the workplace’s walls with posters featuring a code can be an effective way for a company to appear morally upstanding while making little change to its actual practices.

So, what are codes of ethics actually for? At a basic level, we could say they exist to state expectations about how a professional should behave. However, this seemingly singular purpose has many different dimensions. To whom are these expectations being stated, and why? Codes of ethics serve both “inward-facing” functions by communicating to professionals themselves, and “outward-facing” functions by communicating with the rest of society (Metcalf 2014).

Recall that the concept of a profession, compared to other occupations, revolves around an exchange of power. Professionals do work that needs regulation, but meaningful regulation requires expertise that only the professionals themselves have. A solution is for the community to hand over regulatory power to a professional organization. The organization’s code of ethics serves an outward-facing purpose by telling the community, in easily understandable language, what to expect from this self-regulation. The code is part of an organization’s strategy to maintain the community’s trust, so that the community will continue to let the profession keep its self-governing privileges.

A clear example of this in the United States is the way medical licenses are given to professionals, which enable them to practice medicine. Each medical practitioner in the United States must be licensed by a state medical board, which is (usually) made up of practicing professionals, and a common national evaluation of training and standards. These boards are (typically) created by an act of the state governing body but the rules, interpretation, and regulation of these rules is left to practicing professionals. Most of these standards are self-imposed by the various professional societies; reviews of practice and ethics are also undertaken by these professional societies, not state legislatures (Carlson and Thompson 2005).

Ultimately, maintaining the community’s trust requires that the profession actually fulfill its promise of good behavior. The inward-facing roles of a code of ethics help ensure the promise is fulfilled. For new professionals, who may have each individually developed different ideas about professional conduct from their respective workplaces and universities, a code gives a standard point of reference (Johnson 2009). For established professionals, a code serves as a continual reminder of the professional culture’s values and aspirations. When a professional resists pressure from outside forces (such as an employer) to act unethically, a code affirms the organization’s support for that professional. And when an organization member or licensed practitioner behaves disreputably, the code may be cited as grounds for revoking their membership or license.

When an ethical question arises, a code of ethics can serve as a decision-making aid. In general, a code is not designed to be a definitive source of answers; however, the code can highlight relevant values and suggest angles for thinking about the problem. For instance, in 2016, the US Federal Bureau of Investigation (FBI) wanted to access encrypted data on a smartphone connected to a terrorist attack and sought a court order that would compel smartphone manufacturer Apple to create software to bypass the encryption. In theory, though, such software could be used to compromise the security not only of this particular smartphone but also of smartphones belonging to Apple customers anywhere. Because of this, a group of Apple engineers considered refusing to build the software if the court order were issued. One commentator (Markoff 2016) invoked the ACM Code of Ethics to discuss this possible protest: The code includes a directive for computing professionals to follow the law. However, it makes allowances for violating the law when there is a “compelling ethical justification.” Since the code also enshrines the principles of respecting privacy and avoiding harm to the public, the commentator concluded that refusing to carry out the court order would be consistent with the code.

On the other hand, one could invoke the ACM code in favor of obeying the court order as well: The code says to “contribute to society and to human well-being,” and from the FBI’s perspective, the encryption-bypassing software was a potential opportunity to discover new information about terrorist plots that could help them save lives. Thus it could be argued alternatively that breaking the law by refusing to build the software would not have a “compelling ethical justification.” This highlights how conflicts sometimes exist between the different directives in a code of ethics. Codes are, as the ACM code itself states, not designed to be “an algorithm for solving ethical problems” but rather to suggest important values that can be used for decision-making when combined with a professional’s own judgment.

The Apple scenario also raises questions of who is beholden to a code of ethics. The ACM code is intended as a guide for all computing professionals. Within the ACM itself, the code is enforceable; the organization reviews reports of members violating the code and may take punitive action against violators. However, both membership in the ACM and adherence to the code for nonmembers are completely voluntary. Furthermore, many professionals answer to employers outside of the profession; since those employers are not beholden to the code, the professionals bear the full responsibility for compliance. Because of these factors, the success of the code depends on personal commitments or consensus within a practicing community, whether that community is the profession as a whole or just a group of practitioners working for the relevant stakeholders. For example, Apple’s “rebellious” culture was cited as contributing to the vocal dissent among the engineers (Markoff et al. 2016).

The truth is that I have never written popular stories. I am not a popular story writer. I am earnest. I am slow. I do not move at the speed these Americans seem to love. Find a story that people want to read. I can write some follow-up to Mackley, to Double DP, perhaps assist with sidebars to his main piece, but somehow, I suspect that the readers will know that I am faking it.

Ong is a deep believer in the value of the press. While still a child in Laos, Ong watched his much-revered father trade away his freedom because he was unwilling to keep silent about the Laotian government’s wrongdoing. Now on a work visa in the United States and working for a major media company, Ong tries to follow in his father’s footsteps by reporting on government corruption and climate change. But American consumers are more interested in infotainment than deeply researched exposés, and Ong’s boss threatens to fire him if he cannot improve his numbers. Ong’s professional community tries to support him in their own way; his much-more-successful colleague Marty sets him up with an interview that could save his job. But Ong seems to understand his obligation to his readers differently from his American colleagues, seeing them not as customers who should be told only what they want to hear but as clients who need to hear the truth, even when they might not want to.