NOEL:  Hello and welcome to Episode 24 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. After you listen to the episode, you can join the conversation. Follow us on Twitter at @Tech_Done_Right, where you can get notifications of new episodes and tell us what you think. You can leave comments on our website at TechDoneRight.io, where you can also see our full catalog of past episodes. We're really curious about what you like and don't like about the show and what you'd like to hear us discuss in future episodes so please let us know. Also, if you want to help other people find this show, leaving us a review on Apple Podcasts is a great way to do that. Thanks.

Avdi Grimm is the creator of the RubyTapas screencast series, which just celebrated its 5th Anniversary. Before that, he wrote a number of excellent technical books, including Exceptional Ruby and Confident Ruby. I wanted to talk to Avdi about how RubyTapas gets made and what helped him when he was trying to learn programming. We also talked about Avdi's rebuild of the RubyTapas website, which he did using off-the-shelf WordPress tools and why not writing code is sometimes the best decision of all. I really love it when I get a chance to talk to Avdi and I hope you enjoy our conversation. Here it is.

Avdi, welcome.

AVDI:  Thank you, Noel.

NOEL:  It's been five years for Tapas. What made you want to do it? What made you want to start doing that kind of screencast?

AVDI:  You know, a few different things. First off, I wanted freedom to set my own schedule. That was sort of what set me on the course of creating my own content in the first place but apart from just selfish needs like that, I felt like there was a niche for it. I felt like there were a lot of long form screencasts that were starting up back then or had been around for a while but I knew that sometimes, when I was watching long form screencasts, my focus would start to wander and I'd find myself revisiting them over and over again because of bits that I'd missed and I thought "wouldn't be cool, if there's a screencast out there that just taught you exactly one thing every time and nothing extra". If there was something else related, then it would teach you that in a different episode.

NOEL:  And then Tapas concept was born. Did you feel, when you started it, that you were going to be able to sustain it for five years? That you were going to have 500 different one-things to teach people about Ruby?

AVDI:  I know the usual line here is like, "I never imagined that it would go this far," but honestly, yeah. I kind of did. I didn't know exactly where it would go. When you kick something like this off, you just have to see what happens but I did sort of plan to make it sustainable. I made some choices to make it sustainable. I deliberately left my subject matter reasonably broad. It was like Ruby and Object-Oriented Design and testing and refactoring and Rails and all that stuff. I knew that I had a lot that I could talk about.

You know, the choice of very short format, the five-minute video format, it was partly because it was something that I really wanted to see out there but it was also because I was kind of zeroing in on what I knew I could do and what I could sustain and what I could continue to enjoy for a long time. Anyone who has created videos knows that it's like 10x the time of the video... It's probably more than 10x the length of the video itself. It's much more.

NOEL:  Yeah. Video content is so challenging to create. I've done a little bit. I've even done some guest episodes of RubyTapas and it's very surprisingly time-consuming, even most of the video in RubyTapas video is a screenshot. It's not like there's camera edits to make but it's still --

AVDI:  Yeah, there's a lot that goes into it. The majority of the time that goes into it at this point isn't even the video editing or the audio recording or any of that. It's the script writing. It's making sure that you have a good script, the code checks out and it makes sense and it's as clear as possible and it doesn't have any fluff and making sure that the script -- the narration -- is as clear as it can possibly be.

NOEL:  Do you script word for word?

AVDI:  Yes, I do.

NOEL:  How good is your sense of how long a topic is when you come up with it, when you think of, "This is going to be one episode. This is going to be a five-part series?"

AVDI:  It's still not great. There are some things that I know that it's just like one quick episode but there are many times when I've set out to create a quick one off episode about something I'm thinking about and I've realized partway through writing the script that what I have on my hands is, either I have a series on my hands or there are some tangents that I've been covering that I need to extract out into their own thing. Usually, what I'll do is I'll push off the original topic, push that down the road and I'll extract out the supporting tangents that you need to know first. I'll make sure those go out first and then I'll get to the original main point and I'll reference back if I need to.

NOEL:  What do you think makes a great RubyTapas example? Do you prefer the longer ones? Do you prefer the shorter ones? What are your favorite?

AVDI:  It's a good question. You know honestly, my own personal preference is the shorter ones. To me the ideal perfect episode that I'm going to create someday -- I haven't yet -- is going to be 30 seconds long. That's the ideal that I've been shooting for all this time. The truth is a lot of the most popular episodes are some of the longer ones. I say, five-minute episodes, a lot of them do go longer than five minutes, although I try to make sure that nothing ever hits the ten-minute mark. Some of the longer ones on more conceptual stuff on design thinking, have been some of the more popular ones over the years.

NOEL:  Yeah. I think as a consumer of it, they scratch different itches. Sometimes, those two-minute episodes, you hit the right Ruby method or little trick that I didn't even know existed and suddenly, I'm noticeably better at what I'm doing because there's tiny little thing that I didn't know I could do. Then the longer ones give the opportunity to see something in a little bit more of a context, which I think is often missing from short episodes. 

As somebody who spends a lot of time trying to figure out how to teach developers, you have this problem where short things are really cool but have no context that then people don't know how to apply them but as soon as you try to bring in enough context that people know how to apply them, you get buried in extraneous detail. I think you doing a really good job of threading that needle.

AVDI:  I feel like I'm pretty far at that one end of that continuum. For the most part, I rejected context and I tried to narrow things down as much as I can. I try to include the minimal amount of context necessary to understand what's going on. I do really hate totally out of context media, like in defining the problem, they just throw a bunch of jargon at you that they assume that you understand. I am very careful with editing to make sure that I'm setting the stage but I try to be very careful with setting the minimal stage necessary. That reminds me of a recent episode of yours.

NOEL:  A recent episode of mine?

AVDI:  Yeah. I was talking about minimal stage setting and you're talking about --
NOEL:  Oh, we're talking about Betsy. Yeah. I think this is one of the things that you do really well on RubyTapas that I think it's really hard. Especially, the shorter episodes where you have a very, very brief minimal example that foregrounds the thing that you're trying to teach without getting buried in extraneous detail. You do that really well. It's very hard.

AVDI:  Well, thank you.

NOEL:  I'm currently working on the book about Rails testing and there's a tremendous amount of incidental Rails detail that you either have to bring in or people can't find. I think about some of the really focused pieces of RubyTapas, how do you go about trying to create an example for a topic. Is there's a recent episode that you want to talk through that you have a process for?

AVDI:  I'll say this. My examples come from a few different sources. There are some that I do that are just taken directly from actual events, either some code that I worked on or some code that I worked with somebody else on. What I'll do there is I'll go through very carefully and if it's something that I actually worked on, I'll go through and see how much I can strip out. Just go over the lines of code and figure out what's here that is useful as a sort of a signpost of orientation and then strip out everything else.

NOEL:  You definitely used stripped down versions of the Tapas site, for example.

AVDI:  Right. I've got one I did recently that was actually from a really old experience of mine. Episode 490 was on crash logging in Ruby. I wanted to demonstrate the idea of crash logging but I didn't really want to talk about here all of the different things that you might want to log in your crash logs so I just had a very simple example of logging, like the error in the current environment. Once you understand the trick of crash logging and how to capture an exception that's sailing up and out of the program uncaught, you can figure out for your own application what makes sense there but that was definitely a case of cutting out all the stuff that was actually logging in production because that wasn't the point of the episode. The point is how do you do this.

But then there are other episodes where quite honestly, there is something that I want to talk about but I don't have a recent example of using it. In those cases, I'll usually try to find something that is an example that's universally identifiable. I've had some episodes recently that use a shopping list example and I've been using it for things like demonstrating how Ruby duplicates objects and how the duplications are shallow and what we can do about that and how to freeze and unfreeze objects.

The shopping list example is something that's fairly concrete and you can see it. I think most people can see it and instantly understand what's going on here, instantly understand the domain. I don't have to get you up to speed on the domain. What I really try to avoid are foobar kind of examples, where you don't really know what kind of domain we're talking about. With a shopping list, you can instantly identify, A, I understand this domain and B, I see that it's tangential to the actual technique being shown. It's just a foil for the example.

NOEL:  Right, it doesn't matter what's in the shopping cart. It can just be like widgets.

AVDI:  Right.

NOEL:  There's a reason why all the JavaScript frameworks used to do list as they're canonical how-to. It's easy and everybody understands it right off the bat.

AVDI:  Yeah.

NOEL:  Do you ever think about how future proof an episode is? Do you worry about something that is going to be obliterated by a future version or is going to be more timeless? How often do people go back to early parts of the Tapas catalogue?

AVDI:  I'm very pleased to have a catalogue that I think is almost entirely future proof. Okay, let me qualify that. As long as people are using Ruby, then I think it will have some currency, most of it. I don't often cover stuff that is very of the moment and part of that is just again, my choices about what I'm going to cover, what I'm comfortable covering, what I enjoy covering. I don't actually cover a lot of very specific Rails techniques. I kind of leave that to other screencasts. There are a lot of other folks out there are doing great work for Rails, specifically so I don't really cover a lot of that. I do a lot more general stuff. If I cover a gem, I will usually try to pick something that's been around for a while, that other people are using. It's not something that just came off the assembly line. Occasionally, I do episodes about new features in Ruby. As long as the features stay in Ruby, those are still fine.

NOEL:  I was actually just interviewing a self-taught developer who was using old RailsCasts episodes, which there are probably at this point, three or four or five years old and a lot of them still hold up. Once it's out there, there's always benefit.

AVDI:  Yeah. I think the people that are doing media on 

NOEL: JavaScript

AVDI: faster-moving targets, I don't envy them and I think they're doing great work. I have been kind of lazy in my choices of what to cover in that. I deliberately choose stuff that I know I'm not going to have to go and update in a year.

NOEL:  Yeah, if you're doing some sort of regular like React or JavaScript screencast, I would imagine that would fossilize pretty quickly.

AVDI:  Yeah.

NOEL:  What kind of stuff did you find particularly beneficial when you were learning to be a developer? Were there things that you felt you've learned a lot from or that inspired you to be a better developer and then become a developer-educator?

AVDI:  Thinking back, when I was first getting into development, everything was terrible. There isn't a lot that I can think of, as far as books and other media that I look back fondly on from my very first days of learning to be a developer. Some of the things that standout though was picking up the Camel Book for the first time which is the classic book on Perl. Then it was sort of a revelation to me because it was the first fun programming book that I ever read.

NOEL:  Yeah, it had a personality. It had a point of view. I was never a huge Perl programmer but that book sold Perl hard and made it seem fun.

AVDI:  Then I read the book, The Pragmatic Programmer, I guess in around 2001 when it came out. That was a big deal for me as well because again, you had a book with a decent personality and it wasn't snooty, it didn't seem like it came from an ivory tower like a lot of the stuff that was around the shelves that where I worked. It was very pragmatic. There was a lot of stuff in there that kind of went against the orthodoxies of the time. That got me into that whole community. There was an email list around that at the time of people that were applying the thinking from that book. Another of the early things that I really turned to a lot, really learned a lot from was wikiwiki, Ward Cunningham's original wiki, the wiki that created wikis and I spent just hours and hours going over that site and reading the various postings from people about software design ideas.

NOEL:  Yeah, Kent Beck and Ward Cunningham and all the people that were on there, that eventually morphed into the original XP. I spent some time on there too. I was a grad student at a time but our research group was researching wikis as educational tools. I spent a fair amount of time looking at that site. 

One of the first things I remember that really hit me was Code Complete, which I read in a panic. After finishing undergrad and about to go to grad school, having gone from a liberal arts undergrad to a very technical grad school, I was petrified that I actually really didn't know how to program.

Code Complete, more so than anything else, there's all sorts of things that I do on a day-to-day basis that can get traced back to advice from that book, 25 years ago because it was very nuts and bolts in a way that there are very few programming books that really talk about when do you use an 'if' statement, how do you lay out loops, when do you create a new method -- it wasn't an object-oriented -- when do you create a new function. It claimed to be data-backed. Even though I probably disagree with some of the things that he said now, that book had a huge impact on me.

AVDI:  Yeah. That book introduced me to the concept of code construction, which was I think was his term for the decisions you make at the nitty-gritty level of line by line and method by method. That was actually a big inspiration for me when I wrote Confident Ruby. Inspirationally, it was between Code Complete and Kent Beck's Smalltalk Best Practice Patterns.

NOEL:  Right because that's the other book that talks about nitty-gritty line by line stuff because there are surprisingly few, given that those are the decisions that people make all the time. That other book is Kent Beck's Smalltalk Best Practice Patterns, which comes at it from a very different angle but is very, very much about the things that you do line by line and patterns of creating constructor methods and creating accessor methods and using blocks. Even though, it's in Smalltalk, it's still probably one of the five best Ruby books.

AVDI:  Yes, absolutely. That's one of those books that I wish more people would read.

NOEL:  Yeah, and Confident Ruby has a lot of that. I actually remember seeing you do the Confident Ruby talk. It was actually a day that I remember a lot of things about but that was in Kansas City at Ruby Midwest and I remember having a very strong, very similar reaction to it that was like, "This is a really, really, really good advice about doing day to day stuff in Ruby," and, "Programming should be about joy," that was what you said. I was like, "I remember joy. That's right. Programming should be about joy." I actually think about that a lot. In Confident Ruby, there's a whole point of view about how code should be constructed that --

AVDI:  You should tell a story.

NOEL:  -- I think about a lot. In the code, yes. I thought you meant I should tell a story...

AVDI:  But yeah, code should tell us a story. You should tell a coherent narrative.

NOEL:  No, I have a story about that conference because that's the one where Uncle Bob Martin gave the Hexagonal Rails talk and started off by criticizing everybody that had spoken earlier, including both of us, I think.

AVDI:  I have apparently blocked the memory of being criticized. I don't want to unblock that one.

NOEL:  I think he criticized the Rogues' panel in general.

AVDI:  Oh, yeah.

NOEL:  It's great. It's fun. Is there a programming book that you've read recently or a content that you learn from now? What do you do to learn new things now?

AVDI:  My learning focus for the past couple of years has not been so much on programming directly. The Pragmatic Programmers famously said, "You should learn a new programming language every year," and I think that's great advice but as I've gotten older and gone further with having my own business, I've started to interpret it more liberally. I'll consider marketing a new programming language and dive into that. A lot of the stuff that I've studied more recently has not been new programming languages. For me, that would be almost something to do for fun. I'd love to spend more time learning programming languages but I've realized that that's actually not the most high leverage thing that I can do with my time these days. I learned a lot of things of late but a lot of it has to do more with marketing and business strategy and copywriting and stuff like that.

NOEL:  How do you approach that? What are the resources in those areas? Do books work? Do you needed actually what's out there?

AVDI:  There's so much out there. Once you dive in, you realized that the default for making money online is tell how other people how to make money online. There's a lot out there.

NOEL:  In the Gold Rush, the people who made money were the people who sold pick axes.

AVDI:  Exactly and it's hard for me to, off the top of my head, list resources but I will say that when it comes to marketing some kind of product or media online, the key word is content marketing. The positive spin on it is it's the modern practice of actually making yourself useful to people before they buy stuff from you, rather than just plastering the web with ads. There's a lot of information out there about content marketing. The site that has been talking about this for the longest time and has some of the best resources is Copyblogger. You can go there and get a lot of 101 stuff. Also, start to pick up on who are some of the people out there that are good resources because usually, they've written something there or had a guest post there or something like that, then you can start to branch out from there.

NOEL:  Do you find it hard, coming from a programming background to measure your success in things like marketing and business strategy? I say this because I think, I do. When I'm learning a programming language or programming technique, I can see the results of that in a concrete way and I find that kind of frustrating when I'm trying to learn how to market a podcast, just to throw an example at a random. Do you feel that?

AVDI:  Well, yes and no. I do because I'm not doing the things that I should be. The thing is measuring your success for online marketing is stupidly easy, compared to measuring other things. It's really hard to measure the goodness of a program in terms of code quality because there are so many possible metrics we could apply to that. But there is basically one metric for marketing and it's online and it's conversions. It's actually who sees your stuff out there somewhere and eventually, sort of follows the trail of bread crumbs and clicks on a 'Buy Now' button. My problem is that I'm lazy and I often don't set up the analytics that I really should be. But in theory, you actually can measure this stuff. You can set up AB tests and stuff like that and see what you're doing that's working. Now, I do think that that's probably not the only metric that matters because I also want to know how many people am I pissing off with the way I'm marketing and I try to keep that as near zero as possible. I don't want to just optimize for nothing but conversions.

NOEL:  I have self-published stuff. The podcast doesn't actually have conversions in the same way and I have literally no idea how to market this, which is I think, clear but I think that one of the things that is always hard for me is that first step of asking for money, for something. How do you dealt with that? Does that make sense?

AVDI:  Yeah, it's a gradual process of getting comfortable with that, I think. When I was first selling stuff online, I had a lot of people telling me that I was drastically underpricing my stuff and I think a lot of that was what I was comfortable with doing. Looking at some of the higher price points and thinking, I couldn't possibly ask for that much money. At some point, especially when you're in this particular niche, which is selling information products to professionals, professionals whose time is very valuable, you have to realize that if the thing that they learn from your video or from your book saves them a day of work, then that might have saved several hundred dollars or more. If it saves a team a day of work, you're talking about saving thousands of dollars. You've got to realize that if you have something of value to offer, if you have something that they can actually apply and save time or effort or frustration, then that really is worth a lot of money.

NOEL:  Yeah. This is a discussion that I had with a lot of people who self-publish stuff because I also have always habitually sort of underprice the things that I self-published and I've had people tell me that they take it less seriously because it's cheap.

AVDI:  That is absolutely a thing.

NOEL:  Which is in some ways, it's so disheartening. I always like the way that you went of doing it for yourself over stuff where you have a price point and then you had a higher price point that was basically like the perk of this is, is that you give me more money.

AVDI:  I did that with one product. I did that with Objects on Rails.

NOEL:  I remember but then, you also have the postcard, like loophole which I think is an important part because I think that there are people who are in situations where the price point becomes an issue so having a way that they can pay in time, rather than in money becomes a valuable part of building a community, I think around it.

AVDI:  I feel like I should explain that. Explicitly for Confident Ruby but really for most of the stuff I do, I have a policy that if somebody wants to write me a postcard, a physical mail postcard and put it in the mail, I will send them a copy of it. Honestly, part of what that came from was realizing that there are people that are in circumstances where they can't afford it or people that are just in countries where the exchange rate is terrible and US$35 might be just some ridiculously unattainable expense or there are lots of fees they get slapped on to online purchases or whatever.

I thought about what would it take to offer separate pricing for different regions and just pounded my head against the wall at the very thought of dealing with that. Part of it is I really like making it possible for people in any circumstance and part of it is just laziness because if I'm going to do that, I don't want to have to do it in a complicated way and the easy way is send me a postcard and I'll send you a copy. Wonderful thing about this is I have this just box full of postcards that I'm going to replace soon because it's getting too small for all the postcards. They're from all over the world, they're beautiful and some of them are hand drawn and they have the most wonderful things written on the backs of them and that's priceless.

NOEL:  Yeah. You recently came back to conference speaking for the first time in a while with a talk about no code.

AVDI:  Yes, avoiding code.

NOEL:  In what context should we be avoiding code?

AVDI:  Any context where the code that you're writing does not give you a lot of leverage on the problem that you're actually trying to solve.

NOEL:  So for example?

AVDI:  My favorite example comes from my own experience, which is the RubyTapas site, which when I first kicked it off, I went with a hosted service because I needed to get it up and running fast but the hosted service didn't really have a lot of features. All along, I knew that eventually, I wanted to replace it with something that was more flexible to supply all of the features that I wanted to give people and that people were asking for.

For years, I worked in the background on a replacement for it. Every time I would get a day or two free, I would spend some time coding up some more features on this RubyTapas 2.0 codebase that I was going to roll out someday. It went really, really slowly. I realized that there were a lot of things that I needed to handle, beyond just handling subscriptions which is a huge topic in its own right because I promise you, just like slapping on Stripe subscriptions, that is not a drop-in solution. There is so much you have to handle.

NOEL:  And Stripe subscription is better than some of the other ones and there's still a ton of your own custom logic that you need to throw about that.

AVDI:  But then, you throw on top of that all kinds of content delivery, the streaming and the downloads and the making sure that the right people can see the right things and having a nice way to present the episode scripts and any other attachments and categorization and really good search and RSS feeds and some handling corporate accounts and handling discounts and special events and blah, blah, blah, and forums. Eventually, I realized that if I really decided to do this, it could easily become a full time job, just writing this content delivery system and the result of that would be that 'RubyTapas the show' would probably just become all about writing 'RubyTapas the website' because that's all I'd be thinking about all the time.

That's not the show that I wanted to deliver. I had to take a step back and think what is the actual change that I want to affect in the world with this. The answer to that is I want to make Ruby programmers better at what they do, not better at writing what 'RubyTapas the website.' I did some rethinking and eventually came up with a new rule for myself, which is I will not write a single line of code to deliver this content.

NOEL:  What did you do?

AVDI:  I turned to something when I had some experience from in the past, which is WordPress and I rebuilt the site based on WordPress and selection of premium plugins, which handle things like subscriptions and making sure the right people can see the right content and RSS feeds and sending out emails when content is updated and forums and all of that stuff.

NOEL:  What's the general lesson here? How do you apply that to somebody in a different developer position?

AVDI:  The general lesson is you've got to maintain your perspective and you've got to stay aware of what is the change that you're trying to affect in the world. There is going to be some code, probably, maybe. There's going to be some code, which is at the core of affecting that change. Then there's going to be a lot of other code, which is peripheral to that. That's about like sending people emails and other peripheral concerns. You also have to be aware of what services are out there, what software is out there. But a lot of it though is just and a lot of what I was talking about in that talk is mindset and attitude because I feel like a lot of what gets in the way of avoiding code, which really didn't need to be written in the first place, is just our attitude.

NOEL:  There's a couple things: attitude, first of all that like, "I'm a developer so I need to write my site?"

AVDI:  Exactly. That's part of it.

NOEL:  Or the attitude that your problem is a special problem and that the existing tools aren't going to cover it?

AVDI:  There's this idea that you're supposed to eat your own dog food, which means you should use the software that you write but that doesn't mean you have to write all of the software that you use.

NOEL:  Yeah, I think at this point, there are a lot of people who've worked on a lot of hard problems, especially things that have very specific domain knowledge like dealing with money. A lot of the things that you've talked about, there are entire companies in their own right that set up these kinds of things. It's kind of crazy to think that your individual person or your small team is going to be able to create more value than those existing.

AVDI:  Yeah, then the other attitude that you brought up about feeling like our problem is special is another big problem with avoiding code because, I think a big problem that programmers have is they get very precious about their solutions or about their problems. We feel like, "This problem is special. It is a unique snowflake. The workflow that we need to solve it looks exactly like this." Or, "The file formats we need to use are exactly these," or whatever. There's always some very special, very precious requirement that writes off whatever off-the-shelf solutions are out there.

NOEL:  Right and maybe the better way to approach it is to try and isolate the specific stuff from the common stuff.  

AVDI:  Yeah and also be flexible. A lot of times, it turns out that the off-the-shelf software works in a different way because they've been working on that problem longer than you have and you don't realize the issues with the workflow that you think is the right one.

NOEL:  Right and there's a lot of areas like... in publishing, people come in and they're trying to solve... publishing as a business, has notorious inefficiencies if you look at it from the outside but they're all there for a reason. If you come in from the outside and think you're going to fix it, you're going to just spin in circles. I think similarly, if you come to a problem and think that you have an easier way to do it than the people that have been doing it for a long time, you might be right. It's not unheard of that people really do improve these long-standing processes but there's also a really good chance that there's a lot of complexity that you don't even see, that existing tools are already set up to handle.

AVDI:  As programmers, I think one of the things that we get precious about is not repeating ourselves and not repeating data. One of the things that I see a lot is like, "We can't use this off-the-shelf solution because that would mean duplicating some of our data." I think that's something that we have to just be a little bit more flexible on because the gains of using something that is off-the-shelf often outweigh the losses of duplicating some data here and there. Also, it often turns out that it isn't real duplication. There's true duplications and then there's incidental duplication, which is when something appears similar in form but actually, it varies at a different rate on one side of the divide than it does on the other.

NOEL:  For example, it may seem like you're duplicating information with, for example Stripe but Stripe is holding that information for different purposes, it's going to change it for different reasons and do different things with it so they might optimize in a different way or have access in a different way and that's perfectly fine.

AVDI:  One of the things that a lot of apps spend a lot of time on code-wise is sending emails to people. I worked with someone recently on a problem that was basically, making it possible to unsubscribe from the emails that the app was sending to people. This is a solved problem. You can send your emails through something like SparkPost or any of a dozen other email hosts and they will supply the unsubscribe link and they will make sure that people get unsubscribed. If your app tells them to send this email to somebody who has clicked on subscribe, it just won't go out. That's a start towards not writing so much code.

But usually when you go that far, you still have background jobs that are sending out emails. They're just using an API, instead of doing it directly with SMTP or something. The issue there is you're still dealing with background jobs for one thing and who enjoys debugging background jobs. But also, if your marketing department has a new engagement email that they'd like to try out, they have to come to you and say, "Can we get a new mailing set up?" The developers are the bottleneck for that.

There's this next step you can take, where services like Drip, you can actually push a ton of your metadata over to their side. You can associate various bits of metadata and update the metadata associated with an email address like what product is this person bought or what buttons have they pushed or what point are they in completing their profile or something like that. You can push that over and then your marketing people can just set up mailings in Drip that trigger on different events or have all kinds of interesting automations around them and they don't have to come to you anymore. You can just make sure that the right information is getting pushed over there and your marketing people, they don't have to come begging for a new background job to send a new set of emails or new logic to decide when to send those emails, they can just do it.

NOEL:  Right. What we're doing here is you're giving your small team more leverage by taking advantage of larger teams that have done other work around the world. If you're a small development team -- I spend a lot of time on small development teams -- being able to be clear eyed about what the value that your team is there to provide and what the value that other people can provide better, that's super important in delivering a complicated project.

AVDI:  Yeah. Part of it is just staying educated about what's out there now. I heard from someone recently who talked about how they had implemented their own feature flipper. It seemed like this is a trivial thing to do -- originally -- and they've discovered that the feature flipper itself isn't a code that's delivering value to the customer. It's code that's enabling them to switch features on and off as they develop them but that feature flipper itself has sucked down a significant amount of development time.

What they realized in retrospect is there are feature flippers, as a service out there where you just do a little tiny bit of integration into your code and you let the service handle what are the conditions for a user seeing this feature or not. They realized that they would have saved a whole lot of development effort by using one of those. Now, feature flippers as a service is not a thing that has been around forever. That's still relatively new so you have to keep your head up and see what is becoming commoditized now that wasn't commoditized before.

NOEL:  Yeah. Our teams have just started using a tool that does gem upgrades as a service. It scans your Gemfile, looks to see if there's an upgrade, it notices a pull request and it creates a pull request and then throws a pull request into your GitHub repo automatically overnight. That's a thing that is like --

AVDI:  That's awesome.

NOEL:  Yeah, it's relatively new. It's not exactly no code but it's definitely time being automated outsourced to a team that spent more time thinking about the complexities of it than you have. 

I think one of the things that I takeaway from this is that, there's a really good chance if you're doing some complicated business problem, that somebody else has tried to do it with more resources than you have and the fruits of that labor might be available to you. Then again, this doesn't mean like you never do any work. It means that you need to be sort of clear headed about what the best use of your energy is and wheels are everywhere.

AVDI:  Exactly. I do want to clearly disambiguate this from the idea of writing the simplest thing that could work or minimizing the number of lines of code you write to do something. That's something we can talk about. There's value in that but I'm really more interested in the choice to write that first line of code or not, in order to implement a feature because once you write that first line of code, it's the seed around which a whole lot of future work can agglomerate -- I think that's a word.

NOEL:  Sure.

AVDI:  It might not look like a lot now but just like that feature flipper, they discover that their feature flipper itself needed more and more features over time and had bugs that needed to be fixed. That choice to write the first line of something that is peripheral to what your purpose is, it's a big decision because usually, that's the beginning of a long sunk-cost fallacy where you're like, "We've already got this system in-house. There's no reason for us to turn to off-the-shelf software for this."

NOEL:  I have spent projects where clients came to us because off-the-shelf software was not doing what they wanted but they started with the off-the-shelf software. That is, in some ways an easier path to go on and then you come out of that with an understanding of we had this off-the-shelf solution and it actually didn't do these things that we really needed, which is probably a better place to start than to start trying to build the stuff that's already common. 

Avdi, where can people find you online?

AVDI:  They can find me at my new site that I'm still kind of putting together, which is Avdi.codes. They can find RubyTapas at RubyTapas.com. They can find me on Twitter at @Avdi.

NOEL:  Great. Thanks for being on the show. It's been great to get a chance to talk to you, Avdi. I'm really glad we got a chance to do this and thanks.

AVDI:  Noel, thanks so much for having me on.

NOEL:  Tech Done Right is a production of Table XI and it's hosted by me, Noel Rappin. I'm at @NoelRap on Twitter and Table XI is at @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. Please send us feedback or ideas on Twitter at @Tech_Done_Right.

Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to story brands. Find us at TableXI.com where you can learn more about working with us or working for us and we still have jobs open on our website, even as I record this. We'll be back in a couple of weeks with the next episode of Tech Done Right.