Career Development

Summarized using AI

Scaling the Software Artisan

Coraline Ada Ehmke • May 17, 2018 • Pittsburgh, PA

In the talk titled "Scaling the Software Artisan" presented at RailsConf 2018 by Coraline Ada Ehmke, the speaker explores the evolution of the role of software developers, particularly focusing on senior developers and their transition towards a more innovative and impactful position in the industry. The central theme revolves around drawing parallels between the historical shift of artisans during the Industrial Revolution and current changes in software development practices.

Key Points Discussed:
- Definition and Identity of Developers: Ehmke raises the question of what we should call ourselves in the tech industry, discussing various terms such as architects, scientists, engineers, and ultimately settling on "artisans" as the most fitting description for software developers.
- Historical Context: The talk traces the historical evolution of artisanship and craftsmanship, highlighting how artisans played a pivotal role prior to the Industrial Revolution. The introduction of standardization and interchangeable parts transformed manufacturing and the value of artisanal work.
- Interchangeable Parts in Software: Ehmke discusses how software development is at a similar juncture, moving towards standardizing components and using reusable modules, resulting in a shift from traditional software creation to building upon existing technologies.
- Role of Senior Developers: The evolution of senior developers is emphasized, transitioning from merely producing code to innovating solutions and focusing on the broader implications of their work, such as ethical considerations and the dynamics of team collaboration.
- Mentorship and Standardization: The importance of mentoring and fostering a culture of learning within development teams is addressed, along with the necessity to create standards for both technical practices and ethical conduct in software development.
- Ethical Responsibilities: Ehmke concludes by emphasizing the moral responsibilities developers have regarding the impacts of their work, particularly in light of recent ethical dilemmas in technology, urging developers to think critically about the repercussions of their code on society.

This presentation ultimately encourages the audience to reflect on how they can scale their own impact as developers, suggesting a shift in focus from production to innovation, design, and ethical accountability. The talk serves as a powerful reminder of the potential for software artisans to foster profound changes in technology and society by embracing their evolving roles.

Scaling the Software Artisan
Coraline Ada Ehmke • May 17, 2018 • Pittsburgh, PA

RailsConf 2018: Scaling the Software Artisan by Coraline Ada Ehmke

In the late 1700s the discovery of the principle of interchangeable parts shifted the demand for the expertise of artisans from production to design and invention. This shift transformed Western civilization and opened the way for the industrial revolution. We face a similar opportunity now as one generation of software developers reaches its professional peak and a new wave of developers enter the field. This talk will trace the historical evolution of the artisan and explore how understanding this history can help us to maximize and multiply the impact of senior software developers.

RailsConf 2018

00:00:11.000 Today, it's called 'Scaling the Artisan,' and it's about what it means to be a senior developer. By way of introduction, I am Coraline Ada Ehmke on Twitter @CoralineAda. I judge how well I did in the talk by the number of people who tweet about it, so please be kind.
00:00:17.430 I am a code witch. I once had someone ask me, and I cried, 'What do you call yourself, a code witch?' I'm like, I write code, and I'm literally a witch, so it seems to go together. I have code witch stickers with a wonderful 8-bit witch on them.
00:00:22.859 If you want code witch stickers or greater than code stickers, come up and say hi after the talk. I built my first website in 1994, and I'm proud to say it was in the top 5% of all websites. My new website looks a little bit different, but it's still in the top 5% of all websites.
00:00:34.230 I've been an open-source contributor since 2004. I won a Ruby Hero Award in 2016 for my work in diversifying open source. I should warn you that, according to Breitbart News, I'm a notorious social justice warrior, so you should take everything I say with a grain of salt.
00:00:47.910 I’m a founding panelist on the Greater Than Code podcast, which I strongly recommend to everyone. We have an incredibly diverse lineup of guests, and we talk about the human side of software development. I’m perhaps best known as the creator of the Contributor Covenant, the first open source code of conduct.
00:01:01.410 It has over 40,000 adoptions, including Angular, the .NET Framework, Bootstrap, GitLab, RubyGems, JRuby, and Rails. I’m a principal engineer at Stitch Fix. I've been there for just under a year and am really enjoying it. Stitch Fix is one of the sponsors, so come by and say hi.
00:01:16.680 So, I'm going to start with a simple question: Who are we?
00:01:23.520 Are we architects? An architect is someone who plans, designs, and reviews the construction of buildings. To practice architecture means to provide services in connection with the design of buildings in the space surrounding those buildings with the primary purpose being human occupation.
00:01:35.850 I don't think we're architects. Are we scientists? A scientist is a person engaging in systematic activities to acquire knowledge that describes and predicts the natural world. A scientist uses the scientific method, formulating and validating hypotheses. I don't really validate hypotheses in my work, so I don't think we're scientists.
00:01:46.040 We like to call ourselves engineers. Engineers design material structures and systems while considering the limitations imposed by practicality and regulation. The foundational education of an engineer is a four or six year degree followed by four to six years of practical, peer-reviewed professional practices culminating in a project report or thesis.
00:01:55.270 That's a lot more discipline than the work that we do as software engineers. Are we artisans? An artisan is a skilled craft worker who makes or creates things by hand, which may be functional or decorative. Artisans practice a craft made through experience, achieving a level of expression akin to that of an artist.
00:02:10.800 Naming things is really hard. Maybe we should call ourselves 'firefighting space cowboys' and be done with it! Firefighting space cowboys who, of course, love cat gifs. We all know that naming things is hard, so it’s not even easy to name our profession, but of all the options available to us, 'artisan' seems to come the closest, and we're going to go with that for the purpose of this talk.
00:02:20.430 So, what is an artisan? We all want to preserve our high-paying jobs and work somewhere where we're respected for our skills and talents. We want to be like artisans, so what does that mean? An artisan, as I mentioned, is a worker in a skilled trade that produces things by hand.
00:02:35.460 Artisans were the dominant producers of consumer goods prior to the Industrial Revolution. The best artisans worked directly for merchant princes and nobles, producing unique artifacts that were practically works of art.
00:02:48.850 In medieval times, artisans formed fraternal orders to exchange innovations in their craft, while also protecting their professional secrets from potential competitors and the public at large.
00:02:59.400 Over time, these orders developed their own jargons, symbolic frameworks, and elaborate rituals to represent and preserve their hard-won knowledge. Some of these orders have survived to the modern era, still steeped in mystery, rumor, and legend.
00:03:09.870 By the 12th century, to ensure the smooth succession of artisans and the continuity of their traditions, guilds developed a system of apprenticeship. In the 16th century, seven-year apprenticeships became a legal prerequisite for becoming a craftsman or an artisan.
00:03:24.880 Let’s take a little historical journey and talk about something we take for granted in our daily lives: the screw. The screw thread was invented around 400 BC by Archytas of Tarentum. He was a contemporary of the philosopher Plato and is sometimes called the father of mechanics.
00:03:37.300 Archimedes further developed the screw principle and used it to build machines that raised water. Early screws were used in machines that compressed olives to extract their oil.
00:03:51.080 Hero of Alexandria, a mathematician and engineer who lived in the first century BC, contributed to the field. He tutored at Alexandria's Museum and wrote many books on mathematics, geometry, and engineering, many of which were still in use during the later medieval period.
00:04:02.950 He also invented the first known steam engine. In the second volume of his book Mechanics, he outlines the five mechanical powers: the windlass, the lever, the pulley, the wedge, and the screw.
00:04:18.437 However, it wasn't until the 15th century that screws and threaded bolts started to be used as fasteners. Gutenberg famously used screws as fastenings on his printing press.
00:04:29.420 The use of screws in this capacity gained momentum, and they began appearing in mechanisms like clocks and in items like armor. For centuries, screw heads for fasteners were cut by hand, and there was no standardization. A craftsman would carve and file individual matched pairs of screws and nuts; interchangeability was not a requirement, so custom fitting was the norm.
00:04:54.860 This changed around 1800 when an inventor named Henry Maudslay developed a type of metal lathe that enabled the manufacture of standard screw thread sizes. With Maudslay's lathe, you could reliably produce interchangeable screws.
00:05:07.960 Initially, different manufacturers had their own standards for screw threads. A national standard wasn't established in the UK until the mid-1800s, and even into the 20th century, there was no international standardization of screw threads.
00:05:24.340 This created significant supply and repair problems during the World Wars. In 1949, the Unified Thread Standard was adopted by standardization committees in Canada, the United States, and the United Kingdom.
00:05:40.480 In 1947, the International Standards Organization was founded, and fifteen years later, the metric-based International Standard of Units was created. The ISO metric screw thread was adopted as a worldwide standard.
00:06:03.750 So today, when you need to screw something in or tighten a bolt, you don't go to your local metal worker or artisan—you go to Home Depot.
00:06:16.180 Artisans produce machines and tools, but the most profitable endeavor for artisans for almost 4,000 years was the production of weapons. The sword, as we know it, was developed during the Bronze Age, evolving naturally from the dagger.
00:06:25.560 The earliest specimens were forged from arsenic copper in the Turkish region around 1600 BC. Occasionally, a swordsmith would mix iron with optimal amounts of carbon and accidentally produce a steel blade, but it wasn't until the early Middle Ages that this became a repeatable process.
00:06:41.720 By medieval times, the process of sword making evolved largely in response to the availability of more sophisticated materials. The availability and quality of raw materials drove improvements to the sword making process, not the other way around.
00:06:57.080 By the 16th century, knowledge of gun manufacturing arrived in Europe via Middle Eastern trade. Throughout the 18th century, guns in Europe were made one at a time by artisans known as gunsmiths, and each gun was unique.
00:07:11.840 If one single component of a weapon needed replacement, the entire weapon had to be sent to an expert gunsmith for custom repairs. Often weapons were discarded and replaced.
00:07:22.670 Although the killing power of a gun was significantly higher than that of a sword, firearms did not supplant swords until the early 19th century. American gunsmiths were few and far between.
00:07:37.800 In the American colonies of the early to mid-18th century, there are records of less than 20 gunsmiths. The government tried and failed to entice and mandate gunsmiths to practice there.
00:07:50.670 The raw materials for guns were scarce in the Americas, leading to most guns being imported from France and Germany. Gunpowder and firing mechanisms also had to be imported.
00:08:06.000 A gun back then cost about a year’s income for an ordinary farmer. For comparison, a basic rifle now costs the equivalent of three days of labor at the average national wage.
00:08:18.440 There were attempts at producing professional standards for gunsmithing in Europe, but none in America. This means that every gun produced in America was unique to the artisan who produced it.
00:08:40.170 At the end of the 17th century, Maryland reported an inventory of only 20 muskets, 38 carbines, 16 horse pistols, and 70 barrels of powder accumulated over the past 25 years.
00:08:56.070 In the years leading up to the Revolution, they had 200 muskets, 86 carbines, and 6 pistols in usable order. For each working musket, there were two or more that were deemed worthy or capable of repair.
00:09:10.590 Before the Civil War, America had only two armories: one at Harpers Ferry, Virginia, and one in Springfield, Massachusetts. In an attempt to equip the militias to protect the newly independent country, Congress ordered the production of 7,000 muskets in 1793.
00:09:24.110 A year later, they only managed to buy 400. In the late 18th century, a French general named Gribeauval saw this resource-intensive approach as a problem and promoted the idea of standardized parts for weapons.
00:09:38.530 This approach came to be known as the system of Gribeauval and became law in France through a royal order. By around 1778, France began producing some of the first firearms with interchangeable flintlocks, but the parts were still made carefully by craftsmen.
00:09:52.250 In the U.S., Eli Whitney saw the potential benefit of developing interchangeable parts for firearms used by the United States military. In July of 1801, he went before Congress, built ten guns containing the exact same parts and mechanisms, and disassembled them in front of all the congressmen.
00:10:06.180 He placed the parts in a giant pile and, with help, reassembled all the weapons in short order. It was the development of interchangeable parts that led to predictable production. We no longer needed artisans to produce weapons, and artisans could shift their focus toward design and innovation.
00:10:18.670 Today, of course, guns are mass-produced and can be bought for under $200. 5.5 million guns were produced by the United States last year, and their ready availability means we have a new set of ethical dilemmas to deal with.
00:10:33.150 The Industrial Revolution upended many aspects of society, making some better and some worse, but predictable production with interchangeable and standardized parts raised the quality of life for most Americans and allowed us to realize the promise of new technologies.
00:10:47.310 Today, we associate mass production with low quality and low-skill labor. We prefer to buy things with 'artisanal' in their name, from sandwiches to bread to beer to clothing. For many of us, mass production smells like commoditization, and we don't want that!
00:11:10.140 But that's classist and elitist, and I don’t want that in our profession either. So, how does the changing nature of artisanal work and the impact of the Industrial Revolution apply to our industry?
00:11:25.520 I would argue that we're at the beginning of the process of standardizing on interchangeable parts, and we're going to soon have to deal with the commoditization of code. Early computing pioneers had to invent everything.
00:11:39.850 This picture shows the Bombe, one of the earliest computers developed by Alan Turing during World War II to break the Nazi Enigma cipher. The hardware and software to run the Bombe were tightly coupled, and hardware standardization in the 70s and 80s led to creating more general-purpose programming languages.
00:11:54.660 These languages can be compiled across a small number of architectures. Standardized hardware platforms were a material innovation, not unlike the consistent production of steel in medieval times, allowing us to focus on what we produce on top of the material layer—in other words, software.
00:12:09.530 With the advent of the web and the increasing versatility of front-end frameworks, the browser is becoming our main platform. This has only been possible because of the creation and wide adoption of standard protocols.
00:12:26.520 TCP/IP is the lowest level protocol, with HTTP and HTTPS on top of it, along with a standardized front-end language like JavaScript. Just like the standardization approach that the ISO took for screws, these standard protocols are enabling a revolution in the production of software.
00:12:42.630 Behind the scenes, our backend code runs in a variety of languages, but it operates on increasingly standardized server platforms. In the early days of the Internet, servers were owned by the same companies that produced the software, and they spent a lot of time ensuring the reliability, maintainability, and security of their data centers.
00:12:58.390 These days, most servers live in the cloud, and we don't know or care what hardware they use, so data centers have become a commodity.
00:13:12.030 The age of DevOps has arrived, allowing us to focus more on crafting software instead of crafting tools. Modernization happened to hardware and server infrastructure, and software is next.
00:13:25.410 More and more software development is shifting to reusable components like NPM modules or Ruby gems that can be assembled to provide large swathes of functionality for our apps.
00:13:42.130 We no longer have to roll our own authentication or data visualization or our own UI frameworks. AWS provides building blocks for enterprise-class software architectures.
00:13:56.650 We no longer have to invent, create, maintain, or own data storage, file storage, caching, search, or messaging services. Our tools generate scaffolding on top of which we build our applications.
00:14:07.689 We don't have to write boilerplate code anymore. As an aside, the term 'boilerplate' was first used to indicate reusable chunks of text that typesetters didn't need to type by hand for use in newspapers.
00:14:24.460 There was a metaphor from the 1910s to the 1940s of large rolls of metal in flat plates for use in making steam boilers.
00:14:38.740 We're using more standardized parts to build our software and shifting our attention from assembling machines from reusable components instead of inventing steel or machining our own custom screw threads.
00:14:58.200 And today, I don't know if you saw this, but NASA is even working on a machine learning system that will allow users to produce programs without writing their own code.
00:15:10.820 In short, we're inventing ourselves out of traditional software jobs. Software development is increasingly about connecting pieces of existing technologies together with a small amount of glue code and a sprinkling of custom algorithms.
00:15:29.220 This is just like the beginning of the Industrial Revolution, but just as the Industrial Revolution didn’t eliminate the need for artisans, neither does it signal the end of software development.
00:15:44.110 It just means we have to adapt. The job of the future is not the job you're doing today.
00:15:57.230 So, let's talk about artisanship in a modern context. There was a tweet exchange between DHH and Sara May a few weeks ago.
00:16:12.240 Sara said we're starting to differentiate software developers from software engineers. An engineer builds complex software systems that run in the context of people, while a developer writes code.
00:16:28.530 I took exception to this because it struck me as very classist. It's not 'us' versus 'them.' It's not about engineers versus developers; it's about who we are and who other people can aspire to be.
00:16:45.010 It's our job to bring them up to our level. So, I responded. I think it's important to create software in the context of people.
00:17:01.530 That's a critical skill for early career developers, but it becomes essential as one progresses in their career. A senior developer without empathy for end-users is not truly a senior developer.
00:17:16.350 You might think that as you progress in your career, the only thing that should change is the quality of your code and designs, but that's short-sighted.
00:17:30.960 You're expected to deliver more complex code—code that is readable, elegant, and performant. Your job is about more than just delivering story points.
00:17:46.520 You're no longer simply responsible for writing code; you're shifting from being a producer to an innovator. You’re now expected to focus on creative solutions to challenging problems.
00:18:01.400 Some of these solutions won't even involve code. But when they do, you'll be the one designing custom algorithms with a clear focus on exactly the problem you're trying to solve.
00:18:17.740 You have the skills now to invent what needs to be invented. You should ask yourself: Should we solve this problem with code?
00:18:33.290 Some problems are best solved with process improvements that don't require a code solution. Not every spreadsheet that someone in your company uses to track work should be turned into a new Rails application.
00:18:50.090 That runs contrary to what I used to say, which was that every spreadsheet was an application. That didn't happen. Sometimes, a spreadsheet, even on paper, is good enough.
00:19:06.900 We should also ask ourselves: Can we fix this without code? Most software problems are people problems, and most people problems come down to communication.
00:19:22.380 Many process-related features that we're asked to develop are organizational scars over a communication wound. If the feature that your team is asking to build is ultimately just a band-aid on a bad communication channel, is this something we should build ourselves?
00:19:38.270 It's our job to distinguish between the category of just doing business versus doing something that's unique to us. If your company is in the fashion retail business, for example, like mine, you might consider machine learning to pick out styles and make recommendations.
00:19:52.660 But if that's your business, you probably don't want to design a custom data warehousing system because that's not core to what your business does.
00:20:05.920 There's nothing wrong with building it yourself if you really need it, but we need to evaluate third-party solutions and weigh their cost against the cost of engineering.
00:20:20.080 Often, what you'll find is a 90% solution. The missing 10% can be painful, but it takes someone with experience to distinguish between a good enough solution and the best solution.
00:20:34.520 We can also ask ourselves: Should we extract this into a library? A library is a good way to ensure that your innovation becomes more widely used in your organization or in the larger open-source community.
00:20:50.110 It's a way to demonstrate best practices to other developers, and it's a way to democratize the output of your labor by having other people use it, modify it, fix it, and extend it.
00:21:05.740 Our second job is standardization, which means picking the right components, standardizing best practices, and sharing knowledge through communities of practice.
00:21:21.230 The questions we should ask ourselves include: How do we want to do things around here? This might involve creating a style guide or establishing architectural patterns that will be repeated across all services in your application infrastructure.
00:21:36.560 How do we build consensus? Good, solid, healthy development organizations don't do things by fiat. When you're trying to build consensus, start with something that everyone agrees on.
00:21:52.299 For example, saying a shared database is a bad idea doesn't let people share their ideas and alternatives. Focus on one alternative at a time, describing each alternative's strengths, and then repeat the process, describing each alternative's weaknesses.
00:22:06.370 Make sure that everyone is heard and make room for dissent. Make room for people of all skill levels, who often have insights that we as senior developers don't have.
00:22:22.940 Draw them into the conversation, deliberately say, 'Sara, we haven't heard from you. What is your opinion on this particular approach?'
00:22:37.320 Even if you can't reach consensus, everyone will at least feel like their needs and ideas were considered. Finally, how do we spread those practices?
00:22:54.840 At one company I worked for, we had community of practice meetings every other week—a video call where people interested in a particular language or framework would come together to discuss ideas.
00:23:10.900 At my current job, we have a principals meeting where all of the principal engineers come together to discuss ways to improve the quality of the codebase and standardize.
00:23:25.320 We also maintain a shadow backlog of engineering and technical debt, as well as engineering ideas we want to implement, and we share that with the broader team.
00:23:39.960 Of course, you can always use a Slack channel as a special interest group for a particular language, framework, or technology.
00:23:55.490 Our third job is being a force multiplier, and this involves mentoring and teaching—helping our teammates level up and giving back to the community.
00:24:09.029 A question we could ask is: Do we have a good mix of people? Diverse experiences and diverse experience levels lead to better problem solving.
00:24:23.139 We have to recognize that not every software problem requires a senior principal developer.
00:24:40.130 We should ask ourselves if we're pairing people in effective ways. In his book, 'Apprenticeship Patterns,' Dave Hoover lays out what he calls the Boxcar Theory.
00:24:54.741 Imagine a train with boxcars and an engine at one end. Toward the end of the train, you have early career developers, and as you move right toward the engine, you have developers with increasing levels of experience.
00:25:10.040 A lot of companies will pair a very senior person with a very junior person. This is actually a mistake because people who are closer to one another on the train have a greater memory of what it was like to be at that previous stage.
00:25:26.230 They have more empathy as a result and are better able to share knowledge and remember the tips and tricks that helped them level up.
00:25:43.670 Then, we ask ourselves how to help the team level up, and it’s through mentoring and pairing. Code show-and-tell is one way to do this.
00:25:55.120 We do this at Stitch Fix, where whenever a developer creates something they think is cool, innovative, or a good solution to a problem, they walk through the code in 20 minutes and share their ideas and what they did with other developers to get feedback.
00:26:12.070 Of course, humane code reviews come into this process as well. As a senior developer, your code review should not be vicious.
00:26:26.190 You should never ask, 'Why didn't you just...?' and should never be overly critical of the code. You should always be asking questions and helping people arrive at their own conclusions.
00:26:40.490 So, innovate, standardize, and multiply. But are we done? I mentioned that the mass production and ready availability of guns created an ethical dilemma.
00:26:55.000 So does the mass production and ready availability of software. No one wants to be accountable for gun violence, as we've seen in the political situation in America today.
00:27:10.150 And also, no one wants to be accountable for the injustices done by naive, biased, or altogether malevolent algorithms. This is on us to figure out before it becomes an epidemic, if indeed it has not already done so.
00:27:26.240 This is our fourth job, and in some ways, our most important job: we have to be the conscience of our companies and our industry as a whole.
00:27:41.430 We have to decide what is possible versus what is right. There are a number of questions we should be asking ourselves and our companies about the software we're writing.
00:27:55.000 Examples include the Facebook Cambridge Analytica data scandal, which involved the collection of personally identifying information for over 87 million Facebook users.
00:28:09.640 It actually started in 2014, and the data was used to influence voter opinion on behalf of politicians who hired Cambridge Analytica. We knew about this as early as December 2015 when The Guardian reported that politician Ted Cruz was using data from Facebook.
00:28:27.860 Many subjects of the data were unaware that the company was selling their information. Politicians were buying that information; engineers just like us exploited that system to influence a presidential election.
00:28:45.070 This is a moral failing on the part of engineers. Facebook engineers didn't do their jobs; they didn't ask the question, 'Can the data we're providing be used for unjust political gain or even to undermine our democracy?'
00:29:01.370 Another example is the gay hookup app Grindr, which has 3.6 million daily active users around the world. It was recently revealed that Grindr was providing its users' HIV status and last tested date to other companies.
00:29:17.920 Because the HIV information is sent together with GPS data, phone IDs, and emails, the data could actually be used to identify specific users. Grindr's engineers didn't do their jobs; this was an ethical failing.
00:29:30.210 Their engineers didn't ask the question: 'Is the data we collect and share putting people's lives in danger?'
00:29:44.920 Another example is algorithmic hiring. More and more Human Resources staff rely on data-driven algorithms to assist with hiring decisions and navigate the vast pool of potential job candidates.
00:30:02.610 Software systems can be so efficient at screening resumes and evaluating personality tests that 72% of resumes are weeded out before a human even sees them.
00:30:18.540 However, there are drawbacks to this level of efficiency. Man-made algorithms are fallible and may inadvertently reinforce discrimination in hiring practices.
00:30:34.350 Algorithms mimic human decision-making and are trained based on past successes, which may embed existing biases. In an experiment, recruiters identified identical resumes and were shown to select applicants with white-sounding names over those with black-sounding names.
00:30:50.180 So, if the algorithm is trained on data like that and learns what a good hire is based on biased data, it will make biased hiring decisions.
00:31:06.160 The result is that job applicants are judged based on subjective criteria, such as their names, latching onto the wrong features. This approach discounts the candidates' true potential.
00:31:23.600 Algorithms are not neutral. When humans build algorithmic screening software, they may unintentionally determine which applicants will be selected or rejected based on the wrong information.
00:31:36.650 This perpetuates systemic bias, leading to legally questionable and morally unacceptable results. Engineers who write algorithmic hiring software are not doing their jobs; this is an ethical failing.
00:31:52.540 These engineers are not asking themselves the questions they should be asking: Are the algorithms we're creating perpetuating systemic bias?
00:32:11.270 Sophia Noble, a professor of communication at the University of Southern California, recently published a book called 'Algorithms of Oppression.' She argues that while most people think of Google and other search engines as public libraries, trusted places for accurate information, these platforms are increasingly not trustworthy at all.
00:32:28.700 She performed searches on terms like 'black girls,' 'Asian girls,' and 'Latina girls,' finding pornography as a primary representation on the first page of search results.
00:32:46.660 That's not a fair or credible representation of women of color; it reduces them to sexualized objects. Search engines aren't merely selecting what information we’re exposed to, but are cementing assumptions about what information is worth knowing.
00:33:03.540 There's a dominant white male Western-centric point of view that gets encoded into the structure of information. An algorithm is just a structured decision tree.
00:33:19.560 'If these keywords are present, then a variety of assumptions must be made about what to point to among all the trillions of web pages that exist.'
00:33:23.550 Google’s engineers are not doing their jobs; this isn't ethical failing. Search engine engineers are failing to ask the question, 'Is the algorithm we've developed reinforcing stereotypes?
00:33:40.180 In 2013, the city of New Orleans entered into a relationship with a company called Palantir, which is largely funded by the CIA, to implement predictive policing.
00:33:57.810 The city's agreement with Palantir was secret, never revealed to the public or subject to a vote or deliberation. The company provided the police force with hit lists of people that their algorithms indicated were sources of potential violent crimes.
00:34:12.390 Government-funded research cast doubts on the effectiveness of predictive policing, indicating that it disproportionately impacted poor communities of color. Predictive policing perpetuates systemic bias against over-policed communities of color.
00:34:29.420 Palantir’s engineers are not doing their jobs; this is an ethical failing. These engineers failed to ask the question: Is the algorithm we're creating putting marginalized people in harm's way?
00:34:44.360 Facebook’s chief technology officer, in the wake of the Cambridge Analytica scandal, told the media that the company would start mapping out potential threats from bad actors before launching products—a response ten years too late.
00:35:05.360 If you're not thinking about how your features could be abused and put people at risk, you're not doing your job. This is an ethical failing.
00:35:19.710 Marco Rogers wrote that Facebook is literally destroying the Internet, and Google was a trash fire of white supremacy. But all we remember is the execs—all the employees doing the dirty work are going to be fine.
00:35:34.950 We're putting blame on the businesspeople who requested features like this from us, but ultimately we should be held accountable for the code that we write.
00:35:52.080 We need to acknowledge that software doesn't exist in an ethical or moral vacuum. W.B. Yeats wrote, 'Nobody running in full speed has either a head or a heart.'
00:36:03.770 We can just slow down and consider the impact of the software that we're creating. Algorithms can be weapons, and if you're willing to build a weapon, you'd better be comfortable accepting the responsibility for the people it kills.
00:36:19.370 So, innovate, standardize, provide, and be ethical. Those are our jobs.
00:36:35.000 What does that mean for the future of our jobs? We need to scale. Just as the Industrial Revolution didn't eliminate the need for artisans but changed the role of the artisan, moving their focus from production to design and innovation.
00:36:50.500 We can foresee the same thing happening to software artisans. Artisanship in a production capacity doesn't scale, but just as raw materials led to improvements in sword making, improvements in the availability and quality of software developers can drive improvements to our craft.
00:37:05.140 We now have tools that make producing code easier and lower the bar to entry. We don’t have to waste all our artisanal effort on low-value parts of the system.
00:37:20.220 Packaged solutions are often good enough, and the output of a less seasoned developer may also be good enough. We don't need senior engineers to build every feature in a software system.
00:37:35.060 We can reserve the effort and cost of the artisanal approach for the parts of the system that matter the most. Artisans, after all, are an expensive resource, and we need to use them wisely.
00:37:50.920 Predictable, low-cost friction means that the attention of the artisan can shift away from manufacturing. Artisanal effort applied to design becomes a force multiplier and a source of previously untapped value.
00:38:06.930 The fear of competition among artisans created bottlenecks in innovation and production that took the Industrial Revolution to overcome. Competition drives innovation, but only up to a point.
00:38:22.160 To truly change the world, we need to turn our attention to creating standards—technical standards as well as ethical standards.
00:38:39.440 By working with our peers and finding opportunities to teach, learn, help, and most importantly work in an ethical way, we foster innovation, become better at our craft, and ensure the generation of new groups of artisans.
00:38:54.480 No secret handshakes required. Thank you.
00:39:06.930 I wanted to take a moment to announce a new project that I have in the works: a book that I'm co-writing with Naomi Freeman called 'The Compassionate Coder.' In the book, we're describing a framework for dealing with the changing role of software developers.
00:39:36.970 We're practicing empathy in software development—empathy for the modern age. The book will help you learn how to better integrate your teams for efficient and profitable outcomes, learn about your own role in a changing workplace, and teach you how to be a leader, not only in your workplace but in the larger tech community.
00:39:54.480 We're hoping to publish later this year. You can sign up for updates at CompassionateCoder.com. We're using that to gauge interest in our book.
00:40:03.480 So please do sign up; it’s a low-volume mailing list, and we would greatly appreciate your support. Thank you.
Explore all talks recorded at RailsConf 2018
+98