Hi, everybody. Nice to see so many friends
here, old and new. I am going to go ahead
and get started. I have seen the rumors on
Twitter, and I can honestly tell you the answer
is no. I did not write this talk to win a
bet. A bet that said I got a $500 steak dinner
if I won. And to win, I had to figure out
how to bring the story of the electrocution
of an elephant to a Ruby conference. The
elephant part is true. 
I have 25 years of software development experience. I'm
currently serving as an architect at a company
called Stitch Fix. We're in the lobby. I
am co‑authoring a book called "The Compassionate
Coder." I am a troublemaker. I released the
Hippocratic license, and I have also launched
the ethical source definition. I am fighting
to give us as developers control over how
our software is being used. 
If you're interested in the license, go to
do no harm.dev. And if you're interested
in the definition, ethicalsource.dev. I have
a special tweet for you. If you tweet about
this talk and @ mention me, you will be
entered ‑‑ tweet something that you learned
from the talk, I will pick the best answer
and give you a giant Nikola tesla bobble head
with a glow‑in‑the‑dark light bulb in
his hand. 
Let's meet our heroes. Thomas Alva Edison
born 1847, an American inventor accredited
with the invention of the phonograph, motion
picture camera and first practical light bulb. He
is what I call a direct current fanboy. 
Edison invested the money that he made from
his early patents into what he called the
Invention Factory, which is a facility in
Menlo Park, New Jersey, staffed with engineers,
mechanics, and machinists. His first patent
was for an electrographic vote recorder in
1869. The problem he was trying to solve
is that voting in the legislature takes a
long time. So, he thought he could improve
it with automation. A man named Dewitt Roberts
bought the patent for $100 and tried to sell
it to Washington, but they were not in favor
of making the voting process any more efficient
than it was, because they wanted to make time
for wheeling and dealing and filibustering. So,
young Edison's vote recorder was sent to the
political graveyard. 
Nikola tesla, born 1856 studied engineering
and physics, but dropped out like me, and
died penniless in obscurity in New York. He
was Rediscovered in the 90s. 
He worked from various labs around New York
through the 1890s through the 1900s, and this
is a photograph of a lab he built in Colorado
Springs in 1899 to study the conductive Power
of low‑pressure air. He was trying to invent
a way to send power through the air. Tesla
applied for his first patent in 1884, immediately
after leaving Edison's company and founding
the tesla light manufacturing company. We're
gonna talk a little bit about the war of the
currents, but to get there, we need to understand
something called a generator. 
In 1831, Michael Faraday discovered the operating
principle of electromagnetic generators. Faraday's
law is that force is generated in an electric
conductor ‑‑ a wire moving through a
magnetic field. He build the first electromagnetic
generator using a copper disk rotating through
the poles of a magnet. And it produced a
small DC voltage. That same year, a man named ‑‑
generating more current, but his generator
was AC, and that was considered a major flaw
at the time. 
William Cook and Charles Wheatstone were a
pair of inventories who made their name with
improvements to the telegraph. They made
an improvement in generators by replacing
a permanent magnet with a battery powered
electromagnet. By the 1860s, this kind of
generator was common. 
The first practical generator capable of powering
electric devices was called the Gramme machine. It
with us created by ZT Gramme, a Belgium inventor,
and he started selling them in 1870s. A demonstration
took place at the 1878 Paris expedition. The
world was waking up to the potential of electric
power. 
Which brings us to the war of the currents. Edison
stubbornly held on to the idea that direct
current was the best way to deliver electrical
power to the world, while tesla believed in
the superiority of alternating current and
the war raged for nearly 20 years. 
The first large‑scale power station in America
was Edison's pearl street station in New York
City, which began operating in 1882. The
station had six 200 horsepower dynamos powered
by steam engines. It was located in a commercial
district and supplied electricity to customers,
powering lamps. But Edison's generators were
inefficient and couldn't deliver power over
distances of more than a few city blocks. In
order to light New York City with Edison's
generators, there would have to be a power
station every five or six blocks. In 1884,
at the suggestion of a friend, Edison hired
tesla to improve his DC generators and offered
a reward of $50,000, which in modern terms,
is about $1.2 million. Even though tesla
thought that DC generators had no future,
he needed the work. And he did, in fact,
improve DC generators significantly. When
he went to claim his reward, Edison laughed
at him and said my friend, you don't understand
American humor. I never intended to give
you $50,000 for this work. 
Tesla was devastated, and he had to resort
to digging ditches and doing odd jobs to raise
enough money to start his own company, tesla
electric light manufacturing. 
He tried to come up with a better way of generating
alternate current, and he developed a steam
power generator. Steam was forced through
the bottom of the oscillator and rushed out
through a series of ports which pushed a piston. And
the magnet vibrated, producing an alternating
magnetic field. This induced alternating
current in the wire coils and did away with
the complicated parts of the steam engine
generator, but no one was interested in his
invention. 
But tesla's invention was saved from obscurity
when engineers at Westinghouse electric invited
tesla to participate in the 1893 exhibition
in Chicago where they had space devoted to
electrical exhibits. It was a key event in
the history of AC power, demonstrating to
the American public the viability and safety
of AC. 
By 1902, 61%of generating capacity was AC. AC
was really good at delivering power over long
distances, so it was possible to connect to
different stations and balance the load between
them. The war of the currents was won through
a partnership between tesla and George Westinghouse. Edison,
who finally admitted defeat, shifted his focus
to other inventions. Today the world consumes
an estimated 157.5petawatt‑hours of power,
and electricity is responsible for 10%of the
world's GDP. 
I mentioned at the beginning an elephant. There's
a term in French that I'm not going to attempt
to pronounce, literally translated, it means
the spirit of a staircase. In 1773, the French
philosopher was at a dinner party, and someone
insulted him and it left him speechless and
ruined his whole night. When he finally left
to go home, he was going down the stairs and
he came up with a perfect retort. And he
was so frustrated because he thought if I
thought of this an hour ago, I could have
saved my evening and made a good point and
defended myself. So, Edison had one of these
spirit of the staircase moments, too. He
demonstrated this in a 1903 film called electrocuting
the elephant. He had been experimenting with
electricity as a humane way to put animals
down. It was generally accepted by the animal
rights activists at the time. This was Topsy,
a circus elephant and something of a problem
child. He killed a spectator at the circus,
but he deserved it. He put out a cigar on
her trunk and she attacked him. Topsy had
also attacked several handlers, and the circuit
decided she was too much of a liability and
they decided to put her down. The event was
captured and released by the Edison film company
as a 74‑second silent film in 1903, and
interestingly, this was the first time that
death was captured on film on any kind of
camera. 
Edison's film shows the unitization of Topsy
in an under‑construction fairground in Coney
island. Edison was clear about the fact that
AC current was used to electrocute the elephant. He
could not let it go. The fact is if you have
to murder an elephant publicly to make a point,
you're likely on the wrong side of whatever
it is you're trying to argue. 
Both Edison and tesla are portrayed in history
as lone geniuses turning out invention after
invention, but this wasn't really true. In
fact, the notion of genius is a relatively
new concept that comes from the enlightenment
of the 18th century. In previous centuries,
invention was acknowledged as a collaborative
process that built on historical work of precedent ‑‑
historical precedent by other scientists. But
when the first copyright law was enacted,
it gave credence to inventories being the
owners of the ideas. 
There is a book "shakes peer's ghost writers,"
the cult of genius emerged. There's lots
of evidence that Shakespeare borrowed from
poets and play writes, but he's held up an
as example of natural genius. In his book,
the power of two, Joshua Shenk explores the
rule of partnership and collaboration. Successful
collaboration extends beyond widely acknowledged
duos like the Wright brothers or the Curys. 
In 
some cases these relationships are collaborative
and in others they are adversarial, but they
always have an undeniable interpersonal component. Edison,
as I mentioned, got started making improvements
to telegraphs. He had his invention factory. And
the physicists and machinists and mechanical
engineers who worked at the invention factory
were called muckers. And it was the muckers
who were responsible to generating the hundreds
of patents that are credited to Edison. The
muckers didn't enjoy wide commercial success
for their inventions at first. They quickly
discovered that when they tied an invention
to Edison's name, the audience responded better,
because the audience liked the idea of a lone
genius working and turning out the technological
marvels. Francis Jehl even wrote that Edison
is, in truth, a collective noun. 
Tesla worked solo for a lot of his career,
and he failed to meet with success. He needed
the support and business acumen of men like
Westinghouse. There are other examples of
collaboration throughout history. We have
Allen Turing, but he would not have been successful
if not for the dozens of uncredited women
who worked to decode German encryption. Ada
Lovelace needed her partner. And Steve jobs
relied heavily on his partnership with Steve
Wozniak. The conclusion that Shenk came to
is that working relationships are the fundamental
engine of the creative process. 
What does all of this have to do with software
development? In a paper called human cumulative
culture, at the university of saint Andrews,
they explore the unambiguously cumulative
character of complex human advancement. The
paper describes how the transmission of knowledge
gives more complex than what they could alone. Leading
to a ratcheting effect on technology capabilities. The
authors argue that understanding the progress
of human endeavors is only possible through
looking at social processes. And they describe
something called pro‑social behaviors. There's
a broad range of altruistic and reciprocal
social processes that follow social behavior. They
are defined as voluntary actions intended
to benefit other individuals or society as
a whole, and examples include altruism, obeying
rules, acting on our values, and most importantly,
practicing empathy. 
As developers, we feel good about our code
when it's new. And with the exception of
test‑driven developer enthusiasts, we may
be less enthusiastic about things like writing
tests, writing documentation, writing proof
that our code actually works. And this is
evidenced by the hundreds of thousands of
empty read‑mes on GitHub. 
But if you're part of a project that is innovative
and beneficial to society, that helps you
get through the boring work. Successful software
requires collaboration with many people including
end users. Even in the open‑source world
where we're often motivated by satisfying
a need that we ourselves have, projects don't
often have success without the assistance
of other people collaborating in the code
base, writing documentation, giving talks,
or even writing books. 
I believe that each and every one of us alternates
on a spectrum between the raw creative power
of tesla and the practical and methodical
approach of Edison. So, which one are you? 
A tesla developer prefers to work alone without
interruption. And they are really good at
solving complex problems in many a really
creative way. They may not like writing tests
or documentation, and they work in bursts
of energy followed by long periods of low
productivity. 
The Edison developer, on the other hand, loves
pair programming and may apply architectural
patterns to their work. They write comprehensive
issue descriptions and they produce work at
a steady velocity. 
So when you ask yourself where you fall on
the Edison tesla scale, you may aspire to
be more like one or the other. Or you may
recognize that you move between these extremes
in different situations. And that's actually
the ideal. The best developers I know oscillate
between Tesla and Edison as the situation
demands to solve the problem at hand. 
But if you identify more with Edison or more
with Tesla, there are different strategies
you can employ to emphasize your strengths
and work around your weaknesses. Edison was
a practical man, really good at execution,
but also very resistant to change. If you're
an Edison, make use of your practical tendencies,
learn from your failures, embrace team work,
but don't fight against radical ideas. Work
to make those ideas successful. 
Tesla was one of the world's most creative
problem‑solvers, and he was knocked down
by convention. But he was very naive. If
you're a Tesla, don't let people tell you
that your idea won't work or that it's impractical. Find
a way. Believe in yourself, even when no
one else does. And most importantly, figure
out a way to build partnerships to make your
ideas take shape and change the world. 
We all generally work at companies with established
technology platforms. We have a standard stack
that we work in. But sometimes we're attracted
to new frameworks or new technologies or new
languages. We can bring those into our workplace. How
do we do this in a responsible way? How do
we build our own Invention Factory? There
are three main aspects to innovating responsibly
with technologies in a workplace. You want
to evaluate the need for technology, test
it through experimentation, and follow a decision‑making
matrix to make sure it's adopted. First off,
evaluating the need. 
There are six primary questions that we ask
ourselves. Ask yourself why is this new problem
a priority? What does ‑‑ what's different
about what you're facing now compared to what
you faced when your stack was first chosen? And
tie it to a business need. If you can't tie
it to a business need, you're not likely to
get buy‑in from stakeholders. Be very clear
about why your current approach is not working,
why isn't the stack that you've been using
forever or the language that you've been using
forever unable to solve the problem at hand? 
And be very clear about having exhausted the
possibilities of working with your existing
technology. And think about what has changed. 
Think about what kind of effort is needed
to solve the new problem. There are two categories
of effort that you can divide into. One effort
is a strengthening effort, which means investing
time and energy to make an older technology
do something new through re‑engineering
or process changes. Sometimes the efforts
pay off, but sometimes you end up being like
Edison trying to improve the DC generator. It
can be a lost cause. 
Growth efforts involve using new technologies
to solve a problem. But growth efforts may
fail if clear parameters are not established
up front. You can end up like Tesla making
inventions that were unwanted. 
To help us at Stitch Fix understand when to
bring in new technology, I created the new
technology matrix. Ease of adoption, we'll
start with. And that encompasses a number
of considerations. Does the new technology
fit within our existing processes? Will it
be easy for other developers to learn to use
it effectively? Is there good documentation? Is
there prior art that we can learn from? Are
people averse to the questions on stack overflow? Is
it more flexible than current stools? Does
it have a strong security story? Have we
considered the overall cost of adopting the
new technology? 
Usefulness can be determined with more questions. Does
the technology enhance the performance of
our teams? Positively impact stability, performance,
and reliability? Is it well‑maintained? Does
it have an active user base? Does it solve
the problem more effectively than our current
tool set? 
We can use this matrix to guide our decision‑making
process. In the first quadrant, reject, this
is where technologies that are difficult to
adopt and provide a limited utility fall. And
you can reject those outright. Easy to adopt
solutions that maybe are limited in capacity
aren't likely to be adopted, but they can
be really useful to play with. That creates
learning opportunities that can help us gain
a new perspective on a problem that we're
trying to solve. 
Technologies that are useful but difficult
to adopt fall into the wait category. They
may be candidates for future adoption once
the technology matures to the point that tooling
and training exists to make onboarding easier. 
And finally in the explore quadrant, solutions
that are easy to adopt and accommodate a wide
range of use cases. Technologies like this
can move into the next phase, which is experimentation. 
To inform and guide the evolution of our solutions
in a framework of pragmatic innovation and
creativity, we sometimes experiment with new
ways of doing things. And we should do so
responsibly. So, what are the characteristics
of a responsible experiment? First of all,
make sure that you can clearly state what
the problem is. If you can't state what the
problem is in a sentence or two, you probably
don't understand it sufficiently. 
When you're conducting your experiment, you
want to make sure that it has minimal impact
on other systems. For example, if you have
a service oriented architecture, and you want
to experiment, you don't want to have to change
every other service that might be talking
to your service to support protobof. You
want to limit that footprint. That ties into
establishing boundaries. You want to be sure
you're testing exactly what needs to be tested. You
want to establish clear success criteria up
front. It's possible that during the course
of the experiment, you fall in love with this
new technology and you lose sight of the pragmatic
approach that is probably going to be most
successful. 
You want to constrain the time and costs time
box. And make sure that whatever you do can
be rolled back quickly. If you're on a deadline,
that's not the time to experiment. 
The best engineering cultures empower us as
engineers. They give us flexibility in the
way that we go about solving problems. But
sometimes what we want to change has impact
outside of our immediate situation. We have
to be careful and thoughtful about how other
engineers will be affected. And for this,
we can use the responsible, accountable, consulted,
and informed. So, the first thing to do is
identify the scope of the change you're trying
to make. 
If it only affects your team, that's a limited
scope and it's a little bit easier. The person
responsible is you or whoever you're pairing
with. Your manager is accountable, and maybe
that is in collaboration with other senior
engineers. You want to consult other members
of your team. And it might make sense to
inform other engineers on other teams about
what you're doing. They may have a similar
problem and may be very interested to see
what you learn from your experiment. 
If you're making a larger change that will
affect your entire engineering organization,
there's an entire set of decision‑makers. The
people responsible is you and a small team
of engineers that you're working from, preferably
taken from different teams across your organization. Those
teams have managers and senior engineers who
are accountable. And you want to make sure
that you consult with senior engineers across
the org and also think about the impact of
your change on ops and security. 
And you want to make sure that you're informing
the broader engineering organization about
everything that you're doing, because it's
going to impact them. 
One thing that I struggle with personally
is I feel a need to drive the consensus. I
want everyone to agree that what I'm proposing
is the best possible solution to a problem. But
I'm often wrong. So, I want to get feedback
from other people to validate my experiments,
to validate my instinct about how to solve
the problem. And that sometimes can lead
to a problem where if I don't have full consensus,
if everybody isn't fully on board, I might
think that my idea isn't a good one. But
as engineers, we are empowered with a certain
level of decision‑making. Don't be afraid
to make decisions, even if everyone doesn't
agree. 
Final thoughts. We can't just be an Edison
or just be a Tesla if we want to be successful. We
have to find a balance. If we stubbornly
hold on to our own ideas and ignore evidence
to the contrary, we might find ourselves left
behind like Edison during the current wars. But
if we don't partner with people who complement
our ingenuity, we might end up spending our
lives and work hours building things that
nobody really wants. Tesla solved impossible
problems and Edisons make solutions practical. And
the best developers oscillate between these
two extremes. If you're wondering if I'm
more of a Tesla or Edison, that's on my left
shoulder. Nikola Tesla with devil horns and
on the right hand side, Ada Lovelace. 
This was condensed from a blog post that I
wrote, and you can find it on my blog. I
want to thank you for being my audience today. And
point out that I have a ton of stickers up
here, so please come up and grab one. If
you have questions for me, come up and ask
them. You can find me on Twitter or on my
website [ listed on slide ]. 
If you're interested in ethical open source,
check out ethicalsource.dev. I'm also setting
up a birds of a feather to talk about ethics
brought to the open world. Thank you. 
[ Applause ]
