How to scratch an itch: A creativity talk

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.

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:

‍

Transcript of the talk

[00:00:00] This talk is titled, How to Scratch an Itch in 200 Repos or Less. AtSearls is my real name. My parents were quite prescient and on brand back in the 80s when they named me. This is what my face looked like in 2011. And thanks to personal branding, I'm now stuck with this face forever because you might see it from Twitter or GitHub as my avatar.

‍

[00:00:19] Just like Todd mentioned, I co founded an agency with him five years ago called Test Double. Our mission in life is to improve a lot of the stuff about software that sucks. And one of the things that sucks a lot is that, Most engineering teams operate at capacity and they don't have enough slack in the system to improve things like testing and quality and craft.

‍

[00:00:36] And so we come in to pair with those teams to add enough capacity so that we can all work together to make stuff better. It might sound familiar as a business model. It's like consulting except good. So if your team could benefit from that sort of thing, I hope that you'll chat with me or Todd tonight or tomorrow.

‍

[00:00:51] So yeah, how to scratch an itch. You might be able to infer from that title that this is a talk about creativity. Everyone loves creativity. Yay, creativity. That's a good thing, right? Okay, cool. Let's talk about creativity. So what is creativity exactly? It's one of those axiomatic concepts that we generally don't, interrogate or introspect much on.

‍

[00:01:09] And I forced myself to think about this when I was designing this talk. First thing that came to mind is that creativity is a lot like passion. Passion's hot right now. We got all these passion projects. Look at all these passionate logos for passion projects that people have made. But personally, I don't get on board with a movement until I can find a way to engage with a brand and its hashtags.

‍

[00:01:28] The American Express Passion Project. And it actually serves as a really good example of why passion doesn't equal creativity because it fizzles out. Like domain name registrations. So the Amex passion project is just gone now. So no, passion isn't quite what creativity is. You might say, is creativity art?

‍

[00:01:47] Certainly coding feels creative, right? We know it's a creative enterprise. But not all of our code is art. Art, when I like put it up on a screen, it's mostly functional most of the time. It certainly can be art, but it doesn't seem like the best metaphor or abstraction. You could say it's creativity, vision, and foresight.

‍

[00:02:05] If we had a crystal ball, we could see where the cloud is and where it's gonna go. And there might be an aspect of that, but that's not in itself building anything. It's just prognostication. So vision's not enough. And I thought about this at length to try to figure out, Am I creative? Are you creative?

‍

[00:02:21] And if I was forced to like, think in those terms and that popular framing about, Creativity, like filling out a survey. Are you incredibly passionate and do you create beautiful things? And can you see into the future? Of course, most of us would say no to all three of those things. So certainly we're not creative.

‍

[00:02:37] That's a really high bar to clear. Creative people are these magical unicorns and that's not me. That's not us. And that's disappointing. We can usually at least relate to the idea of a creative spark, right? Like we have an idea in the back of our heads, we're walking down the street, an idea occurs, and then of course what happens next is we just effortlessly create amazing things based on that idea.

‍

[00:02:57] Unfortunately that doesn't comport with my experience, actually like I have a, Creative ideas, they stress me out. That spark tells me like, I'm already really busy. How am I going to find the time or the capability to go and accomplish that thing? And these ideas, they scare me because I don't think I'm going to have fear and uncertainty and doubt.

‍

[00:03:13] I'm not going to be able to do. I'm like, where does that spark come from? Is that like some big dragon breathing fire behind me? Should I be running from my ideas or I'm going to burn up? I've got this fraught relationship with these creative ideas in my head. And so I was thinking about. My own weird relationship with creativity.

‍

[00:03:28] And I realized the best metaphor for me is that creativity is a chronic illness. Which I know sounds horrifying, but hear me out. Cause what happens is I go two weeks, three weeks, four weeks. And eventually something makes me angry. Something wells up inside of me. And then I have an episode of Creativity and I emit a blog post, or a library, or a framework.

‍

[00:03:49] And the way I think of it is like, it's like like kidney stones, like I'm passing NPM modules. Uh, and then I feel a sense of relief after. So they've seen this pattern in my life, right? I've got all these negative emotions, this toxicity. I'm a really sad, broken individual. And over the course of my professional life, I keep finding these ways to shape that into positive outcomes.

‍

[00:04:12] And I don't know how that happens. And so this talk is an exploration into trying to figure that out. And maybe there's something that you can relate to. Because what I've found is that reframing of what creativity is certainly lowers the bar. It's are you a broken individual? Good, then you can be creative too.

‍

[00:04:28] So let's wind all the way back to the beginning of my career. I was working at a big accounting firm. I wasn't very creative. I didn't have very much autonomy at my job, and I would get ideas, like anyone gets ideas, but I wouldn't be able to act on those ideas, and so they actually just bummed me out.

‍

[00:04:43] In fact, eventually the ideas would fade away, and that would make me feel relieved, because now they weren't stressing me out. And it took me years to realize that what I was missing was I didn't have an outlet for it. to practice those creative ideas, to develop a feedback loop, just like we do with coding stuff.

‍

[00:04:57] And I learned once I started trying that production wasn't necessarily the best creative outlet either. Us as developers working at machines at work, we might think that this is creativity, building ideas, but typically they're other people's ideas. We're building, reports or mailers and shopping carts.

‍

[00:05:14] And we feel creative because we did create it, but because it wasn't our own, it doesn't really scratch the same itch, I don't think. Separately. We usually work on teams. And an important part of building software on teams there's me, and that's my team an important part about building software on teams is that we're building everything to be very consistent and orderly so any of us can be productive in that environment.

‍

[00:05:35] But creativity is sporadic and messy. I might have an idea like, hey, I could pull this one package out and then that would eliminate the need of these two packages because I could put a factory in front of them and look at this and this is really cool and I could be really proud of the creative thing that I just did.

‍

[00:05:49] But from everyone else's perspective, they see the system as becoming less stable and less workable and I, they're worried and I get mad because they don't appreciate this cool creative thing that I just did. And then they get angry because I keep going off the reservation and disrupting the orderliness of the system.

‍

[00:06:05] A third thing that I, we see happen a lot in our company at Test Double is developers who are passionate about what they do, they put a lot of effort, they tie up their ego in the stuff that they build, and then they hand it off, they get excited, and then it just sits in QA, or people, comment on their pull requests, and it and things take forever, and they don't see it in front of users, and then eventually they just get angry, Because what they did was, they ceded control of their happiness and their emotional state to somebody else.

‍

[00:06:32] And at work, that's just not appropriate because we're not building this stuff for our own good. We need another place to to practice creativity. So you gotta create your own space where that's safe. And one morning, I was taking a shower. Ideas come to me in the shower. I don't know when they come to you, but they always come to me in the shower.

‍

[00:06:49] And I had an idea and it made me angry, because I, of course, ideas are bad, like I explained earlier. And I got so mad at this idea that I went and sat at my computer and I hacked on it until I could build a thing. And I felt that relief again, but this relief was different. This was like, like this was the first green bar in the test.

‍

[00:07:06] I was like, okay, cool, I understand this now. Okay. And I went from a disgruntled employee to a merely gruntled employee because I was starting to learn how to be productive with creativity. And from then on, when I got a creative idea in the shower, I'd roll my eyes because now I'd be like I gotta make time for this.

‍

[00:07:23] Maybe there goes my Saturday or my evening or something. But at least I had a reasoned way to work through it. And so ever since I started programming professionally, I've always had a main project that occupies most of my time, most of my focus, but a little project to the side. Whenever I get frustrated or if I want to play with something or if I'm learning something, I can pull on that thread as well.

‍

[00:07:42] And I always balance both of these things. Of course, this comes at risk. I'm very often burning the candle at both ends. If I work all weekend cause I'm so excited about my side project and I come to work on Monday morning, the last thing I want to do is program. That can be problematic.

‍

[00:07:56] And. In the last several years in particular, I spent so much time on the road doing all this open source stuff on top of my normal job that I'm often asking, like, why do I do this? And that's where the introspection of this talk is part of the why I did this talk is I don't think that I'm that special.

‍

[00:08:12] I think all of us could be this creative. And it would save me a lot of time if all y'all would do the talks instead of me. So when I sat and I thought about really why is it that I do this? Almost shame to admit those sources cause they're from my childhood. So I got a few little childhood anecdotes.

‍

[00:08:28] My dad was actually an amateur golfer. Like one of my first memories is watching my dad play golf on TV at an amateur PGA event. And so in Southeastern Michigan, every well to do business person wanted my dad in their foursome. So I spent as a kid, a ton of time at country clubs with kids who were way richer and more world weary and experienced and knowledgeable and well to do than me.

‍

[00:08:48] And that was an important part of my upbringing because it taught me the ever important skill of feeling inadequate.

‍

[00:08:58] Talk about my church a little bit. I went to a church that didn't necessarily work in its community and serve the poor or anything like that. I went to an upper crust, white, evangelical, Presbyterian church where I spent like years five through ten of my life learning how to understand very intangible concepts and then feel extremely strongly about them and argue with passionate rhetoric.

‍

[00:09:17] And that was also a really important skill because I learned righteous indignation. Fun fact about me, nobody's ever asked for my opinion because no one's ever needed to. I can't help but form really strong opinions the minute I see something and that's less fun than it sounds.

‍

[00:09:34] Third thing about my life I One of those people at lunch talking about College programs, I got a computer science Degree in college, and I didn't, I wasn't very good at it. My professors pulled me aside in senior year When I was trying to find a job, And some of them confided in me that maybe I should find a more hybrid role Where I'm also talking to people more And maybe not trusted with the computer.

‍

[00:09:54] And it was through there that I learned this real deep grained incompetence. And what's funny about all those three things is clearly they're negative, but they have flip sides that I think are really valuable to exploit. The inadequacy leads to me having a bunch of people that I aspire to in my life, that I look up to.

‍

[00:10:11] The indignation means that I always have something to say or A perspective, whether it's valid or not. And the incompetence means that I don't view myself as a rockstar. I always feel like I've got a lot to learn and a lot to improve. That translates to a means and a motive and an opportunity to exploit creative ideas.

‍

[00:10:27] Also worth mentioning here is this, these are all markers of tremendous amounts of privilege in my upbringing. Most kids don't have the amount of spare time that I did to nurse my existential grief to the extent that I have. But through doing a lot of creative stuff, I've learned how awesome and how enriching and rewarding it can be.

‍

[00:10:44] And getting back to Todd and I forming Test Double, a big reason we did that is we want everyone to be able to have that experience by moving at a sustainable pace, By being able to build creative stuff in a way that's congruent with our normal work life so that you don't have to be working on nights and weekends or particularly privileged to be able to enjoy the fruits of creativity.

‍

[00:11:04] If you want to talk to us about that you can email join at test double dot com. Our first step in our recruiting process is really low pressure. It's not some sort of technical interview at a whiteboard. It's literally a conversation about how we work, and how you work, and whether you'd like to try how we work.

‍

[00:11:18] Just to learn about us and learn a little bit about, what we've learned about productive, autonomous software development. So anyway, all these things, really negative. How does that lead to creative ideas? I feel like it's a game of Mad Libs in my head. This is my user story for creativity.

‍

[00:11:33] I feel righteous indignation. But I don't know what I'm doing. Maybe if I build something, I will feel less inadequate. And I have nine little anecdotes, nine little stories of side projects over my career that have helped me to mitigate some of that toxicity in my heart. And I'm going to start with talking about incompetence.

‍

[00:11:52] Cause like I mentioned, I wasn't very good in college, and I was really worried, like, why would anyone ever pay me to build software when I can barely learn how to do it? And my library at the time where I worked said, hey, we need a new citation editor. On the web. And I thought, I'm gonna, I'm up to this challenge.

‍

[00:12:06] I feel like I don't need this computer science highfalutin stuff, but I also don't know how to build apps either. So maybe if I build it, I'll at least find a way to survive this profession. And it was a pretty low pressure gig, cause it was like ten bucks an hour and I could spend all summer on it.

‍

[00:12:20] So I built this thing called NightSite. A little citation editor on the web. It was free and I was really proud. I did it. I accomplished a lot of my goals. It supports all the major style guides, dozens of sources, only one that did that has an account system where you can log in, create bibliographies and export them.

‍

[00:12:36] It's gotten millions of users. And still to this day, it's by far the most used piece of software that I've ever written. And I made it all up as I went. I didn't read in a book how to do this. I just had to figure out how to do a reset password thing. And I just figured it all out as I went. This, of course, had some very minor downsides.

‍

[00:12:53] Like for instance, it's totally insecure. It's 100 percent manual testing. It produces gigabytes of daily server warnings that, that those poor admins who still, over a decade later are still dealing with. And it's one 16, 000 line long PHP file of just ifs and elses and string concatenation.

‍

[00:13:13] But what had happened to me in my classroom education was it had drilled into me this fear that I don't get what's going on. It paralyzed me from ever practicing any of that creative reflex and that creative muscle. So recognizing that I needed a safe space that were, where it was okay to make a mess and to do that in concert with learning proper, computer science y stuff was crucial to me even being in this profession, much less on a stage talking to you all about it.

‍

[00:13:39] So that certainly lessened my sense of incompetence. The other thing at the time, the web was just like a really fancy hypercard implementation. I didn't feel like a real developer. My friends all worked like on airplane real time controls and operating systems. And so the web, versus the, being closer to the metal, like Uncle Bob told me, is Uncle Bob still here that today that you're not a real programmer unless you programmed assembly.

‍

[00:14:00] I hadn't really programmed a lot of assembly, so I didn't feel like a real programmer. And so I tried to go native at multiple points in my career. Maybe on a Saturday I'd open up Xcode and say, I'm going to build an OS 10 app. And I'd look at the documentation and it would confuse me and I'd feel stupid.

‍

[00:14:13] And then I'd wait a weekend and I'd go and. And find a different part of the documentation and it would depress me and I'd feel stupid. And then the week after that I would open up Xcode and I'd look at a different part. And this outside in maybe if I just read it all and then I'll know how to make native apps.

‍

[00:14:26] Of course it didn't go well. And time kept passing and I just concluded I was probably too dumb to make native apps. Maybe I just had to stay on the web. But then one day, a momentous day that a lot of us remember, the iPhone was announced. And I thought to myself, as soon as this thing has an SDK, That's I'm gonna make an app, I really want to build something for the iPhone.

‍

[00:14:44] The only problem was I had no idea what that would be. So I got the original iPhone and it was, it changed my life, right? It's beautiful, obviously, it's innovative, there's nothing like it. I knew from the first day I had it that it was life altering because I took my wife to a restaurant and I ignored her the whole time.

‍

[00:14:59] And I was like, this is the future. And boy was I right. So The thing about that was I was staring so long because Edge was so slow. And I had this one gaming forum I like to visit and there's first of all, it's not very readable, but like it took three minutes to load a single page of what were often 50, 60 page long threads.

‍

[00:15:17] And so that was unacceptable. But there was no such thing as the mobile web at the time. There's certainly no responsive design. And so I thought to myself, maybe I could build an app that was like a client to this website. Because I felt like the mobile web was a joke, but I kept failing to learn Coco.

‍

[00:15:32] And so maybe if I built something, then I'd at least learn how to learn a really unfamiliar thing and tackle a new platform. And I did it. So I started by building a little system that would just go and fetch the HTML and then I figured out how to load a library like libxml2 and parse all that into an object model.

‍

[00:15:48] And then, I'd find all the media in those objects and go and fetch them from the internet so I could build a UI and then I'd have a custom user interface in an iPhone app. And you know what? It was way faster and it was legible and it was full featured. You could log in and edit posts and stuff.

‍

[00:16:01] It was really neat. It was also the very first time I ever contributed to open source in a real way and It was so cool because every time that the Facebook app got launched, a little bit of my code ran. And when I realized the impact that I could have that way, I got addicted to sharing my stuff in open source.

‍

[00:16:16] It was also my very first user group talk, and the only reason I'm here today is because this one app happened to go well. Of course, it was rejected by Apple, because sometimes people swear on the Internet, and swearing was against the guidelines, which were very prudish at the time. And so I threw it in the trash.

‍

[00:16:32] But I didn't care, I was happy as a clam, because mission accomplished. I'd learned how to learn a thing. That was the real purpose for that exercise. And what I learned there is learning something simple is pretty easy, so long as you can fit it inside a day, or whatever the bounds of that passion is, right?

‍

[00:16:46] Because it's enough to get through a weekend, but then when the going gets tough, your motivation fizzles. If you're trying to learn something bigger, that's gonna take several days, weeks, months, then you really need a plan. that's going to push you through those barriers as time goes on. Or else, you'll get distracted.

‍

[00:17:00] You'll end up with just like a graveyard of half finished projects everywhere. And so what I try to do is find a small thing, the smallest thing I can possibly care mad about really like I need this project to exist. And I'm going to just push and drag it over the finish line. And that was a lot of valuable lessons and it certainly made me feel less incompetent as a developer.

‍

[00:17:17] Cause I got to go native. For a long time I did Java development, and Java's a cool language but I felt, like it was a little uncool it was certainly not getting a lot of buzz in the mid aughts certainly not like Ruby was, a lot of my friends they seemed really cool, they all worked at Ruby and work, and the best way I can compare the two languages is via Super Mario Kart.

‍

[00:17:36] You might think of Java as being like one of the early courses. That's a really wide lane and you can't really mess up that badly. If you go off the course you can just drive back on. And we get that with Java because it's not a very expressive language. The compiler does a lot for you, the tools do a lot for you.

‍

[00:17:52] Ruby is more like Rainbow Road. Where it's narrower and faster and if you fall off, Lato has to pick you up and you lose like 20 seconds. And that's just like reflective of like dynamic programming and meta programming and how you don't have the same amazing tooling. And so programming, even at this point in my career, I felt like I wasn't a very good programmer, much less.

‍

[00:18:12] Dynamic programming, and at the time in Ruby, Metaprogramming, like changing at runtime, The the object model, the classes, And method definitions I didn't even understand How that could possibly work, and I joined my first Ruby team, completely terrified, And surrounded by people who were way cooler than me, And I thought, I have nothing to contribute here, Until I looked at their test suite.

‍

[00:18:29] Because in Java, we had A pretty formal sense of What good tests looked like, and I knew that Ruby Has wrote a lot of tests, but it turns out that They all sucked. And so when I looked at those tests, I thought maybe this is like a way for me to sneak in the back door and actually be relevant.

‍

[00:18:43] I looked at a test like this. This is creating a fake dog object, and it's saying the dog should be called with the method wag and the argument tail, and then you pass the dog to your subject under test, and this just looked way wrong to me. First of all, there's no type awareness, so you don't know that dog actually responds to wag.

‍

[00:18:59] Then these things are out of order. It's given, then, when, and that feels awkward. And the API for making that test double and stubbing it was confusing. So I got care mad enough to say maybe I could like I hate these mock objects, but if I can't metaprogram Ruby, I can't build something to replace it.

‍

[00:19:15] So maybe if I build it, then I'll at least find a way to fit in as a Rubyist. And my whole goal here was just to cargo cult my favorite test double library in Java and implement it in Ruby. And it turned out that didn't work so well. I learned. some humility in the process that I had to actually go and talk to humans about idioms and conventions in Ruby.

‍

[00:19:33] I had to really bone up and learn, like, how the Ruby object model worked. And then I had to put the time in. I took two weeks off for Christmas that year and I spent the whole time squirreled away just working on this which my family didn't appreciate. And so what came out is this little fun gem called GIMME.

‍

[00:19:48] You pass it a type it's got the type awareness built in. Here I pass it the subject in the correct order. And here you can say, you verify the dog's called with web and tail in a way that looks like a method invocation. And so I was really proud, because this had the type awareness I was looking for.

‍

[00:20:01] It preserves the test order. It has a clever tourist Ruby like API. Of course, nobody adopted it, because nobody knew who I was. But I shopped it around at a couple of conferences and got people like Jim Wyrick to incorporate this style into FlexMock. And now RSpec which was the first example, has incorporated the same style.

‍

[00:20:17] So I was able to move the needle a little bit. But what that project taught me was like, it's important to get out of the line of fire, right? I don't want to try to learn how to metaprogram like in the most important feature, because then I'm on the spot and everyone's going to call me out as an imposter.

‍

[00:20:33] Meanwhile I learned working code can sell an idea way better than just nitpicking stuff. If I'd just come to that team and said, hey, your tests suck, because I don't like this and this, they'd say, what, but if you can throw a keyboard at the problem and actually build something, a proof of concept, you can reframe the discussion around the concrete stuff.

‍

[00:20:47] And that's how I was able to sell that idea. Additionally, if what you're selling is ideas, the best part is they require no maintenance. Nobody's going to open up a GitHub issue at 3 a. m. on a Saturday because your idea stopped working. And so it's true that thought leaders have more fun. So that made me certainly feel less than confident.

‍

[00:21:04] A little bit about my own sense of inadequacy and how I was able to deal with that. I practice a thing called Midwestern programming. So if this is the continental U. S. My. general stereotype perception is people on the East Coast, the developers there, they have serious jobs. They work at universities, doing high finance.

‍

[00:21:23] It's like very obviously valuable work because it creates a lot of money. And on the West Coast, your apps obviously don't make any money, but they get a lot of attention. And you got like all the really popular Snackle Chat and other stuff that everyone has heard of. But in the Midwest, we do a lot of charts.

‍

[00:21:39] We have all these, we have all these blue chip companies that have backend office apps that they need built. That might only have three users that they might, not be that exciting. So frankly, I'm not great at cocktail parties when I explain Oh we're building the system that participates in demand response, energy markets in various parts of the people, their eyes glaze over.

‍

[00:21:59] And I had a certain amount of rockstar envy. I want to just build a cool thing that I could say in a sentence. People would know what I did. So I felt like my work wasn't exciting, but I only really knew how to build enterprise stuff. So maybe if I built something that was just designed to go viral, I'd feel more appreciated.

‍

[00:22:13] There was a service called Mustachify me at the time. My friend Aiden wrote. And what you do is you pass an image, and then it would use the Facecom API and put mustaches on the faces. And I thought that was cool, but let's go bigger. What could I build that leveraged this? And so I made a Chrome extension called Mustache.

‍

[00:22:27] And my friend Cory and I wrote it. And so basically we would just go to the Mustachify service, replace all the images on every page in your browser with a mustachified one. And we thought this was really cool. We did it in three hours. We posted to a forum at night. We went to bed. And then the next day we had 3, 000 installs of like pro users.

‍

[00:22:43] So they were visiting like 40 pages an hour, 42 images per tab. And we did the back of the napkin math to realize it was like 5 million requests per hour. And we learned a valuable lesson on that first day. It's actually, it's a popular meme right now called serverless architecture. Cause we just destroyed Aiden's poor dino.

‍

[00:22:58] So we had to go back to the drawing board and we, what we did was we rebuilt it, but this time talking directly to the face. com API, which did the facial recognition, got you JSON back. And then with that JSON, we take our own image and then just rotate, transpose, and put it over the images ourselves. And that was really fun.

‍

[00:23:13] That was a fun weekend hack. But I didn't get a ton of attention. In fact, time passed. I forgot all about this thing until I saw in the news that Face. com was getting acquired for 80 million by Facebook. And that made, that was surprising. So I went and started Googling around my mustache thing and saw it had been covered and tested.

‍

[00:23:28] It had been covered in PC World and in print. It was on The Verge. The Glamour magazine wrote an article about this Chrome extension and no one ever thought to contact me. But I felt pretty proud that I'd had this impact. I'm pretty annoyed too when I thought about it, it's I looked at face.

‍

[00:23:42] com's developer forums and almost all the posts were just people using my stupid mustache thing. And the developers at face. com were giving them active tech support. And I thought, but this is violating your terms of Oh, it's so that you hockey stick and can show off a ton of usage to Facebook. And I bet you a big part of that 80 million valuation had something to do with Where's my cut?

‍

[00:24:02] My cut came in the form of face. com shutting down and then me getting a bunch of email because all of a sudden, nobody's browser worked. Because all the images were just 404. And that was cool. I built a popular thing. Yay! But I didn't get to enjoy any of that popularity at all. And I may have made somebody else literally millions of dollars.

‍

[00:24:21] Citation needed. But, it feels that way. Laughter. And I made lots of users angry. The only time they ever learned about me was after their stuff stopped working. And I was left with no recourse. I didn't have time to build a new face. com. I just had to shut down the extension. So I learned in the process serverless isn't.

‍

[00:24:39] Obviously if you depend on somebody else's server they can always pull the rug out from you. That was a valuable lesson. And also like chasing popularity without an underlying purpose or value statement is toxic because when I did run into a problem, I didn't have the time, there was no like economic reason or even moral reason for me to invest the time to fix it.

‍

[00:24:56] I was just left, with people angry at me. So that sucked, but it did get covered apparently in the last season of HBO, Silicon Valley, where they made like an AR version of the plugin. So that made me feel pretty cool, another way that I felt inadequate as a developer is one time I was on this legacy rescue project, a big waterfall project.

‍

[00:25:14] If you don't know these terms, by the way legacy, when we use that in software terms, it means that your kids will inherit it. And rescue means that you want to be rescued. And so I was on this project for months. I could barely, I my, my computer was just a memory at this point cause I hadn't programmed in so long.

‍

[00:25:30] I'd forgotten how to program. I felt could I even program anything in two months anymore? I was really feeling kind of despondent and out of touch with myself as like a craft person. Craftsperson and at the time the to do apps were like undergoing this like renaissance because it was still early in the app store And there's all these new to do apps, and I don't really like any of them I kept falling back on this plaintext thing that I did where I define a project with a colon and dash arise tasks And I indicate to myself something's done with a slash or blocked with a pound sign or I would date it with braces And I would just do this instead of using an app, but of course that was inconvenient So I was thinking at the time, I was like, I feel like I hate all these to do apps, but I've also forgotten how to code, so I can't build my own, but maybe if I were to try, I'd at least be able to restore my dignity as a developer.

‍

[00:26:11] And what I had to do there was, like, give myself the constraints needed, and so I gave myself a little quest. I said I want to build a to do app that's so great, that even that I will use this at the exclusion of all the others, and I only want to give myself 24 hours. Can I still hack it?

‍

[00:26:25] Under pressure. So I built this app called DoingIt. So DoingIt, you define a project, and I I started by just saying, throw all the content in a div into ContentEditable. Dump it into local storage, read it from local storage, and then use the tool to track the rest of the work in the tool.

‍

[00:26:40] So I was using doing it to build doing it from like minute 40. And so I did it. I built the thing. It's still up at todo. testdouble. com. If you want to check it out, you can, make a project. It'll auto format based on the lead character here. And so this is me making a couple different things.

‍

[00:26:54] I can mark them done or overdue or high priority, and then mark them all done. That was a lot of fun, I finished it within the one day. Gave me a renewed sense of confidence as a developer. It still works, thanks to Heroku's free Dynos. No users, so no angry emails to deal with. That was nice.

‍

[00:27:10] And I just threw it up on GitHub, because that's the default thing. I just work in the open. But the purpose, of course, was just self validation. I just wanted to prove to myself I could still program. But when I throw stuff out into the open, it's just because that's my default. It's not because I'm necessarily like trying to become an open source star, but I do get a lot of people, because I do a lot of open source, come to me and say, like, how do I get into open source?

‍

[00:27:30] And I think that maintainers struggle with this question because they want to make it sound easy to get involved. They might say write me some docs. Or send me a small pull request or something. And the problem with that, of course, is that it's not the normal creative exchange of ideas. Like you might even submit the pull request, but then most of the time that maintainer is going to get angry and say this isn't how I do it.

‍

[00:27:48] Reject it or change it. And nobody needs another boss. And so if you get into open source to be creative, I recommend you just create stuff instead. Because when you go and talk to like open source maintainers, like how did you get started in open source? It was rarely I started doing docs for this one other guy.

‍

[00:28:04] It was usually. I made stuff that I wanted. I threw it up on the internet and then some of it got popular and most of it didn't, and you'll never predict what's going to stick and what's not. The reference to 200 repos is I've probably got like 250 repos that I've started and you odds are you've heard of zero of them, you may have heard of two or three, but the vast majority is just stuff that I just built just for the sake of it and I don't expect to hear about it again and it might seem scary to work in the open people are going to criticize your code, but there's a secret that like nobody reads code.

‍

[00:28:34] So just don't worry about that. I'm not going to read your code. So that made me feel a little bit less inadequate as a developer. Third one, now that I'm like a self professed thought leader who talks at conferences a bunch, most thought leaders get into this line of work by doing something interesting, or observing something interesting, sharing that insight with other people.

‍

[00:28:54] But then eventually, you stop doing the work, and you run the risk of thought leading other people straight off a cliff. And you don't want to do that. When it comes to test driven development, I talk about test driven development a lot. More, I've talked about it for more years than I've practiced it, which is worrying.

‍

[00:29:08] And one day I decided to start leading some thoughts about test driven development. In fact, if you Google the phrase TDD failure this blog post is the top result, which I'm particularly proud of. And it got a lot of attention. And it was the front page of Hacker News, and I was in the article, I was saying like this is what London School test driven development is.

‍

[00:29:25] And then the guy who actually invented that, Nat Price, was like, no, it's not really. And I was like, but I just got 400, 000 page views, saying it was, now everyone's gonna find out that I'm a big idiot. And so I was really upset about that. But then being the opportunistic and person just seeking the validation of everyone else, I decided to pivot.

‍

[00:29:41] And instead just rename what I do as its own thing. So I call it discovery testing. And I actually like built libraries and talks around like how to practice discovery testing as its own school of TDD. So much so that I realized I give a lot of talks about it but I hadn't actually practiced it much.

‍

[00:29:56] And I was just full of hot air. So I felt like TDD, of course, it's not very well understood. A lot of us try it and fail or don't really learn how to apply it consistently. So there's stuff to say here, But I've just become a talking head at this point. And so I, I realized this last summer.

‍

[00:30:10] I was like, maybe I need to start practicing this more on my own and really proving out that it really works. I got to validate my ideas. So I had this simply safe alarm system. It's just a thing where, you know you stick it to the wall and then if a door opens and alarm goes off, police come to your house.

‍

[00:30:23] It's simple alarm monitoring. And I love Apple's home kit. Cause I really liked this idea of a smart home. Like we learned today, the internet of things, just Aside from denial of service attacks is also useful for just the convenience of controlling your domain. And so I have this server called Homebridge.

‍

[00:30:38] It runs Node. js and you can build adapters. So I was thinking, I'll build an adapter for SimpliSafe so that when I'm on my couch I can say, Hey Siri, turn on my alarm. So I, the idea being, of course, I would spend 40 hours building a thing to save myself 8 seconds the 3 or 4 times that I think to use the thing.

‍

[00:30:54] Cause programming, So the question was, what's this thing in the middle? How do I build an adapter? The truth is I had no idea how to build this, and that's purportedly what my practice of test driven development discovery testing does. So does my process actually work? And so I actually experimented, and several hours in, I was very relieved to find that I could build a thing, and that it actually worked.

‍

[00:31:11] And so there's, This NPM module now exists, simply safe, and it's got a simple little API, you pass it credentials, you get a client back, you can set the state. What was funny is I TDD'd this, right? So I was writing tests, and the only credentials I had were the ones to my house, and so I had to be really careful in the failure states, cause I was like, didn't want to send the cops to my house by accident.

‍

[00:31:28] And, in particular, this got really confusing with Travis, because then I would upload it to Travis, and like a continuous integration, and then people would send pull requests, and it would like, in my house and I have to make sure all the doors were shut.

‍

[00:31:43] But the lesson I learned there was like I'm follow, I got to follow my own advice and really practice it. I was relieved to see that it went well, but honestly I'm ashamed because I went so long without validating my ideas. And I, and you guys just by having me here today have given me a platform and I don't want to abuse it by just being a talking head.

‍

[00:31:58] I want to make sure that everything I share can potentially really help you grow in your career. So that was a valuable lesson and I think I, we can apply it. To managers, like technical managers, former developers. What I've been able to generalize from my experience, especially at TestDouble is like everything at a distance seems simpler.

‍

[00:32:16] The people actually doing the work when the developer says this is going to take several more weeks, they're closer to it. They see all the complexity, which is. Easy to just hand wave away when you're operating at a distance. Additionally, when you have a lot of experience, you tend to like, we're all pattern recognition machines and you feed in all these problems and somebody might feed you a problem and you might say yeah, that looks like the 15 other things that I did.

‍

[00:32:35] And you come up with this like round polished idealistic solution. But of course that's not going to actually map very closely to that individual's context. You have to trust the people closest to the work. And so that's been a humbling exercise in, in a manager role to not just jump to conclusions that I always know best.

‍

[00:32:50] But nonetheless, that was also helpful in me dealing with my own sense of inadequacy as I merge into this kind of more management role. Let's talk a little bit about indignation. For first of all, I'm a big worrier. Todd mentioned I'm really high anxiety. I worried about banks and credit card statements and financials and stuff.

‍

[00:33:07] And I really wanted just a dashboard to handle this all for me. And Mint was that for a long time. So I'd use Mint, I'd see all my finances were like, still there. And I feel good. But six years in, I had this random thought. I was like, you know what? I wonder how Mint is actually secure. Like, how does it actually securely go and get all these services?

‍

[00:33:22] And get all my account updates. And of course what I figured out was that it's just not secure. It has decryptable versions of all of your passwords to all of your banking stuff and doesn't support two factor auth or anything like that. And that's worrisome. It's actually a very popular internet cloud architecture right now called SPA FAS.

‍

[00:33:38] If you're not familiar with SPA FAS, it stands for a single point of failure as a service. Thing we're learning about today, too, with the internet outage. Mint, Yodlee, if they go away, then all of your stuff just disappears. You're just giving a single point of failure for them to take all your money.

‍

[00:33:50] And so I was stewing on this. I got angry. I was trying to figure out how do I get off Mint. I'm sure I can cancel it, but I want to replace it with something better. What could I build? So I thought, security matters. But I'm not an expert, I'm not going to build the next Mint or Yodlee and solve this very difficult distribution problem, but I could probably just build something for myself and at least personally feel a little bit safer.

‍

[00:34:09] And so I built this gem that I call Finance. And in finance, you build adapters. And so here's an adapter to Vanguard. I pass the credentials. And because I can run it locally, I can actually do two factor auth in my terminal. So I have two factor auth set up now. And it just downloads all my account holdings for all my Vanguard accounts.

‍

[00:34:26] And I built a little Rails app for it, too, that runs at localhost. And so it's encrypted on my disk. And it shows me all of my account holdings and I click that button and it launches the Selenium workers to go and to open browsers to go to all my banks and stuff. And I was really proud because now I have almost got this dashboard that I wanted.

‍

[00:34:43] It's locally encrypted, it's as safe as running it from my own browser. Put Selenium to good use for once instead of just like really brittle integration tests. And, admitting it's not a generalizable app. You can go and find this stuff on GitHub and clone it yourself and run it yourself, and I'd encourage you to try it.

‍

[00:34:58] But it's not gonna be the next unicorn billion dollar company. But honestly, there's no shame in hobby grade. A lot of times we're talking about creativity, right? We're talking about building stuff, and sometimes just solving your own problem is enough. These little toy apps like this are often what got us into programming in the first place.

‍

[00:35:14] Even if you're just solving your own problem, there's no shame in that. So that made me feel a little bit less furious at the world. Another example. So Test Double, our company, right? I've already referred, I used the term Test Double a few times, but some of you might not know it. That library, GIMME, is actually an example of a Test Double library.

‍

[00:35:32] If you don't know the term, the word Test Double is supposed to evoke the image of a stunt double, but not like a stunt driver, like in a plane stand in for your test. So assume you maybe your app depends on the cloud, and so you have to fake that out to make your test pass. Whatever you did to fake out the cloud is probably an example of a Test Double that fakes that service out.

‍

[00:35:49] And in JavaScript, the most popular testable library is called Sinon. But when I see people use Sinon, most of them don't understand it very well because it's confusing. A lot of people get frustrated because it's a huge API or just angry at the fact it's not very opinionated. And so I've given a lot of thought to making something better than Sinon in JavaScript.

‍

[00:36:08] And I decided, a lot of users that use Sinon are in pain. But I have to admit, I can't beat it. It's got 2 million downloads a month. But if I build something, at least I'll be less grouchy. And at least I'll have something to hand somebody instead of just more snark and whining. And so it was humbling, right?

‍

[00:36:24] Because I've built now, this is like a fourth or fifth testable library in a different language that I've built. And I keep coming back to the same saw over and over again. And I've, it's humbling to think that like my entire career may well hinge on just Two or three concepts, and I keep repeating them.

‍

[00:36:39] Because I learn, because I'm passionate about it, and then I build something, and I share it, and I feed back into learning more, and it's this infinite loop of me iterating over time on just a handful of issues. And with Test Double, we were able to do that again by building testdouble. js. You can install it on npm to get the npm install npm package testdouble.

‍

[00:36:58] It works on the front end and the back end. There's a screencast on our website called HappierTDD with testdouble. js that you can go watch. We've also got a comparison blog post of testdouble versus Sinon. And what was cool about testdouble is it works, but it most importantly shares all of our opinions of what we've learned about testdouble libraries and good isolation testing over the years.

‍

[00:37:18] And it's certainly better than just being cynical and snarky about, oh, JavaScript sucks, or JavaScript testing is this or that. A lesson I learned early on is that if your message isn't getting through to somebody and they're not hearing what you're trying to say, you can conclude one of two things.

‍

[00:37:32] You can either conclude that they're a bozo for not understanding you, or that there's something with how you're trying to communicate that's failing to convey to them. And if you conclude that they're a bozo, that's it. They're, they, you just disengage, right? There's no way, there's no next step. But I always assume that it's something wrong in how I'm trying to communicate.

‍

[00:37:50] And so I'm always iterating on my message and only as a very last possibility do I assume it's the listener's fault, because I can't control that at all. And then also, for your library to win, not everything else has to lose. Sometimes just doing something that's useful for a small group is plenty, especially if you're able to communicate ideas in a way that kind of moves other people forward in how they think about something.

‍

[00:38:09] And certainly criticism is easier than contribution. It's really easy to be snarky on Twitter and say something sucks but Christian Johansson who made SignOn, he put himself out there and it has served a lot of people really well. And he's a really nice guy. But, I spent two years just shittin on his work on Twitter before I thought maybe I should just build something that, that serves my needs instead.

‍

[00:38:29] Building that certainly made me a little less angry about JavaScript testing. Another thing you may have noticed is I like emoji. I don't I've used a few of them in the slides. And creativity, open source stuff can sometimes feel a little too self serious. And open source feels you create, we depend.

‍

[00:38:46] Other people start to pull your stuff, and then all of a sudden they're really demanding. And, it usually starts with just, you have an idea, you want to build a thing, and then it, it's a labor of love and it brings you joy. But then eventually companies start depending on it and criticizing or opening issues or acting entitled and trying to get stuff out of you for free.

‍

[00:39:03] And that's a big bummer. In fact, I know a lot of open source maintainers and what's super consistent is that they tend to hate their creations in proportion to how popular they are. And that's just seems totally backwards. So I was feeling exploited and exhausted at this particular point in my career, but I can't just escape open source.

‍

[00:39:22] I'm not going to rage quit, get hub and delete all my stuff and yank all my stuff and take it, take my ball and go home. So maybe if I just build something new, something fresh, I'll find a fresh start. And the way I did it was I decided I was going to build something that no business could ever want. To just be creative for the sake of creativity.

‍

[00:39:39] And sometimes even still, like if I build something that I worry, a business might exploit might build a business around and cut me out, I'll just license at GPL as if to troll them because then that way they have to come to me to obtain a commercial license. And this is such a project.

‍

[00:39:53] I think it is G gpl, it's called Emo Ruby. So there's not a lot of ERs for the ruby language, but this one es emo emoji into Ruby code. So here's an example. File listing of emo ruby. This is a class called Heart. I finding a method called Wave. Printing out a statement saying hello. Ending those two things.

‍

[00:40:11] And then, instantiating the Heart and calling Wave. And so this if you're not familiar with EmoRuby this translates to this ruby here. And it totally works, and it was a lot of fun. Yeah. TLDR, what I learned on EmoRuby is it's super dumb. It's just there for fun. It's just there to be joyful.

‍

[00:40:27] I actually got a lot of contributors on it because they found fun in just trying to map different keywords and control flow structures to what emoji should that be. But it brought me a lot of joy, and it's had zero issues opened against it this year. So it's one of my favorite projects.

‍

[00:40:40] It's okay to just build stuff for yourself. I know some of you are like developers here, and you're here with your managers, Hopefully they're not looking over your shoulder right now. It's actually okay just to build things for fun. The joy of programming is I think really undervalued when we get too self serious about our craft.

‍

[00:40:54] So that helped lessen my sense of indignation. Looking back on all this stuff is, I wouldn't recognize myself 10 years ago, I think, because all of this creative exercises really changed me as a person. I've actually found a way to mature and grow up. And. I see you there. I'm saying that Hey, look, creative stuff.

‍

[00:41:12] This is easy. But I've also just lambasted you with 12 years of side projects and look at me. This is the cool thing I built. I understand like that might make the bar feel higher. And you know what? Maybe you're right. Cause it's true. Creativity is not for everyone. Here's a quick litmus test.

‍

[00:41:25] If you're perfectly content and you're totally fulfilled and you're okay with the status quo, then why would you want to change things? You're right. Maybe you aren't a creative type. You should just enjoy the beach that you guys have not too far from here. But if you have any negative feelings at all, our culture right now, we tend to pathologize negative feelings as themselves being bad, but often they're just a symptom of some different root cause.

‍

[00:41:46] And if you analyze and you're open about that with yourself, you might find that what's really bothering you is you're using the wrong tool for the job, or there's friction between the technologies and the practices that you're using, or work can't offer you what you need, or maybe you just have your own internal baggage that you need to get over.

‍

[00:42:00] And creativity can be a great outlet for those kinds of root cause problems. If you reflect on how you feel. and you feed like you accept those emotions. What's funny is our asynchronous brain will just start spitting out ideas. And it'll be a big idea generator and hopefully you'll find a way to exercise it.

‍

[00:42:17] And when I tell you, like, when you feel confused, or when you feel down or upset or scared, all of those emotions are the place where all the good stuff comes from. They typically Great ideas don't come from people who've already got everything figured out. And when the bar is that low, you fling over it and hopefully wind up in a better place.

‍

[00:42:36] The important thing is you got to find your outlet and I don't know what that outlet is for everybody. In fact, it's important for me to mention that outlet might not have anything to do with software. Certainly. If my outlet for creativity wasn't software my wrist wouldn't hurt as much and I'd probably get more sun, I'd be in better shape.

‍

[00:42:53] So find what that outlet is for you. Cause it may or may not have anything to do with software. So tomorrow, I was here last year, and the day after SCNA was one of my favorite days last year, because I just sat on Manhattan Beach and watched football and drank Big Ten football from 9am to 3pm, which is something I can't do in the Eastern time zone.

‍

[00:43:09] So that was really cool. But tomorrow, we're going to have even more fun, because we're going to be here Todd my partner and I, we're going to join forces tomorrow and we're doing what we call a test smells, like a code smells workshop. It's a really fun, engaging thing where we all talk toge together about things about testing that we hate.

‍

[00:43:26] I hope that you'd come and join. And when what we do is Listen to stories, and then we've got this repository of 30 different types of problematic tests. Work through those examples and really bring a name to a lot of the different anti patterns that we find in tests. I hope that you'll join us.

‍

[00:43:39] It's a really fun exercise. And that's going to be happening coincident with the code retreat and what other activities we have tomorrow. So again, my name is AtSearls, or Justin, you can call me whatever you like. I hope you tell me on Twitter what you thought of this talk, any feedback you have.

‍

[00:43:54] Like I mentioned, we're here to fix this software industry, and to do that we're going to need creative people who want to creatively solve those problems and help inspire that in others. If you're interested in joining our team, I hope you'll contact us. And if know any teams that are looking for that slack, looking for some outside inspiration we're always looking for additional clients that we can work with.

‍

[00:44:13] You can reach us at hello at test double or find me or Todd tonight and tomorrow. We'd love to talk to you. Also got a lot of stickers and business cards we'd like to share. You've been super patient, like Todd mentioned, I'm the only thing standing between you and free drinks, and nobody got up and left, and so that's really humbling.

‍

[00:44:28] Thank you so much for your time today.

‍

‍

‍