Post #60

How to Scratch an Itch

(in 200 repos or less)

Are you a "creative person"? Why is it that most of us would probably hesitate to answer "yes" to that question?

Stereotypes that paint creativity as a mysterious force for good in the world have incidentally discouraged many of us from practicing creativity in our own lives.

This talk presents a strange theory: what if creativity is more like a chronic illness, one fueled by toxic emotions and character flaws? If nothing else, that would certainly lower the barrier to entry.

Using my own career as a case study, this talk is reflection on how my own shortcomings have served as my inspiration and how creative work has helped me mitigate my personal failings while learning to accept myself.

Or, if you'd rather, this is a talk about 9 whacky side projects involving mustaches and home security systems.

The video above was recorded at SCNA on October 21, 2016, at USC Viterbi School of Engineering.


Here's a transcript of the remarks, generated from the subtitles by our gem supertitle:

[00:00] This talk is titled how to scratch an itch in 200 repos
[00:03] or less. @searls is my real name
[00:06] My parents were quite prescient and on-brand back when
[00:09] they named me. This is what my face looked
[00:12] like in 2011 and thanks to personal
[00:15] branding, I'm now stuck with this face forever because you might see it
[00:18] from Twitter or Github as my avatar
[00:21] Just like Todd mentioned, I co-founded an agency with him
[00:22] Just like Todd mentioned, I co-founded an agency with him 5 years ago called
[00:25] Test Double. Our mission in life is to improve
[00:28] a lot of the stuff about software that sucks, and one of the things that sucks a lot
[00:31] is that most engineering teams operate at capacity
[00:34] and they don't have enough slack in the system to improve
[00:37] things like testing, and quality, and craft. So we come in
[00:40] to pair with those teams to add enough capacity so that
[00:43] we can all work together to make stuff better. It might sound
[00:46] familiar as a business model, it's kind of like consulting except good
[00:49] So if your team could benefit from that sort of
[00:52] thing, I hope you'll chat with me or Todd tonight or tomorrow
[00:55] So, yeah, how to scratch an itch You might be able to
[00:58] infer from that title that this is a talk about creativity
[01:01] Everyone loves creativity, "yay! creativity!" That's a good
[01:04] thing, right, ok, cool, let's talk about creativity. …So what is
[01:07] creativity, exactly? It's one of those axiomatic
[01:10] concepts that we generally don't interrogate
[01:13] or introspect much on, and I forced myself to
[01:16] think about this when I was designing this talk and
[01:19] The first thing that came to mind is that creativity is a lot like passion
[01:22] Passion's hot right now. We got all these passion projects. Look at all
[01:25] these passionate logos for passion projects that people have
[01:28] made. But personally I don't get on board with a movement
[01:31] until I can find a way to engage with a brand
[01:34] and its hashtag. So the American Express passion project.
[01:37] And it actually serves as a really good example of why
[01:40] passion doesn't equal creativity, because it fizzles out
[01:43] kind of like domain name registrations
[01:46] So the Amex passion project is just gone
[01:49] now. So, no, passion isn't quite
[01:52] what creativity is. You might say "is creativity art?"
[01:55] You certainly—coding feels creative, right?
[01:58] We know it's a creative enterprise, but not all of our
[02:01] code is art, when I put it up on a screen
[02:04] You know, it's mostly functional most of the time. It certainly can
[02:07] be art, but it doesn't seem like the best metaphor
[02:10] or abstraction. You could say, is creativity vision
[02:13] and foresight? If we had a crystal ball where you could see
[02:16] where the cloud is and where it's going to go and there might be an
[02:19] aspect of that, but that's not in itself building anything
[02:22] it's just prognostication, so vision's not enough
[02:25] And I thought about this at length to try to
[02:28] figure out, "am I creative? are you creative?"
[02:31] And if I was forced to think in those terms
[02:34] and that popular framing about creativity like filling out a survey
[02:37] Are you incredibly passionate? Do you create beautiful things?
[02:40] Can you see into the future? Of course most of us would say no
[02:43] to all three of those things, so certainly we're not
[02:46] creative. That's a really high bar to clear. Creative people
[02:49] are these magical unicorns and that's not me, that's not us.
[02:52] That's kind of disappointing. We can
[02:55] usually at least relate to the idea of a creative spark, right, like we
[02:58] have an idea in the back of our heads we're walking down the street and an
[03:01] idea occurs and then of course what happens next is we just
[03:04] effortlessly create amazing things based on that idea
[03:07] Unfortunately, that doesn't comport with my experience. Actually
[03:10] I have a—creative ideas, they stress me
[03:13] out. That spark, tells me— I'm already really busy
[03:16] how am I going to find the time or the capability to go
[03:19] and accomplish that thing
[03:22] these ideas they sort of scare me, because I don't think I'm—gonna
[03:25] have fear, uncertainty, and doubt I'm not going to be able to do them. Where does that spark
[03:28] come from? Is there some big dragon breathing fire
[03:31] behind me? Should I be running from my ideas or I'm going to burn
[03:34] up? I got this fraught relationship with these
[03:37] creative ideas in my head, and so I was thinking about my own
[03:40] weird relationship with creativity and I realized
[03:43] the best metaphor for me is that creativity is a chronic
[03:46] illness. Which I know sounds horrifying
[03:49] But here me out. Because what happens is I go two weeks
[03:52] three weeks, four weeks, and eventually something makes
[03:55] me angry, something wells up inside of me
[03:58] and then I have an episode of creativity
[04:01] and I emit a blog post or a library or a
[04:04] framework. And
[04:07] the way I think of it is it's like kidney stones
[04:10] I'm passing npm modules
[04:13] And then I feel a sense of relief
[04:16] after. So I've seen this pattern
[04:19] in my life, right? I've got all of these negative emotions, this
[04:22] toxicity. I'm a really sad, broken individual and
[04:25] over the course of my professional life I keep finding these
[04:28] ways to shape that into positive outcomes
[04:31] and I don't know how that happens, and so this talk is an exploration
[04:34] into trying to figure that out, and maybe there's something that you can
[04:37] relate to. Because what I've found is that that reframing
[04:40] of what creativity is certainly lowers the
[04:43] bar, it's like "are you a broken individual? Good! then you
[04:46] can be creative, too!" So let's
[04:49] wind all the way back to the beginning of my career
[04:52] I was working at a big accounting firm, I wasn't very
[04:55] competent. I didn't have very much autonomy
[04:58] at my job, and I would get ideas like anyone gets ideas
[05:01] But I wouldn't be able to act on those ideas, so they actually just
[05:04] bummed me out. In fact, eventually the ideas would fade away
[05:07] and that would make me feel relieved, because now they weren't stressing me
[05:10] out. And it took me years to realize that what I was missing was
[05:13] I didn't have an outlet to practice those creative ideas
[05:16] To develop a feedback loop, just like we do with coding stuff
[05:19] And I learned once I started trying that production
[05:22] wasn't necessarily the best creative outlet, either
[05:25] Us as developers working at machines
[05:28] At work, we might think that this is creativity, building
[05:31] ideas, but typically they're other people's ideas
[05:34] we're building reports, or mailers, or shopping carts
[05:37] and we feel creative, because we did create it
[05:40] but because it wasn't our own, it doesn't really scratch the same itch, I don't think
[05:43] Separately, we usually
[05:46] work on teams and an important part of building software on teams
[05:49] (there's me and that's my team)
[05:52] An important part about building software on teams is that we're building everything
[05:55] to be very consistent and orderly so that any of us can be productive
[05:58] in that environment, but creativity is sporadic
[06:01] and messy. I might have an idea like "Hey I could pull this
[06:04] one package out and that would eliminate the need for these two packages
[06:07] Because I could put a factory in front of them and look at this, and this is
[06:10] really cool and I could be really proud of the creative thing that I just did
[06:13] But from everyone else's perspective, they see the
[06:16] system is becoming less stable and less workable. And
[06:19] they're worried, and I get mad because they don't appreciate this cool
[06:22] creative thing that I just did and then they
[06:25] get angry because I keep going off the reservation and disrupting the
[06:28] orderliness of the system. A third thing that
[06:31] we see happen a lot at our company Test Double is, developers
[06:34] who are passionate about what they do, they put a lot of effort
[06:37] they tie up their ego in the stuff that \they build and then they hand it off
[06:40] they get excited and then it just sits in QA
[06:43] or people comment on their pull requests and
[06:46] and things take forever and they don't see
[06:49] it in front of users and then eventually they just get angry
[06:52] because what they did was they ceded control
[06:55] of their happiness and their emotional state to somebody else
[06:58] and at work that's just not appropriate, because we're not building
[07:01] this stuff for our own good
[07:04] we need another place to practice
[07:07] creativity. So you have to create your own space where that's
[07:10] safe. And one morning, I was
[07:13] taking a shower. Ideas come to me in the shower, I don't know when they come to you
[07:16] but they always come to me in the shower, and I had an idea and
[07:19] it made me angry, of course, because ideas are bad like I explained earlier
[07:22] and I got so mad at this idea that
[07:25] I went and sat at my computer and I hacked at it until I could build a thing
[07:28] I felt that relief again, but this relief was
[07:31] different. This was like the first green bar
[07:34] in the test. This was like "OK, cool, I understand this now"
[07:37] And I went from a disgruntled employee
[07:40] to a merely gruntled employee because I was starting to learn
[07:43] how to be productive with creativity
[07:46] And from then on when I got a creative idea
[07:49] in the shower, I'd roll my eyes because now I've gotta make time
[07:52] for this—maybe there goes my Saturday or my evening or something
[07:55] But at least I had a reasoned way to work through it
[07:58] And so ever since I started programming
[08:01] professionally, I've always had a main project that occupies most of my time
[08:04] and most of my focus, but a little project to the side. Whenever I get
[08:07] frustrated or I want to play with something or I'm learning something
[08:10] I can pull on that thread as well, and I always balance both
[08:13] of these things. Of course this comes with risks
[08:16] I'm very often burning the candle at both ends
[08:19] If I work all weekend because I'm so excited about my side project
[08:22] then I come to work on Monday morning, the last thing I want to do is program
[08:25] That can be problematic, and
[08:28] in the last several years in particular I've spent so
[08:31] much time on the road, doing all this open source stuff on top of
[08:34] my normal job, that I'm often asking "Why do I do
[08:37] this?" And that's where the introspection
[08:40] of this talk is—part of why I did this
[08:43] talk is that I don't think that I'm that special. I think all of us could be this
[08:46] creative and it would save me a lot of time if you all would
[08:49] do the talks instead of me
[08:52] So when I sat and I
[08:55] thought about why is it that I do this
[08:58] I'm almost ashamed to admit those sources
[09:01] because they're from my childhood, so I've got a few little childhood anecdotes
[09:04] The first one's about golf. My dad was actually an amateur
[09:07] golfer. One of my first memories is watching my
[09:10] dad play golf on TV at an amateur PGA event
[09:13] and so in southeastern Michigan, every well-to-do businessperson
[09:16] wanted my dad in their foursome, so I spent as a kid
[09:19] a ton of time at country clubs with kids that were way richer and
[09:22] more world-weary and experienced and knowledgeable
[09:25] and well-to-do than me
[09:28] that was an important part of my upbringing, because it taught me the
[09:31] ever-important skill of feeling inadequate
[09:37] Talk about my church a little bit I went to a church that didn't
[09:40] necessarily work in its community and serve the poor or anything
[09:43] like that. I went to an upper crust white evangelical
[09:46] Presbyterian church where I spent years 5
[09:49] through 10 of my life learning how to understand very
[09:52] intangible concepts and then feel extremely
[09:55] strongly about them and argue with passionate rhetoric
[09:58] and that was also a really important skill, because I learned
[10:01] righteous indignation. Fun fact,
[10:04] about me: nobody's ever asked for my opinion, because
[10:07] no one's ever needed to
[10:10] I can't help but form really strong opinions
[10:13] the minute I see something, and that's less fun than
[10:16] it sounds. Third thing about my life
[10:19] I'm one of those people, like at lunch we were talking about college
[10:22] programs. I got a computer science degree
[10:25] in college, and I wasn't very good at it
[10:28] My professors pulled me aside senior year when I was trying to find a job
[10:31] and some of them confided in me that maybe I should find a more
[10:34] hybrid role where I'm also talking to people more and maybe
[10:37] not trusted with a computer
[10:40] and it was through there that I learned this
[10:43] real deep-grained incompetence and
[10:46] what's funny about all those three things is that clearly they're negative but they have
[10:49] flip sides that I think are really valuable to exploit
[10:52] The inadequacy leads to me having a bunch of
[10:55] people that I aspire to in my life—that I look up to
[10:58] The indignation means that I always have something to say
[11:01] or a perspective (whether it's valid or not) and
[11:04] the incompetence means I don't view myself as a rockstar, I always
[11:07] feel like I've got a lot to learn and a lot to improve
[11:10] That translates to a means, a motive, and an opportunity
[11:13] to exploit creative ideas
[11:16] Also, worth mentioning here is this
[11:19] these are all markers of tremendous amounts of privilege in my upbringing
[11:22] most kids don't have the amount of spare time that I did to
[11:25] nurse my existential grief
[11:28] to the extent that I have, but through doing
[11:31] a lot of creative stuff, I've learned how awesome and how enriching
[11:34] and rewarding it can be. And getting back to Todd & I
[11:37] forming Test Double, a big reason we did that is because we want everyone to be
[11:40] able to have that experience by moving at a sustainable pace
[11:43] by being able to build creative stuff in a way that's congruent
[11:46] with our normal work life, so that you don't have to be
[11:49] working on nights & weekends or particularly
[11:52] privileged to be able to enjoy the fruits of creativity
[11:55] If you want to talk to us about that
[11:58] you can e-mail Our first
[12:01] step in our recruiting process is really low-pressure, it's not some sort of
[12:04] technical interview at a white board, it's literally a conversation about
[12:07] how we work and how you work and whether you'd like to try how
[12:10] we work. Just to learn about us and learn a little bit about
[12:13] what we've learned about productive, autonomous software development
[12:16] So anyway, all these things: really negative
[12:19] How does that lead to creative ideas? Well, I
[12:22] kind of feel like it's a game of MadLibs™ in my head. This is my user
[12:25] story for creativity. I feel
[12:28] righteous indignation, but I don't know what I'm doing
[12:31] Maybe, if I build something I will feel
[12:34] less inadequate. And I have 9
[12:37] little anecdotes. 9 little stories of side projects over my career
[12:40] that have helped me to mitigate some of that toxicity
[12:43] in my heart. And I'm going to start by talking about
[12:46] incompetence. Because like I mentioned, I wasn't very good in college and
[12:49] I was really worried: why would anyone ever pay me to write software?
[12:52] when I can barely learn how to do it? And my library
[12:55] at the time where I worked said "Hey, we need a new citation editor"
[12:58] on the web. And I thought, you know, I'm
[13:01] up to this challenge. I feel like I don't need this
[13:04] Computer Science hifalutin stuff, but I also don't know how to
[13:07] build apps, either, so maybe if I build it I'll at least
[13:10] find a way to survive this profession, and it was a pretty low
[13:13] pressure gig, because it was $10 an hour and I could
[13:16] spend all summer on it. So I built this thing called
[13:19] KnightCite, a little citation editor on the web. It was free
[13:22] and I was really proud, I did it. I accomplished a lot
[13:25] of my goals. It supports all the major styleguides, dozens
[13:28] of sources (the only one that did that). Has an account
[13:31] system where you can login, create bibliographies, and export them
[13:34] It's got millions of users, and still to this day it's by
[13:37] far the most-used piece of software that I've ever written, and
[13:40] I made it all up as I went. I didn't read in a book how to do this
[13:43] I just had to figure out how to do a reset password
[13:46] thing, and I just figured it all out as I went. This, of course
[13:49] had some very minor downsides. Like, for instance, it's totally
[13:52] insecure.
[13:55] It's 100% manual testing
[13:58] It produces gigabytes of daily server warnings
[14:01] That those poor admins who still
[14:04] are, over a decade later, still dealing with
[14:07] and it's one 16,000 line-long PHP file
[14:10] of just if's and else's and string concatenation
[14:13] But
[14:16] what had happened to me in my classroom education was it had
[14:19] drilled into me this fear that I don't get what's going on
[14:22] and paralyzed me from ever practicing any of that creative
[14:25] reflex and that creative muscle. So recognizing
[14:28] that I needed a safe space where it was OK to make a mess
[14:31] and to do that in concert with learning proper
[14:34] computer science-y stuff was crucial
[14:37] to me even being in this profession
[14:40] much less on a stage, talking to you all about it. So that
[14:43] certainly lessened my sense of incompetence. The
[14:46] other thing at the time, the web was just a really fancy hypercard
[14:49] implementation. I didn't feel like a real developer; my friends all worked
[14:52] on airplane realtime controls and operating systems
[14:55] so the web versus being
[14:58] closer to the metal. Like, Uncle Bob told me—is Uncle Bob still
[15:01] here today, that you're not a real programmer
[15:04] unless you programmed assembly—well, I hadn't really programmed a lot of assembly
[15:07] So I didn't feel like a real programmer. And so I
[15:10] tried to go native at multiple points in my career
[15:13] Maybe on a Saturday, I'd open up Xcode and say, "I'm gonna build an OS X
[15:16] app", and i'd look at the documentation and it would confuse me and I'd feel
[15:19] stupid, and then I'd wait a weekend and I'd go, and I'd
[15:22] find a different part of the documentation and it'd depress me, and I'd feel
[15:25] stupid. And then the week after that I would open up Xcode and I'd
[15:28] look at a different part—and this outside in, like, "maybe if I just read it all
[15:31] and then I'll know how to make native apps." Of course, that didn't go well
[15:34] and time kept passing and I just concluded I was
[15:37] probably too dumb to make native apps, maybe I just had
[15:40] stay on the web. But then one day, a momentous day that a lot
[15:43] of us remember: the iPhone was announced. And I thought to myself
[15:46] as soon as this thing has an SDK, I'm gonna
[15:49] make an app. I really want to build something for
[15:52] the iPhone. The only problem was I had no idea what that would be. So I
[15:55] got the original iPhone and it changed
[15:58] my life, right? It was beautiful, obviously. It's innovative, there's nothing like it.
[16:01] I knew from the first day I had it that it was
[16:04] life-altering, because I took my wife to a restaurant and I ignored her the
[16:07] whole time. And I was, like, "this is
[16:10] the future!" Boy was I right
[16:13] So, the thing about that was I
[16:16] was staring so long, because Edge was so slow
[16:19] and I had this one gaming forum I liked to visit, and
[16:22] at first it was not very readable, but it took like
[16:25] 3 minutes to load a single page
[16:28] of what were often 50, 60 page-long threads
[16:31] so that was unacceptable. But there  was no such thing as
[16:34] the mobile web at the time. There's certainly no responsive
[16:37] design, and so I thought to myself, maybe I could build an app that was like a
[16:40] client to this website. Because I felt like the mobile web was a joke
[16:43] but I kept failing to learn Cocoa, and so maybe
[16:46] if I built something, I'd at least learn how to learn a
[16:49] really unfamiliar thing and tackle a new platform
[16:52] and I did it. So I started by building a little system that just
[16:55] go and fetch the HTML, and then I figured out how to load a library
[16:58] like libxml2 and parse all that into an object
[17:01] model, and then, you know, I'd find all the media in those
[17:04] objects and go and fetch them from the Internet, so I could build a
[17:07] UI and have a custom user interface in an iPhone app
[17:10] and you know what, it was way faster, and it was legible, and it was
[17:13] full-featured, you could log in and edit posts and stuff, it was really neat
[17:16] it was also the very first time I ever contributed to open source in a real
[17:19] way, and it was so
[17:22] cool, because every time that the Facebook app got launched, a
[17:25] little bit of my code ran, and when I realized the impact that I
[17:28] could have that way, I got addicted to sharing my stuff in
[17:31] open source. It was also my very first user group talk, and so
[17:34] the only reason I'm here today is because this one app happened to go well
[17:37] of course, it was rejected by Apple
[17:40] because, sometimes people swear on the Internet. And swearing
[17:43] was against the guidelines, which were very prudish at the time
[17:46] and so I threw it in the trash. But I didn't care
[17:49] I was happy as a clam, because mission accomplished: I'd learned how to learn a thing
[17:52] That was the real purpose for that exercise, and
[17:55] what I learned there was that learning something simple is pretty easy so
[17:58] long as you can fit it inside a day or whatever the bounds
[18:01] of that passion is, because it's enough to get
[18:04] through a weekend, but when the going gets tough, your motivation
[18:07] fizzles. If you try to learn something bigger, that's going to take several
[18:10] days, weeks, months, then you really need a purpose
[18:13] that's going to push you through those barriers as time
[18:16] goes on, or else you'll get distracted, you'll end up with just
[18:19] a graveyard of half-finished projects everywhere
[18:22] So what I try to do is find the smallest thing I can possibly
[18:25] caremad about. Really, like, "I need this project to exist
[18:28] and I'm going to just push and drag it over the finish line"
[18:31] And that was a lot of valuable lessons, and certainly
[18:34] made me feel less incompetent as a developer, because I got to go native
[18:37] For a long time, I did Java development
[18:40] and Java's a cool language, but I felt like it was
[18:43] a little uncool. It was
[18:46] certainly not getting a lot of buzz in the mid-aughts
[18:49] certainly not like Ruby was. A lot of my friends, they
[18:52] seemed really cool, they all worked on Ruby at work
[18:55] and the best way I can compare the two languages is via
[18:58] Super Mario Kart. You might think of Java
[19:01] as being like one of the early courses, just like a really
[19:04] wide lane and you can't really mess up that badly
[19:07] If you go off the course, you can just drive back
[19:10] on and we get that with Java, because it's not a
[19:13] very expressive language. The compiler does a lot for you
[19:16] the tools do a lot for you. Ruby is more like Rainbow Road
[19:19] where it's narrower and faster
[19:22] and if you fall off, Lakitu has to pick you up
[19:25] and you lose like 20 seconds, and that's reflective of
[19:28] dynamic programming and metaprogramming and how
[19:31] you don't have the same amazing tooling. And so programming
[19:34] even at this point in my career, I felt like I wasn't a very good programmer
[19:37] much less dynamic programming. And at the time
[19:40] in Ruby, meta-programming— changing at runtime the
[19:43] object model, the classes and method definitions
[19:46] I didn't even understand how that could possibly work. So I joined
[19:49] my first Ruby team completely terrified and surrounded by people who
[19:52] were way cooler than me and I thought "I have nothing to contribute
[19:55] here" until I looked at their test suite
[19:58] Because in Java, we had a pretty formal sense of what
[20:01] good tests looked like, and I knew that Rubyists wrote a lot of tests
[20:04] But it turns out that they all sucked, and so when I looked
[20:07] at those tests, I thought maybe this is a way for me to sneak in
[20:10] the back door and actually be relevant. I looked at a test like this
[20:13] This is creating a fake dog object and it's saying
[20:16] the dog should be called with the method wag and the argument tail
[20:19] and then you pass the dog to your subject under test
[20:22] and this just looked way wrong to me. First, there's no type awareness
[20:25] so you don't know that dog actually responds to wag. Then
[20:28] these things are out of order. It's like given-then-when and that feels
[20:31] awkward. And the API for making that
[20:34] test double and stubbing it was kinda confiusing, so
[20:37] I got caremad enough to say maybe
[20:40] I hate these mock objects, but if I
[20:43] can't metaprogram Ruby, I can't build something to replace them
[20:46] so maybe if I build it, I'll at least find a way to fit in
[20:49] as a Rubyist. And my whole goal here was just to
[20:52] cargo-cult my favorite test double library in Java and implement it
[20:55] in Ruby. And it turns out that that didn't work so well
[20:58] I learnedl some
[21:01] humility in the process that I had to go and actually talk to humans about
[21:04] the idioms and conventions in Ruby. I had to really bone up and learn
[21:07] how the Ruby object model worked. And then I had to put the time
[21:10] in. I took two weeks off for Christmas that year and I spent the whole time
[21:13] squirreled away just working on this, which my family
[21:16] didn't appreciate. And so what came
[21:19] out is this little fun gem called gimme. You pass it a type
[21:22] it's got the type awareness built-in. Here I pass it [to] the subject
[21:25] It's in the correct order. Here you can say you verify that the
[21:28] dog's called with wag and tail in a way that looks like a method
[21:31] invocation. And so I was really proud because this had the type awareness I was looking
[21:34] for. It preserves the test order. Has a clever, terse Ruby
[21:37] like API. Of course, no one adopted it, because nobody
[21:40] knew who I was, but I shopped it around at a couple conferences and got people
[21:43] like Jim Weirich to incorporate this style into Flexmock
[21:46] and now RSpec—which was the first example—
[21:49] has incorporated the same style. So I was able to kind-of move
[21:52] the needle a little bit. But what that project taught me
[21:55] was it's important to get out of the line of fire, right?
[21:58] I don't want to try to
[22:01] learn how to metaprogram in the most important feature, because
[22:04] then I'm on the spot, and everyone's going to call me out as an imposter
[22:07] Meanwhile, I learned that working code
[22:10] can sell an idea way better than just nitpicking stuff
[22:13] if I just come to that team and say  "hey your tests suck, because I don't like this
[22:16] and this and this", they'd say "what, so?". But if you throw a keyboard at
[22:19] the problem and actually build something—a proof of concept—you can reframe the
[22:22] discussion around the concrete stuff, and that was how I was able to sell
[22:25] that idea. Additionally, if what you're selling is ideas
[22:28] the best part is they require no maintenance. Nobody is going to open up a GitHub
[22:31] issue at 3am on a Saturday because your idea stopped
[22:34] working and so it's true that thoughtleaders
[22:37] have more fun. So that made me certainly
[22:40] feel less incompetent. A little bit
[22:43] about my own sense of inadequacy and how I was able to deal with that
[22:46] I practice a thing called Midwestern programming
[22:49] So if this is the continental
[22:52] US, my general
[22:55] stereotyped perception is that people on the east coast, the developers
[22:58] there they have serious jobs. They work at universities doing
[23:01] high finance, it's very obviously valuable
[23:04] work because it creates a lot of money. And on the west coast, your apps
[23:07] obviously don't make any money, but they get a lot of attention and
[23:10] all the really, really
[23:13] popular snacklechat, and other stuff, everyone is sort of…
[23:16] but in the midwest, we do a lot of charts
[23:19] We have all these blue
[23:22] chip companies that have backend office apps that they need
[23:25] built that might only have three users, that might
[23:28] not be that exciting. So frankly, I'm just not
[23:31] great at cocktail parties, when I explain, "Oh, well we're building
[23:34] this system that participates in demand-response energy
[23:37] markets in various parts of the country", people… their eyes glaze
[23:40] over and I heard a certain amount of rockstar envy. I just wanted to build a cool
[23:43] thing that I could say in a sentence, people would know what I did
[23:46] so I felt like my work wasn't exciting, but I only really knew how to build
[23:49] enterprise stuff, so maybe if I built something that was just designed to
[23:52] go viral, I'd feel more appreciated
[23:55] There was a service called at the time. My friend Aidan
[23:58] wrote, and what you do is pass an image and then it would
[24:01] use API and put mustaches on the faces
[24:04] and I thought "that was cool, but let's go bigger". Like, what could I
[24:07] build that leveraged this, so I made a Chrome extension called Must
[24:10] Stache. And my friend Cory and I wrote it
[24:13] and so basically we would just go to the mustachify service, replace
[24:16] all the images on every page in your browser with a mustachified one
[24:19] and we though this was really cool, we did it in like 3 hours
[24:22] posted to a forum at night, we went to bed. And then the next day we had like
[24:25] 3000 installs of Pro users so they were visiting 40
[24:28] pages an hour, or 42 images per tab and
[24:31] we did the back-of-the-napkin math to realize it was like 5 million requests per hour
[24:34] and we learned a valuable lesson
[24:37] on that first day. It's actually a popular meme right now called
[24:40] serverless architecture, because we just destroyed
[24:43] Aidan's poor dyno. So we had to go back to the drawing board
[24:46] and what we did was we rebuilt it but this time talking directly to the
[24:49] API which did the facial recognition and got you JSON
[24:52] back. And then with that JSON we'd take our own image and
[24:55] then just rotate, transpose, and put it over the images ourselves
[24:58] And that was really fun. That was a fun weekend hack
[25:01] But I didn't get a ton of attention. In fact time passed
[25:04] I forgot all about this thing until I saw in the news that
[25:07] was getting acquired for $80 Million by facebook
[25:10] that made me—that was surprising. So I went googling
[25:13] around my Must Stache thing and saw it had been covered in Tested
[25:16] it'd been covered in PC World in print. It
[25:19] was on the Verge. You know, the Glamour magazine wrote an article
[25:22] about this Chrome extension. And no one ever thought to contact me
[25:25] But I felt pretty
[25:28] proud that I'd had this impact. And pretty
[25:31] annoyed too when I thought about it. I looked at's
[25:34] developer forums and almost all the posts were just people using my
[25:37] stupid Must Stache thing, and the developers at were
[25:40] giving them active tech support. And I thought "but this is violating
[25:43] your terms of—ohhhhh, it's so that you hockey stick and can
[25:46] show off a ton of usage to Facebook, and I bet you a big
[25:49] part of that $80M valuation had something to do with
[25:52] my thing. Where's my cut? Well, my cut
[25:55] came in the form of shutting down and then me getting a bunch of
[25:58] e-mail because all of a sudden, nobody's browser worked
[26:01] Because all of the images would just 404
[26:04] So that was cool. I built a popular
[26:07] thing, yay, but I didn't get to
[26:10] enjoy any of that popularity at all, and I may have
[26:13] made somebody else millions of dollars [citation
[26:16] needed]. But it feels
[26:19] that way and I made lots of users angry
[26:22] the only time they ever learned about me was after their stuff stopped
[26:25] working. And I was left with no recourse
[26:28] I didn't have time to build a new, I just had to kind of
[26:31] shut down the extension. So I learned in the process
[26:34] serverless isn't. Obviously, if you depend on someone else's server
[26:37] they can always pull the rug out from you
[26:40] That was a valuable lesson. Also, chasing
[26:43] popularity without an underlying purpose or value statement is
[26:46] toxic. Because, when I did run into a problem, I didn't have
[26:49] the time—there was no economic reason or even moral reason
[26:52] for me to invest the time to fix it. I was just left, you know,
[26:55] with people angry at me. So that sucked.
[26:58] But! It did get covered, apparently,
[27:01] in the last season of HBO's Silicon Valley where
[27:04] they made an AR version of the plugin, so
[27:07] that made me feel pretty cool, I guess.
[27:10] Another way that I felt inadequate as a developer is that one time I was on this
[27:13] legacy rescue project. A big waterfall project. If you don't know these
[27:16] terms, by the way, legacy when we use that in software terms
[27:19] it means that your kids will inherit it
[27:22] and rescue means that you want to be rescued
[27:25] So I was on this project for months
[27:28] I could barely—my computer was just a memory
[27:31] at this point, because I hadn't programmed in so long, I'd forgotten how to program
[27:34] I felt like, "could I even program anything in 2 months anymore?"
[27:37] I was really feeling kind of despondent and out of touch with myself as a
[27:40] craftsperson. And at the time the
[27:43] to-do apps were undergoing this renaissance, because it was still
[27:46] early in the App Store and there was all these new to-do apps and I didn't really like any
[27:49] of them. I kept falling back on this plaintext thing that I did where
[27:52] I'd define a project with a colon, and I'd dasherize tasks
[27:55] and I'd indicate something's done with a slash or blocked
[27:58] with a pound sign, or I'd date it with braces and I
[28:01] would just do this instead of using an app, but of course that was inconvenient
[28:04] So I was thinking at the time, I feel like I hate all these
[28:07] to-do apps, but I've also forgotten how to code so I can't
[28:10] built my own. But maybe if I were to try I'd at least be able to restore my
[28:13] dignity as a developer. And what I had to do there was I could give myself
[28:16] the constraints needed and so I gave myself a little quest
[28:19] I said "I want to build a to-do app that's so great
[28:22] that I will use this at the exclusion of all the others…
[28:25] and I only want to give myself 24 hours."
[28:28] Can I still hack it? Under pressure.
[28:31] So I built this app called doing-it.
[28:34] So in doing-it, you define a project. And I started by just saying
[28:37] throw all the content in a div, [make it] contenteditable
[28:40] dump it into localStorage, read it from localStorage
[28:43] and then use the tool to track the rest of the work in the tool
[28:46] So I was using doing-it to build doing-it from like minute
[28:49] 40. So I did it, I built the thing. It's still up at
[28:52] if you want to check it out you can
[28:55] make a project, it'll autoformat based on the
[28:58] the lead character here, so this is me making a couple different things
[29:01] I can mark them done or overdue or high priority
[29:04] and mark'em all done. And that was a lot of fun, you know I finished it within the
[29:07] 1 day. Gave me a renewed sense of confidence as a developer
[29:10] It still works, thanks to Heroku's free dynos
[29:13] No users, so no angry e-mails to
[29:16] deal with. That was nice. And I just threw it up on GitHub
[29:19] Because that's just the default thing, I just work in the open
[29:22] But the purpose of course was just self-validataion that's what
[29:25] I wanted to prove myself I could still program, but when I throw
[29:28] stuff out into the open, that's just because that's my default, it's not because
[29:31] I'm necessarily trying to become an open source star. But I do
[29:34] get a lot of people—because I do a lot of open source—come to me and say
[29:37] "How do I get into open source", and I think that maintainers struggle with this
[29:40] question, because they want to make it sound easy to get involved
[29:43] They might say, "write me some docs" or "Send me a
[29:46] small pull request or something", and the problem with that of course is that
[29:49] it's not the normal creative exchange of ideas. You might
[29:52] even submit the pull request, but then most of the time that maintainer
[29:55] is gonna get angry and say "this isn't how I'd do it—rejected!"
[29:58] or "Change it!" and nobody needs another boss
[30:01] right? So if you get into open source
[30:04] to be creative, you just create stuff instead
[30:07] Because, when you go and talk to open source maintainers, like "how did you get started
[30:10] with open source," it was rarely "oh, I started doing docs for this
[30:13] one other guy. It was usually "well, I made stuff that I
[30:16] wanted, I threw it up on the Internet, and then some of it got popular
[30:19] and most of it didn't." And you'll never predict what's
[30:22] gonna stick and what's not. The reference to 200 repos is that I've probably
[30:25] got like 250 repos that I've started and you've—
[30:28] —odds are you've heard of zero of them. You may have heard of two or
[30:31] three. But the vast majority is stuff that I just built
[30:34] just for the sake of it, and I don't expect to hear about it again
[30:37] And it might seem scary to work in the open, like
[30:40] you know, people are going to criticize your code, but there's a secret:
[30:43] nobody reads code. So
[30:46] just don't worry about that. I'm not going to read your code
[30:49] So that made me feel a little bit less inadequate
[30:52] as a developer. Third one, now that I'm a self-professed
[30:55] thoughtleader who talks at conferences a bunch, most
[30:58] thoughtleaders get into this line of work, by doing something
[31:01] interesting, or observing something interesting. Sharing that insight with
[31:04] other people. But then eventually, you stop doing
[31:07] the work, and you run the risk of thoughtleading other people straight off
[31:10] a cliff. And you don't want to do that
[31:13] When it comes to test-driven development, I talk about test-driven development
[31:16] a lot. I've talked about it for more years than I've practiced
[31:19] it, which is worrying. And one day I decided to start leading
[31:22] some thoughts about test-driven development. In fact, if you google
[31:25] the phrase tdd failure, this blog post is the top
[31:28] result, which I"m particularly proud of
[31:31] And I got a lot of attention. And it was the front-page of Hacker News and I was
[31:34] in the article I was saying "well this is what London-school test-driven development
[31:37] is", and then the guy who actually invented that, Nat Pryce, was like
[31:40] "no, it's not, really", and I was like "But I just got 400
[31:43] thousand page views saying it was" and now everyone's going to find out that I'm a big
[31:46] idiot. And so I was really upset about that, but
[31:49] then, being the opportunistic and
[31:52] person just seeking the
[31:55] validation of everyone else, I decided to pivot and instead
[31:58] just rename what I do as its own thing, so I
[32:01] call it "Discovery Testing" and I actually built libraries
[32:04] and talks around how to practice Discovery Testing as its own school
[32:07] of TDD. So much so, that I realized I give a lot of talks
[32:10] but I hadn't actually practiced it much
[32:13] and I was just full of hot air. And so I felt like TDD, of course
[32:16] it's not very well understood. A lot of us try it and fail
[32:19] or don't really learn how to apply it consistently, so there's stuff
[32:22] to say here, but I've just become a talking head at this point
[32:25] And so I realized this last summer, maybe I need to
[32:28] start practicing this more on my own and really proving out
[32:31] that it really works. I've gotta validate my ideas. So I've got this
[32:34] Simplisafe alarm system. It's just a thing where you
[32:37] stick it to the wall, and if a door
[32:40] opens, an alarm goes off, police come to your house. Simple alarm monitoring
[32:43] And I love Apple's HomeKit, because I really love this idea
[32:46] of a smart home, like we learned today the Internet of Things
[32:49] aside from denial of service attacks
[32:52] is also useful for just the convenience
[32:55] of controlling your domain. So I have this server called
[32:58] homebridge, runs Node.js and
[33:01] you can build adapters, so I was thinking I'll build an adapter for Simplisafe
[33:04] So that when I'm on my couch I can say "hey Siri, turn on my alarm"
[33:07] The idea being, of course, I'd spend 40 hours building
[33:10] a thing to save myself 8 seconds the 3 or 4 times that I think
[33:13] to use the thing, because programming.
[33:16] So the question was: what's this thing in the middle? How do I
[33:19] build an adapter? The truth is I had no idea how to build this, and that's
[33:22] purportedly what my practice of test- driven development, Discovery Testing
[33:25] does. So does my process actually work? And so I actually
[33:28] experimented, and several hours in I was very
[33:31] relieved to find that I could build a thing and that it actually worked
[33:34] So there's this npm module now exists, simplisafe and it's got
[33:37] a simple little API. You pass it credentials, you get a
[33:40] client back, you can set the state. What was funny was I TDD'd
[33:43] this, right, so I was writing tests. And the only credentials I had were the ones
[33:46] to my house. And so I had to be really careful in the failure states, because I
[33:49] didn't want to send the cops to my house by accident
[33:52] And in particular, this got really
[33:55] confusing with Travis [CI], because I would upload it to Travis
[33:58] continuous integration, and people would send pull requests and it would
[34:01] change the beeping in my house and I'd have to make sure all the doors were shut
[34:07] But the lesson I learned there, I followed
[34:10] my own advice and really practice it. I was relieved to see that it
[34:13] went well. But honestly, I'm kind of ashamed because I went so long without validating
[34:16] my ideas. And you guys, just by having
[34:19] me here today, have given me a platform and I don't want to
[34:22] abuse it by just being a talking head. I want to make sure that everything I
[34:25] share can potentially really help you grow in your career
[34:28] So that was a valuable lesson and I think
[34:31] we can apply it to managers, like technical
[34:34] managers, former developers, what I've
[34:37] been able to generalize from my experience, especially at Test Double, is that everything
[34:40] at a distance seems simpler. The people
[34:43] actually doing the work, when a developer says this is going to take several more weeks, they're
[34:46] closer to it, they see all the complexity, which is easy
[34:49] to just hand-wave away when you're operating at a distance
[34:52] Additionally, when you have a lot of experience, you tend to
[34:55] —we're all pattern-recognition machines and you feed in all these problems and somebody might
[34:58] feed you a problem, and you might say "well, yeah, that looks like the 15 other
[35:01] things that I did." And you come up with this round, polished idealistic
[35:04] solution. But, of course, that's not going to actually map very closely
[35:07] to that individual's context. You have to actually trust the people
[35:10] closest to the work.
[35:13] And so that's been a humbling exercise in a manager role, to not
[35:16] just jump to conclusions that I always know best.
[35:19] But nonetheless, that was also helpful in me dealing
[35:22] with my own sense of inadequacy as I merge into this
[35:25] more management role. Let's talk a little bit about indignation
[35:28] First of all, I'm a big worrier
[35:31] Todd, mentioned I'm really high anxiety. I worry about
[35:34] banks, and credit card statements, and finances, and stuff
[35:37] and I really wanted a dashboard to handle this all for me and Mint
[35:40] was that for a long time. I'd use Mint, I'd see all my finances
[35:43] were still there, and I'd feel good. But
[35:46] six years in, I had this random thought: you know I wonder how Mint
[35:49] is actually secure? How does it actually securely go and get all these
[35:52] services? And get all my account updates?
[35:55] Of course, what I figured out was that it's just not secure
[35:58] it has decryptable versions of all of your passwords
[36:01] to all of your banking stuff and doesn't support two-factor auth or anything like
[36:04] that. And that's kind of worrisome. It's actually a very popular Internet
[36:07] cloud architecture right now called SPoFaaS.
[36:10] If you're not familiar with SPoFaaS, it stands for single point of failure as a service
[36:16] Another thing we're learning about today, too, with the Internet outage
[36:19] So, Mint, Yodlee, if they go away
[36:22] then all of your stuff just disappears. You're just giving
[36:25] a single point of failure for them to take all your money. So I was stewing on this
[36:28] I got angry. I was trying to figure out how do I get off Mint.
[36:31] Sure, I could cancel it, but I want to replace it with something better. What could I build
[36:34] So I thought: security matters.
[36:37] But I'm not an expert. I'm not going to build the next Mint or Yodlee
[36:40] and solve this very difficult distribution problem, but I could probably
[36:43] just build something for myself and at least personally feel a
[36:46] little bit safer. And so I built this gem that I call fine_ants
[36:52] In fine_ants you build adapters. So here's an adapter to Vanguard
[36:55] I pass it credentials. And because I can run it locally, I can
[36:58] actually do two-factor auth in my terminal, so I have two-factor auth set up
[37:01] now. And it just downloads all my holdings for all my Vanguard accounts
[37:04] And I built a little Rails app for it too that
[37:07] runs at localhost, and so it's encrypted on my disk
[37:10] And it shows me all of my account holdings and I click that button and it
[37:13] launches a Selenium worker to go and
[37:16] open browsers to go to all of my banks and stuff
[37:19] And I was really proud, because now I've almost got this dashboard that I wanted
[37:22] It's locally-encrypted. It's as safe as running it from my own browser
[37:25] Puts Selenium for good use to once, instead of just
[37:28] really brittle integration tests, and
[37:31] and, you know, admitting it's
[37:34] not a generalizable app. I mean, you can go and find this stuff on
[37:37] GitHub and clone it yourself and run it yourself, and I'd encourage you to try it
[37:40] But it's not going to be the next unicorn, billion
[37:43] dollar company. But, honestly, there's no shame in hobby
[37:46] grade. A lot of times, we're talking about creativity, right? We're talking about
[37:49] building stuff. And sometimes just solving your own
[37:52] problem is enough. Like these little toy apps like this are often
[37:55] what got us into programming in the first place, even if you're just
[37:58] solving your own problem, there's no shame in that. So that
[38:01] made me feel a little bit less furious
[38:04] at the world. Another example, so
[38:07] Test Double, our company, right. I've already referred—I used
[38:10] the term "test double" a few times, but some of you may not know it. That library
[38:13] gimme is actually an example of a test double library. If you don't
[38:16] know the term, the word "test double" is supposed to evoke the image of a
[38:19] stunt double. But not like a stunt driver in a plane, like
[38:22] a stand-in for your tests. So assume you like, maybe
[38:25] your app depends on the cloud, so you have to fake that out to make your
[38:28] test pass. Well, whatever you did to fake out the cloud is probably
[38:31] an example of a test double that fakes that service out
[38:34] And in JavaScript, the most popular test double
[38:37] library is called Sinon. But when
[38:40] I see people use Sinon, most of them don't understand it very well
[38:43] Because it's kind of confusing. A lot of people get frustrated
[38:46] because it's a huge API, or just angry at the
[38:49] fact it's not very opinionated. So I've given
[38:52] a lot of thought to making something better than Sinon in JavaScript
[38:55] And I decided, you know, a lot of users
[38:58] that use Sinon are in pain, but I have to admit I
[39:01] can't beat it. It's got like 2 million downloads a month
[39:04] But if I build something at least I'll be less grouchy and at least I'll
[39:07] have something to hand somebody instead of just more snark
[39:10] and whining. And so it was humbling, right, because
[39:13] I've built now—this is like the 4th or 5th test double
[39:16] library in a different language that I've built and I keep coming back to the same
[39:19] saw over and over again. And it's humbling to think
[39:22] that my entire career may well hinge on just
[39:25] two or three concepts and I keep repeating them, because
[39:28] I learn, because I'm passionate about it, and then I build
[39:31] something and then I share it, and then I feed back into learning more
[39:34] and it's this infinite loop of me iterating over time on just a handful
[39:37] of issues, and with Test Double, we're able to
[39:40] do that again by building testdouble.js. You can install it on
[39:43] npm. To get the npm install, and
[39:46] the npm package "testdouble" it works on the frontend and the backend
[39:49] There's a screencast on our website called happier tdd with
[39:52] testdouble.js you can go watch. We've also got a comparison
[39:55] blog post of testdouble vs. sinon and
[39:58] what was cool about testdouble is it works, but it
[40:01] most importantly, shares all of our opinions about what we've learned
[40:04] about test double libraries and good isolation testing over the years
[40:07] And it's certainly better than just being cynical and snarky
[40:10] about "oh, JavaScript sucks" or "JavaScript testing is this or that"
[40:13] A lesson I learned early on is that if
[40:16] your message isn't getting through to somebody and they're not hearing
[40:19] what you're trying to say, you can conclude one of two things:
[40:22] you can either conclude that they're a bozo for not understanding
[40:25] you, or that there's something with how you're trying to communicate that's
[40:28] failing to convey to them. And if you conclude that they're a bozo
[40:31] that's it. You just
[40:34] disengage, right? There's no next step. But
[40:37] I always assume it's something wrong in how I'm
[40:40] trying to communicate, and so I'm always iterating on my message
[40:43] and only as a very last possibility do I assume it's
[40:46] the listener's fault, because I can't control that at all
[40:49] And also, for your library
[40:52] to win, not everything else has to lose. Sometimes just doing something that's
[40:55] useful for a small group is plenty. Especially if you're able to communicate
[40:58] ideas in a way that moves other people forward
[41:01] in how they think about something. And certainly criticism
[41:04] is easier than contribution. It's really easy
[41:07] to be snarky on Twitter and say something sucks, but
[41:10] Christian Johansson who made Sinon, he put himself
[41:13] out there and it has served a lot of people really well
[41:16] and he's a really really nice guy, but I
[41:19] spent like two years just shitting on his work on twitter before
[41:22] I thought "maybe I should just build something that serves my needs
[41:25] instead." So building
[41:28] that certainly made me a little less angry about JavaScript testing.
[41:31] Another thing you may have noticed is that I like emoji
[41:34] I've used a few of them
[41:37] in the slides
[41:40] And creativity, open source stuff, can sometimes feel
[41:43] a little too self-serious and open source feels "you create,
[41:46] we depend." Other people start to pull your stuff
[41:49] and then all of a sudden they're really demanding
[41:52] and it usually starts with: you have an idea, you want to build a thing
[41:55] and it's a labor of love and it brings you joy, but then
[41:58] eventually companies start depending on it, and criticizing
[42:01] or opening issues or acting entitled and trying to get stuff out
[42:04] of you for free and that's a big bummer. In fact I know a lot of open
[42:07] source maintainers and what's super consistent
[42:10] is that they tend to hate their creations in
[42:13] proportion to how popular they are, and that just
[42:16] seems totally backwards. So I was feeling
[42:19] kind of exploited and exhausted at this particular point
[42:22] in my career. But I can't just escape open source, I'm not going to
[42:25] ragequit GitHub and delete all my stuff and yank all my stuff
[42:28] and take my ball and go home. So maybe if I just build something
[42:31] new, something fresh, I'll find a fresh start. And the way I did it was, I
[42:34] decided I was going to build something that no business could ever want
[42:37] To just be creative
[42:40] for the sake of creativity. And sometimes, even still, if I build something
[42:43] that I worry that a business might exploit, might
[42:46] build a business around and cut me out, I'll just license it
[42:49] GPL as if troll them, because then that way they have to come
[42:52] to me to obtain a commercial license
[42:55] This is such a project. I think it is
[42:58] GPL'd, called emoruby. So there's not a lot of transpilers
[43:01] for the Ruby language, but this one transpiles emoji
[43:04] into Ruby code. So here's an example file
[43:07] listing of emoruby. This is a class called Heart,
[43:10] defining a method called wave, printing out a statement saying hello
[43:13] and ending those two things. And then
[43:16] Instantiating the heart and calling wave
[43:19] So this, if you're not familiar with emoruby, this
[43:22] translates to this ruby here, and it totally works
[43:25] And it was a lot of fun. So tl;dr what I learned
[43:28] on emoruby is that it's super dumb, it's
[43:31] just there for fun, it's just there to be joyful. I actually got a lot of
[43:34] contributors on it, because they found fun in trying to map
[43:37] different keywords and control- flow structures to what
[43:40] emoji should that be. But it brought me a lot of joy
[43:43] and it's had zero issues opened against it this year
[43:46] So it's one of my favorite projects. It's okay to just build stuff for
[43:49] yourself. I know some of you are developers here and you're here with your managers,
[43:52] hoping they're not looking over your shoulder right now: it's actually OK just
[43:55] to build things for fun. The joy of programming is like
[43:58] really undervalued and we get too self-serious about our craft
[44:01] So that helped lessen
[44:04] my sense of indignation. Looking back on all this stuff
[44:07] is—I wouldn't recognize myself
[44:10] ten years ago, I think, because all of this
[44:13] these creative exercises have really changed me as a person and I've actually
[44:16] found a way to mature and grow up, and
[44:19] I see you there, I'm saying "hey look creative stuff, this is easy" but I've
[44:22] also just lambasted you with 12 years of side projects
[44:25] and "look at me! look at me! This is a cool thing I built!" I understand
[44:28] that might make the bar feel higher, and you know what
[44:31] maybe you're right, because it's true that creativity is not for everyone. Here's a
[44:34] quick litmus test if you're perfectly
[44:37] content. And you're totally fulfilled. And you're OK with
[44:40] the status quo, then why would you want to change things? You're right, maybe
[44:43] you aren't a creative type. You should just enjoy the beach that you guys have
[44:46] not too far from here. But if you have any negative
[44:49] feelings at all, our culture right now, we tend to pathologize
[44:52] negative feelings as themselves being bad, but often they're just a
[44:55] symptom of some different root cause, and if you analyze and
[44:58] you're open about that with yourself, you might find that what's
[45:01] really bothering you is that you're using the wrong tool for the job, or
[45:04] there's friction between the technologies and the practices that you're using
[45:07] or work can't offer you what you need, or maybe you just have your own internal
[45:10] baggage that you need to get over. And creativity can be a great outlet
[45:13] for those kind of root cause problems. And if you reflect
[45:16] on how you feel and you feed—you accept—
[45:19] those emotions, what's funny is our asynchronous brain will just
[45:22] start spitting out ideas and it'll be a big idea generator
[45:25] and hopefully, you'll find a way to exercise it.
[45:28] And when I tell you, like when you
[45:31] feel confused, or when you feel down, or
[45:34] upset or scared, all
[45:37] of those emotions are the place where all the good stuff
[45:40] comes from. Great ideas don't come from people who've
[45:43] already got everything figured out, and
[45:46] when the bar's that low, you fling over it and hopefully
[45:49] wind up in a better place. The important thing is you've gotta find your outlet
[45:52] And I don't know what that outlet is for everybody
[45:55] In fact it's important for me to mention that that outlet might not have anything
[45:58] to do with software. Certainly, if
[46:01] my outlet for creativity wasn't software,
[46:04] my wrists wouldn't hurt as much and I'd probably get more sun and I'd be in better shape
[46:07] So find what that outlet
[46:10] is for you, because it may or may not have anything to do with software
[46:13] Tomorrow, I was here last year, and the day after SCNA
[46:16] was one of my favorite days last year, because I just sat
[46:19] on Manhattan beach and watched football and drank with Big Ten football
[46:22] from 9am to 3pm which is something I can't do in the
[46:25] eastern time zone, so that was really cool. But tomorrow tomorrow,
[46:28] we're going to have even more fun, because we're going to be here
[46:31] programming stuff. Todd
[46:34] my partner and I, we're going to join forces tomorrow and we're doing
[46:37] what we call a "test smells", like "code smells" workshop
[46:40] it's a really fun, engaging thing where we all talk
[46:43] together about things about testing that we hate
[46:46] I hope that you come and join, and what we do is
[46:49] listen to stories, and we've got this repository of
[46:52] 30 different types of problematic tests, work through
[46:55] those examples and really kind of bring a name to a lot of the different
[46:58] antipatterns that we find in tests. I hope that you'll join us, it's a really
[47:01] really fun exercise, and it's going to be happening kind of coincident
[47:04] with the code retreat and what other activities we have
[47:07] tomorrow. So again, my name's @searls
[47:10] or Justin, you can call me whatever you like
[47:13] I hope you tell me on Twitter what you thought of this talk, any feedback
[47:16] you have. Like I mentioned, we're here to
[47:19] fix the software industry and to do that we're gonna
[47:22] need creative people who want to creatively solve those problems and help
[47:25] inspire that in others. If you're interested in joining, our
[47:28] team I hope you'll contact us. And if you know any
[47:31] teams that are looking for that slack. Looking for some
[47:34] outside inspiration, we're always looking for
[47:37] additional clients that we can work with. You can reach us at
[47:40] or find me or Todd tonight or tomorrow, we'd love to talk to you
[47:43] Also got a lot of stickers and business cards we'd like to share
[47:46] But, you know, you've been super patient. Like Todd
[47:49] mentioned, I'm the only one standing between you and free drinks
[47:52] and nobody got up and left, so that's
[47:55] really humbling. Thank you so much for your time today.

Follow-up interview

After giving this presentation at NG Conf 2017, I sat down with the famous @EmberSherpa from This Dot Media for a discussion about this presentation and how it fits the context of the JavaScript community as frameworks like Angular, React, and Ember have become more mature. If you're interested in additional thoughts behind this talk and its implications for open source work, please enjoy this 20 minute interview:

Test Double helps software
teams scale with stability.