Episode 001: Taking Payments on the Web with Noel Rappin

Panelists: 

Coraline Ada EhmkeJessica KerrSam Livingston-GrayJay BoboDavid Brady

Guest Starring: Noel Rappin
Noel Rappin Writes Here
Table XI

Show Notes:

00:18 – Welcome to “Dread Coder Roberts!” …we mean, “Greater Than Code!”
01:30 – Noel Rappin’s Introduction (Spoiler alert! He’s got a Ph.D.!)
04:31Take My Money: Accepting Payments on the Web
08:30 – Code Paths and Tracking Failures

We are (currently) listener supported! Support us via Patreon!

10:59 – What is the quickest path to accepting payments online? Are there drawbacks to getting something up fast? (~ David Bock)
13:17 – Testing Payment Issues
14:29 – Design Patterns and Missing Layers Between Controllers and Models
17:49 – Business Logic and Database Constraints (aka, “Why did he write the book?!”)
20:14 – I Was A Developer Running HR For A Year: AMA by Noel Rappin at Madison+ Ruby: Epilogue 2016
24:02 – Practices, Problems, and Potential Solutions for Human Resources
29:34 – Team Diversity and Inclusion

Listener Call to Action: Team retrospectives and
demonstrating that it is safe to fail.

Takeaways:

Noel: The impact of our applications and how they work in real-world context.

David: How can we help introverts feel comfortable?

Quiet: The Power of Introverts in a World That Can’t Stop Talking
by Susan Cain

Coraline: Inspiration to look at teams, meetings, and discussions and see if they are leaving room for everyone to participate equally.

Jessica: We started out talking about accepting payments on the web and we found something greater than code.

Jay: If we want to try to work with the hard stuff, the hardest problems to solve are the things that are greater than code.

Sam: Being, as Jay said, “not just allies, but accomplices.”

Transcript:

CORALINE:  Are we ready?

[Intro music]

CORALINE:  Hello and welcome to Episode 1 of Dread Coder Roberts! I am Coraline Ada Ehmke and I am so excited to be with you today.

JESSICA:  Coraline, that is not the name of the show.

CORALINE:  What?

JESSICA:  Dread Coder Roberts is an awesome name, but you know it’s even greater than that! Greater Than Code!

CORALINE:  If you say so.

JESSICA:  [Laughs]

DAVID:  And no one on the podcast can see all of this cheering and waving our hands on camera. I love it.

JESSICA:  I’m @jessitron and I’m super excited to be on Greater Than Code today. And with us, we also have our new panelist – oh wait, we’re all new panelists, Jay Bobo from Columbus, who was better than David everything.

JAY:  Oh, wow! Yeah, hi! This is Jay and I am having a great time hanging out with some amazing people. I’m handing it off to Sam Livingston-Gray.

SAM:  Thank you, Jay. I would also like to point out that Greater Than Code is also cheaper than therapy. And speaking of therapy, let me introduce David Brady.

DAVID:  Good morning, everybody or afternoon or evening, wherever you may be. I don’t have anything ready to say which is – I’m trying out a new thing and we’ll just see how it works. Probably, I won’t carry them to episode 2. 

CORALINE:  Speaking of therapy, yes.

DAVID:  I should probably just introduce our guest, shall I? Today, we’ve got Noel Rappin on the call and I actually wrote a thing for him, which is: Noel Rappin has written five technical books including Rails 4 Test Prescriptions and the awesomely named Master Space and Time with JavaScript. He’s been through the web technology room on Obtiva and Groupon and currently works as the Director of Development at Table XI. His blog, responsibly called Noel Rappin Writes Here is at NoelRappin.com. His current book is called Take My Money: Accepting Payments on the Web. And he’s here to talk to us about that today.

But before we talk about that, we need to address this shifty business of Noel holding a PhD in Educational Technology from Georgia Tech and not telling anybody. So Dr. Rappin, what’s all of this then?

NOEL:  I do have a PhD from Georgia Tech, it’s in Educational Technology and User Experience and it was back in the day when Newtons were a cool idea and professors were doing research on what you would do if everybody had a Newton which back in the day they called –

JESSICA:  Newton like the unit of measure?

NOEL:  No, like the Apple Newton.

CORALINE:  Oh my God! Those were so amazing. My boss had one back in the 90’s. It was so cool.

NOEL:  Not the professor I was working with but there was somebody there at the time who was doing research on what would happen if everybody around you had a Newton which back in that day they called ubiquitous computing and now we call ‘life’.

JESSICA:  They’re not like the big Newton.

NOEL:  No. It has been a long time ago, I did research [inaudible] teaching Chemical Engineers how to design pipe systems and research [inaudible] teaching Object-Oriented Programming to developers. And now, I only use the title sarcastically. So if somebody calls me an idiot, I’ll say, “That is Doctor Idiot to you.”

JESSICA:  [Laughs]

DAVID:  Nice.

CORALINE:  Nice.

SAM:  Nice.

DAVID:  Have you ever said, “It’s Dr. Rappin if you’re nasty.”

NOEL:  No.

[Laughter]

CORALINE:  I like the new Dave. This is cool. [Laughs]

DAVID:  [Laughs]

CORALINE:  Noel, I want to point out an episode from our past which I hope is funny at this point in time. I once had the privilege of interviewing you for a job that you didn’t get. Do you remember that?

NOEL:  Yes, it is all true.

CORALINE:  Working for a Chicago startup and the reason that you did not get hired is that you didn’t do open source work regardless of your contributions in the form of your writing in your blog post and all the [inaudible], you didn’t have an open source portfolio in GitHub and that was like a red flag for people.

NOEL:  I did not actually know that was the reason why.

CORALINE:  Yes. [Chuckles]

NOEL:  I just assumed you didn’t like me.

CORALINE:  Ohhh, I loved you. I love you, Noel. 

NOEL:  Yes. You know what’s actually funny about that is that my GitHub portfolio is even worse than that because especially then, not only do I not have open source contributions, but I also have deliberately terrible code that I use as workshop examples up there. So, my GitHub portfolio is actually a negative indicator of my programming skill.

CORALINE:  That’s a great example of why you should not use GitHub as your resume. That’s like so problematic on so many levels.

SAM:  I feel like we should do a show on that.

CORALINE:  I like that idea.

JAY:  If only I knew people who work at GitHub.

CORALINE:  I just passed the 6-month mark. I’m so excited.

JESSICA:  Wow! Has it been six months already?

CORALINE:  Yeah.

SAM:  Wow!

CORALINE:  So Noel, about this new book. I understand it has a little bit to do with eCommerce, kind of like touches on that.

NOEL:  Yeah, I have a new book out. It’s currently on beta from pragmatic. It will be probably physically published in February but you can get it now in beta. It is called ‘Take My Money:  Accepting Payments on the Web’. It’s about accepting payments. It’s about the kind of applications that you write that use things like the Stripe API to take in credit cards and payments like that. And it’s also about all of the things that you need to do in your application beyond calling the Stripe API in order to manage money. So, how to manage money as data, how to manage transactions as workflows, how to deal with failures, how to deal with administration, reporting, all the things that take you from ‘yes, I can make a Stripe API call’ to ‘I have a robust application that can take in a fair amount of transactions without falling over’.

SAM:  That sounds very cool. I just have to derail this for a moment though, and just say that title is a total letdown. We go from mastering space in timeless JavaScript to allowing people to give you small and lots of cash.

[Laughter]

JESSICA:  Nobody said they had to be small amounts.

SAM:  Yeah, but where do you go from there, though?

NOEL:  Time is money, Sam. Time is money. I was actually really surprised that they let me keep ‘Take My Money’ as the title. I actually submitted ‘Shut Up and Take My Money’.

[Laughter]

NOEL:  But somewhere along the way, that had been taken off. ‘Master Space and Time’ is named that way because I self-published it and I wanted to come up with the least tech publisher name I can think of. I didn’t want it to sound like Pragmatic JavaScript or something like that. So, I came up with a name that is very memorable but kind of long and unwieldy.

CORALINE:  Does that mean that for my book, it’s not like I’m going to be able to get the title ‘Be a Compassionate Coder, You Fuck’.

[Laughter]

JESSICA:  [Inaudible] not taken?

NOEL:  Oh no. I would check the domain registrations and see if that domain’s available.

CORALINE:  I’m on it.

NOEL:  Anyway, what happened to me was that I actually started doing an application like this that had serious business logic around authorization gateway API and I actually inherited it with the API called [inaudible] and I thought that the hard work was done because it was there. I quickly realized that that was very naïve and started to run up against some of these issues of ‘how do you protect against database failure after you’ve charged the credit card invalidating the transaction on your end’ which is mildly terrifying because you’re charging your user for something that you then potentially have no record of. And what I found was it was really hard to get really good information on what other people were doing to mitigate this to the point where I kind of at one point sort of doubted whether I was even seeing a real problem and kind of wondered whether I was just not understanding how easy this was. But eventually, decided that it actually was hard and there was just nobody who is telling good stories about how to do it the right way. And eventually I realized that I had enough stories like this and enough people that I talk to who’d done some more things that was worth putting it all in a book form.

JESSICA:  It’s fascinating that you thought it would be easy because you were already able to take people’s money in that application. You already had the payment and integration. But it turns out that the hard part is everything that can go wrong. I love that the book focuses on that, that it introduces the happy path and then Chapter 5, “Bam! But this is the real world!”

NOEL:  Dealing with failure. The long term difference in how well this stuff is going to hold up has to do with beyond sort of the normal coding requirements of whether it’s good code or not. The ways in which an application like this lives and dies are how well it deals with failure and how well it deals with administration.

I had a really great opportunity to interview Dave Thomas about the Pragmatic Bookstore as part of this, and I think he said that their administrative code is twice the size of their user facing code and I absolutely believed that. Administrators make the stuff really complicated because they basically live to mess with business logic. Pretty much anytime they’re making a change, they’re changing existing business logic, they’re changing a price, they’re changing a sale, and you need to be able to sort of validate that you have a [inaudible] data set even after the administrators do whatever they will. 

JESSICA:  This [inaudible] our code paths in the administration because the administrators need to do [inaudible] more different things than the users. And the same with failures, there is tons more different failures than happy paths.

NOEL:  Yes. One of the things that’s interesting about that is that there are a lot more ways that things can fail than the ways that failure can actually show up. It’s sometimes easier to clean up the footprints than try and figure out what made them.

SAM:  [Laughs]

NOEL:  Sometimes, if you can recognize that we had at one point in this system that it was a rare condition where somebody could get a privilege that they weren’t entitled to or a discount – I don’t remember exactly what it was. And it was very, very hard to diagnose what the problem was, what was causing it but it was really easy to tell what had happened after it happened, like we could see it in the database immediately. And that was fine, it happened like once or twice a year and it was cheaper to actually have the tracker say, “Hey, this went wrong. Let’s correct it,” than it was to spend two days trying to track down some sort of whatever rare ways condition or something was causing this weird case.

So sometimes it is cheaper to fix the symptoms rather than go after the actual problem.

CORALINE:  That is awesome. I want to remind our brand new listeners, and we love each and every one of you, that we are listener-supported currently. We have a Patreon at Patreon.com/GreaterThanCode. We have some fabulous rewards for people who contribute. We have a Patreon only Slack that you can join in on and you can actually post questions for our upcoming guests. We will give you shout-outs and tweets to thank you. At the $25 level, we actually will add you to our Patreon page, $50 gets you a shout-out on the show and Twitter and a t-shirt and sticker pack which is pretty amazing. So, give what you can even if it’s only $1, that will get you into our Patreon only Slack. We love you all and hope that you will support us so that we can continue bringing you awesome podcasts.

JESSICA:  Wait, wait, wait! There are stickers?

CORALINE:  There will be stickers.

NOEL:  I’m so tempted to just shout-out random things that might be benefits just to have you guys have to edit them out or whatever.

CORALINE:  Go for it.

JESSICA:  We’d love your ideas.

CORALINE:  Yeah, we call it [inaudible].

NOEL:  At the $20 level, you get an elephant. No!

JESSICA:  [Laughs]

JAY:  Donate $150 and Sam will dye his beard.

NOEL:  That’s awesome!

CORALINE:  We’ve actually talked about that as a perk. So that is very possible. You get to pick the color [inaudible] beard.

DAVID:  Users pledging above $10 before the 1st week in October will get Noel Rappin’s home phone number.

[Laughter]

NOEL:  I had it started, didn’t I?

CORALINE:  A doc’s reward. So, in our Patreon only Slack that I mentioned, we had a question for you, Noel, that came from David Bock. He said, “Tools recruiting on my businesses have become incredibly accessible. I can have a great business idea, spend a few hours coding it up, authenticate with a service like [inaudible], host with a service like Heroku, and launch my business the same day I had the idea. But then I ran into the reality of credit cards, merchant accounts, payment gateways, et cetera. What is the quickest path to accepting payments online? Are there any drawbacks to getting something up fast?

NOEL:  Right. This is actually kind of like before you get into the stuff that you need with the book covers. But there are a couple of [inaudible] let you come in really fast. Stripe has their full credit card form version of their JavaScript thing which is super easy. You just drop it in and it gives you a really pretty credit card form. And then you’re using Stripe’s dashboard for all of your administration. But it’s really easy to set up. In the normal web situation, you’d probably have to integrate it in your shopping cart a little bit, but it works fine for taking payments. If you want to outsource the whole shopping cart, there’s all kinds of services that do that. Things like DPD or Shopify, I think, that let you outsource the entire shopping cart. So, like myself published on my site currently goes to DPD and also Squarespace eCommerce things like that that are services that will take the whole workflow for you and then they’re also handling your administration.

So, there’s a couple of different levels there before you get into actually to handling the API calling your own server side. Customization is one of the tradeoffs and you also lose if you have specific business logic around inventory or accessibility or pricing or things like that. The more things like that you have, the harder it is to integrate one of the off-the-shelf services. But it is a good way to get started. The Stripe dashboard in particular is really nice. You can do refunds from it. You get a sense of your users from it. Your users can register with it and Stripe manages all of that. And that can take you ways until you feel like you need the custom data. Your long-term tradeoff is probably going to be getting the data out of Stripe into whatever you’re continuing to use ongoing but it’s certainly a great way to get started.

JESSICA:  Yey Stripe! I work at Stripe and I think Stripe is awesome.

NOEL:  Stripe’s docs are fantastic. The documentation they have is really, really well done.

JESSICA:  Also you can get started testing with no approvals or process.

NOEL:  Yes.

CORALINE:  Testing is a really interesting subject that you cover pretty extensively in your book, Noel. Do you want to talk about that a little bit?

NOEL:  There’s a couple of different issues with testing payment issues. One of which is just the generic issue they have of testing any third party service. You’re trying to test something that is making a network call, so you want to set that up in such a way either using – in Ruby, you can use the vcr gem to make the third party network call and then store the results to the next [inaudible] test runs. You’re using the stored results rather than actually going out to the network for a new call. That works great.

But then you also have the specific issues of you really are doing something that potentially has real world consequences in terms of potentially charging credit cards, you need to be careful by how you test. Stripe provides a lot of specific pieces of data to test specific failure modes. So you can do things like put in test with a specific credit card number that triggers a specific kind of failure or card decline or a zip code that triggers a fraud detector or things like that. Those are really helpful in terms of testing. 

But a lot of it has to do with just designing your application so that all of your interactions with the payment gateway go through one point so that you can test your code more or less in isolation of the third party networking tool and then also test the third party networking tool separately.

SAM:  You mentioned design. And one thing I noticed in your book, you’re using a pattern that is kind of like something I’ve seen called gourmet service objects or like what some people were talking about three or four years ago with DCI. This whole idea of missing layer between controllers and models, do you want to talk about that a little bit?

NOEL:  The way the book is set up is we create almost everything that we do in the book goes through what we call workflow object. So mostly what the controller does is create one of these workflow objects, pass it to data, the workflow object interacts with active record, handles the business logic, and returns essentially a success or failure code back to the controller.

There are a couple of reasons why I do that. One of which is to try and get the business logic isolated in Ruby objects that are not active record objects, so it’s somewhat easier to test. It turns out that it’s actually just because of the way Rails works. It’s still kind of hard to test them in total isolation from your database, but it’s somewhat easier to test them separately. And it also means you wind up with a bunch of relatively small, well defined classes rather than just having one generic payment class that winds up being 500 lines long, you have accepts payment class, you have refunds class, and things like that.

There’s one other way in which this is helpful. One of the ways to mitigate failure is to have that process run as a series of very small background jobs. So you have one very small background job that does the set up of your data, one small background job that calls the third party gateway, one small background job that then notifies the users’ success or failure. And that’s a lot easier to do if you have those things sort of isolated into their own objects and then you get some protection against failure cases and certain kinds of error checking become easier.

CORALINE:  Did you consider calling the book Practical Object-Oriented Design for eCommerce?

NOEL:  [Chuckles] No, I kind of wish I had. That seems to be a really popular title.

CORALINE:  99 Bottles of eCommerce.

SAM:  [Laughs]

DAVID:  For those of you who are just tuning in now, you’re listening to Classy 107.2 where we’re interviewing Noel Rappin, author of Growing Object-Oriented Software Guided by Other People’s Money.

[Laughter]

CORALINE:  Nice!

JESSICA:  Noel, I really do like the way you work this design recommendations in with the actual objective of the book, so that people can think about them in context. I also like the way each design recommendation expresses a tradeoff. That seems to be like a theme.

NOEL:  Yeah. Like I said, I think of this book as secretly being about designing Rails applications. Sam [inaudible] the structure of the book. The first chapter of the book really is all about getting the design and data model right even before you start taking payments. It’s actually the first chapter, I think it’s called Not Taking Payments on the Web and it’s really just about setting up the data model and setting up this workflow and talking about why you would want them to design an application that way.

I think it’s really important as somebody who comes across with a certain amount of authority from writing a book. People are going to receive this as coming from a certain amount of authority, I think it’s really important to say, “This is the way to answer it but this is the thing I did here. This may not match your experience. You might also want to look at this option.” You can’t do that too much because it gets really confusing for [inaudible] people. But I think it’s really beneficial to say, “This is why I did this. Your logic may vary, your need may vary, and you might want to explore doing something else.”

JESSICA:  Because you mentioned earlier at the beginning of the show that there weren’t any real solid stories out there of how people take payment and deal with failures and do all the hard parts of that. And that led you to write the book?

NOEL:  Yeah. We talked a lot in software design about business logic and we kind of hand-waved this is how we need to manage the business logic. But literally, when you’re talking about this payment stuff, you’re literally talking about the business logic like it really is the actual logic that keeps the business afloat. So it involves – zooming in on that thing that we sort of abstract away when we talk about principles of software design and really having to think about we actually need to take into account what’s going to happen when somebody comes and says. “Hey, we got a big order but it’s 10% off. Can we handle that?”

Or there’s a specific kind of tradeoff, for instance, around data validation. A lot of people put a lot of database validations in their application and it turns out that that’s constraining.  Each one of those database validations is a way that transactions can fail if something happens the way that you don’t want. And you need to think about whether that data validation is actually worth potentially failing a transaction over or whether it’s something that you can live with and mitigate later on.

CORALINE:  I’m not a big fan of database constraints. I kind of go back and forth on database constraints because it feels to me like smearing business logic across the layers.

NOEL:  [inaudible] a lot of them on our application after we — I literally went through, at one point, all of the code that we had that was running after we charge the credit card line by line as to like, “How can this fail in a way that’s going to have somebody get angry at me?” And, “Is it worth having somebody get angry at me to keep this line of code in there?”

JESSICA:  The database constraints are about when you find the errors on insertion or later when you try to read from it, right? And it’s like saying, “When should we find the errors?” “Oh, right now! One of the customers is waiting on us.”

NOEL:  When we have the chance of charging the customer and then failing is the best time to error check. Yeah, definitely.

Dave Thomas said that the only thing I got out of this application was he felt like the only kind of database constraint that was worth having was foreign key constraints, that those data [inaudible] are worth it. I kind of agree but they also make unit testing a lot harder especially in Rails. As Rails has moved towards more foreign key checking, it gets harder and harder to test active record objects in isolation but that’s, again, another kind of tradeoff.

JESSICA:  We’ve gotten down into tactics again. But I think when you talked about, when we’re deciding how many database constraints to have, at some point, you’re describing a strategy that is a business decision. That is how we, as a business, are going to handle these things, which reminds me of your talk about being a developer who’s also leading a [inaudible]. And you had the same problem there where you found a lot of information about tactics but little about strategy.

NOEL:  I spent a little over a year as Director of Talent at Table XI which put me in charge of internal recruiting and essentially all of the HR kind of stuff except for benefits that a small company might put up with. One of the things I discovered looking out for literature on this is they have a lot of very tactical information about ‘you should ask these questions in a technical interview’, ‘you should not ask these questions in a technical interview’, ‘this is what your job [inaudible] should look like’. And there are very few higher order resources like when do you know that you need to hire, how do you increase diversity on a team that doesn’t have much turnover. Bigger picture questions about how you manage certain kinds of tradeoffs in terms of balancing the needs of the company, for instance. Balancing vacation time against an hourly consulting business is really complicated and there’s not a whole lot of guidance about that.

JAY:  I think it’s kind of unusual. I’ve seen another company kind of have someone who led engineering and development move into talent. Other particular strains that you think that someone with an engineering background can bring to talent? I mean, HR has been around for a long time and there’s kind of a set way of doing things. [inaudible] stood out and you say, “Hey, I think I might be able to apply things differently in talent.”

NOEL:  Yes, there are definitely weaknesses. One of things at the talk is kind of like I wasn’t really a good fit for this. There were some things about it that I was excited about and good at, and there were some things about it that I kind of struggle with. I think that one of the things that I brought to it was an understanding of what we were trying to do in the developer recruiting process and I think that that was having an engineering perspective like really designing that helped a lot.

One of the things that I really try to do and didn’t do a super great job of – it’s a common issue at small companies – is that you don’t really have to think about having much of an HR reporting process for even minor issues that people might have. And I think it’s really common especially if you’re a small company who kind of really hires well and has good people. You think of this as something you don’t necessarily need until you really, really need it.

And we’ve been lucky for the most part. But I tried really hard to put together and HR reporting path and I kind of thought we could potentially do one that went through me as the Director of Talent and it turned out that – there are a few reasons why that didn’t work out. And one of the reasons it didn’t work out is because it was awkward for engineer coworkers to come to an engineer with that, I think. I think they may also be that I’m potentially kind of socially awkward in one-on-one situations and I think that that played a role too. I think that that maybe, I almost certainly don’t have the kind of emotional intelligence that you really want in that role.

So, that’s a limitation. And it’s not a limitation of all engineers certainly but I think there was a limitation of this engineer. It was in the [inaudible] position of kind of understanding all of the things that I couldn’t do in a way that was frustrating because I couldn’t do them.

DAVID:  What is that [inaudible] position?

NOEL:  The [inaudible] position of being able to appreciate greatness but not being able to achieve it yourself. I think I was able to see what a good process would be without really being able to bring [inaudible] myself.

CORALINE:  HR is really hard to do and hard to get right. GitHub is actually [inaudible] right now especially in their hiring practices and there’s been some public discussion of GitHub’s hiring practices. It’s a really hard problem to solve. It’s good to see some emphasis on it but I have to say Table XI considered hiring someone who kind of specializes in some of these areas to educate you.

NOEL:  Yeah. We brought in a third party to do an exit interview of people to talk about, not so much our hiring practices, but to talk about the company to do a pre-focused — what turned out to be an exit interview that we were specifically trying to get questions answered about diversity and inclusion at the company. So we did that. We brought in somebody to give us a [inaudible] from the outside looking at those issues. We have talked about having a – we have a dedicated person who handles benefits. We talked about having a part-time person to handle conflict resolution like a lot of small hourly companies. It’s a priority issue as much as anything else. We did the best we can with what we’ve got and I advocate for the things that I can and we do what we can.

The interesting thing about the Table XI example is it’s a company that really is a very good place to work where people really, really care about making it a really great place to work and things still aren’t perfect, which is a completely different problem than a place where nobody gives a damn. People really care about it and we still struggle with the stuff.

JESSICA:  Earlier you said that your web [inaudible] on how it handles failure and administration. Is that true of your company too?

NOEL:  I think that there is something to that. The sort of piffy line is ‘culture is the things you let happen’. I think there’s something to that. And one of the things we actually haven’t tried to do is ask everybody to be really super invested in the kinds of casual things that we let happen and the kinds of casual things that we don’t want happen and that’s something that we’re really making it off around.

JAY:  I always talk about things that for me – one of the implications of the applications that we’re creating and this gets back into my whole thing about [inaudible] is when we sit down – I know we only kind of think about some of these things. I know that don’t always [inaudible] but I’ve been through this process of implementing Stripe and kind of building an application. But as a part of this as a developer, I could also say I’m automating a way a little skill job there. So I wonder if we have responsibility. When we talk about culture at large, as well, I don’t know if it’s something that we should consider talking about down the road. The way we build our companies, obviously, there’s inclusion and it’s also very important. But we also, in automating things, we’re getting to a place where [inaudible] some of this stuff. You would call in on the phone and make an order and someone would [inaudible]. Obviously none of that is going to change at all, but I do wonder if, as the panel, if that’s anything that you kind of thought about at all and say, “Hey…” I’m not saying we’re destroying the society at all but the code that we write has implications outside of just our small, small business. Sorry, I know it’s really long but that’s what I’ve been thinking about this entire time.

NOEL:  That goes way beyond what I was talking about when I talked about culture and things like that. But it is something to consider. In terms of the impact on the larger society, we try to work with clients that we think are going to be beneficial in that way. Do we do it all the time? No, but we certainly try to have clients that align with what we’re trying to do.

JESSICA:  When it comes to taking payment and I’m speaking about Stripe’s mission here. Stripe’s mission is to let more people participate in global commerce so that if someone is [inaudible] maybe they have an idea to start their own business or maybe they put things on [inaudible] or Shopify. The more we can make it easy for more people to take out the people’s money, then we give them alternatives.

NOEL:  The interesting thing about this is that we live in a culture that is really enamored in the idea of disruption. And I think it’s important to understand that disruption has sort of by definition, like unpredictable consequences that you never know who is going to benefit in the end and who’s not going to benefit. We see this in the small and in the large and we see it in the things that might replace call centers, we see it in self-driving cars that may replace truckers or cab drivers or things like that. I think that it’s tricky because it’s hard to contain the technology once it’s there. But it’s also hard to know what the impacts of these kinds of things are going to be. I think that it’s really beneficial to try and have as many people as possible be able to participate in the economy of being able to take payments. Stripe and Square and there’s a whole new kind of transactions that are feasible. A whole new kinds of business are feasible with that technology that were not feasible before. And that comes at a certain kind of cost. There’s a whole kind of employment that was feasible before that may not be feasible in the future. I don’t know how to balance those tradeoffs. And I think that I have larger political opinions about that that may or may not be interesting to anybody else on my head but I certainly don’t know how to balance the tradeoffs [inaudible] community.

DAVID:  It’s hard to determine who will profit from a move but it’s impossible to determine who’s going to profit here. The nature of disruption is it’s not directed. You’re going to detonate something and then you’re going to see who can react to it and embrace the change the fastest. After, there’s going to be winners and losers.

CORALINE:  I think it’s really important to have teams that are made of people with different backgrounds and experiences. I see a lot of “disruption” [inaudible] at Silicon Valley which is just solving the problem as [inaudible] heterosexual white guys in their 20’s. And if that’s the source of disruption, then they’re going to be suicidal consequences that are anticipated.

NOEL:  There was a talk at [inaudible] last week that was about a Rails application. I’m sorry I don’t have the details in front of me. But they built a Rails application to help people crowd source water bills in Detroit and Baltimore which are cities where if you don’t pay your water bill, it gets put on your local property tax bill. And they built a site to all the people to crowd source one time payments to get out of that problem. I’m doing this on top of my head, so I’m probably not describing it right.

But that’s a case of trying to disrupt the problems of single mothers who are in debt and that’s the case where diversity might try to disrupt other people’s problems rather than the problems of 20 something tech workers.

CORALINE:  Yeah.

NOEL:  That’s a really interesting use of technology. There’s certainly all kinds of – this is going to be terrible because it’s certainly not what I spend my day doing unfortunately. But there’s certainly all kinds of government [inaudible] services that are terribly hard to navigate. They would certainly be considered ripe for disruption if they were commercial services.

CORALINE:  I was just reminded of a tweet that I saw, I wish I could remember who tweeted this. But if you’re not thinking about how the software you’re building can be used for abuse then you’re not doing your job. I’m reminded of a piece of software that is anonymous location based chat that has been used and abused for harassment purposes. And that’s more of the thing I was thinking about when it comes to who’s doing the disruption. Like, have you ever been a victim of harassment or are they thinking about how a particular app can be used for harassment? Or are they thinking about the repercussions of the thing that they’re enabling with technology?

NOEL:  That sort of ties us back towards why is it valuable even for a small company like ours to have diverse teams to include voices to empower people within the company from all kinds of backgrounds to talk about what their issues are, to bring different perspectives to the table when we have a project so that all of these different perspectives are heard. The more input you have, the more potential problems that you can head off before they go [inaudible] or they can actually hurt people.

JAY:  I’ll go one step further too. I think there weren’t a place where as engineers we have the responsibility, I think, to the public at large to also advocate on their behalf and being in a place where we’re making great money, there’s other opportunities that are there for us. And I think that’s a part of that in saying that we need to bring people in but we also need to be not just allies but accomplices for people who [inaudible] representing communities. I think that’s a piece of it.

And there has been benefits. I think one of the things I’ve noticed in so under representing communities is things like Stripe and social media has allowed people to create small businesses within their homes that are doing really, really well. To be able to kind of hit the long tail of people within their communities and they’re able to advertise at a much cheaper rate and not have to think about how do I utilize Stripe’s API.

There’s also beauty to the things that we’re doing as well. But as we’re looking at disruption for taxi cab drivers or truck drivers and things of that nature, I think it’s going to require us to advocate for people who aren’t in the position as we have.

NOEL:  One thing I just want to say about diversity inclusion within your team is that it’s also worth thinking about diversity, not just in terms of people’s experiences but also in terms of people’s personalities. A really [inaudible] I think is, especially in an engineering culture, is introvert-extrovert where if you’re the extrovert who’s the person who’s raising your hand at the meeting get hurt, that’s an issue that’s separate in [inaudible] from all of these other really important issues but it can also prevent some of these other issues from coming to the table in a team if people are not the kind of people who want to shout out for whatever reason don’t feel comfortable doing that. That’s an issue that almost every — I would imagine that many engineering teams sort of struggle with and it’s something that may be preventing all kinds of different perspectives from coming to the table.

CORALINE:  At a previous job, I was on a team [inaudible] for remote and both of us who were remote were women. And the teams sort of [inaudible] was strong opinions as he held which led to a very argumentative approach to problem solving.

DAVID:  Dialectic.

CORALINE:  Yeah, neither I nor the other woman on the team felt comfortable arguing and expressing strong opinions because we had a different approach to problem solving. And also the fact of being remote meant that we didn’t really know the queues for when we were ready to talk, when we were ready to participate. There was sort of [inaudible] over us.

So I think that addressing that kind of issue at the culture level can exclude or include people with different communication styles which may intersect with different populations.

NOEL:  That goes back to all kinds of things. I can [inaudible] this all the way back because we talked about George Tech [inaudible]. One of the reasons I’m there instead of another school is I visited another school and I learned that part of their culture is what they call Friday Afternoon Fights where somebody would come in and deliver their work. And the goal of everyone else was to heckle them so much that they couldn’t pass their first slide because they have to ask so many questions. This is not a culture that I am interested in participating in.

But this goes all the way back to the kinds of companies we work at. This comes back to how we present our job listings. I recently read a job listing that was like talking about [inaudible]. If programming languages were weapon, Ruby would be your weapon of choice. I don’t know that I like that. There’s all kinds of things that tie in, in big ways and small ways.

JESSICA:  And it comes back again to looking for this failure cases because when you invite people with broad experiences to the table and give them the opportunity to speak, then you’re actually looking for the failure cases. It’s much easier in a meeting to focus on the happy path of the things we agree on. It’s a totally different culture that says we really want to hear about this might not be quite right.

CORALINE:  There was an interesting experiment in the [inaudible] by a sociologist named Solomon Asch is the conformity experiment. I talked about this in one of my talks. He would have a panel of 7 or 8 men. And he told the one participant of the experiment, one of the 7 or 8, that they will be participating in a test of visual acuity. And he would hold up a card with a line on it and then hold up another card with 3 lines on it labeled A, B, and C and ask which line is the same height as the other line. What he demonstrated is if the majority of people that [inaudible] in the experiment give the wrong answer, the last person to answer who’s the actual subject of the experiment was almost 50% more likely to go with the wrong answer rather than go against the group.

If you imagine that in a meeting situation where you have some very vocal people who are talking about the right solution, even psychology dictates that [inaudible] group, everyone is more likely to go along with the first suggestion that people put forward [inaudible] couple of suggestions especially if they’re worded very strongly.

JESSICA:  And some people have more weight than others as well. Like if you’re the manager or the tech lead and you put forth a suggestion, people are not disagree with it the way they would if it was someone else said it. Or if you’re the person with the most experience at the company or the most prestige, you can shut people down before they even open their mouths.

NOEL:  That’s a power you don’t really want to use very sparingly if you’re in a situation where you have that kind of weight.

DAVID:  I have probably counseled no fewer than three different vice presidents of engineering, taken them aside and said, “You used to be the team lead and you are used to saying ‘how about if we try this’. Have you noticed that since you became VP, when you say ‘how about we try this’ there are no competing theories? That’s because when the VP says ‘how about we try this’, everyone hears ‘you will try this’.”

NOEL:  I think that’s a very hard thing to get used to, I would imagine. I only have very limited experience with it. It’s a very hard thing to get used to that sort of transition between when you’re used to being in a situation where you’re sort of wanted a team and you’re suddenly put in a situation of being a team lead, that implies a transition in your style, in your conversational style and your meeting style that I think is a hard adjustment for some people.

JESSICA:  My manager at work said once that it gets in the way a lot for leaders to have opinions.

CORALINE:  Nice.

DAVID:  Nice. I think there’s an important distinction because there are people out there that are listening to us right now going, “No, if somebody doesn’t stand up and have an opinion, we’ll never get anything done.” There’s a time and a place for extroverts to have their dialectic and argue. There’s also a time for people to say, “This is the direction we will go. We’re going this way.”

JESSICA:  And a designated leader, as a VP, it is your job to say that at some point. The problem is you can’t say anything before that.

DAVID:  Yeah.

JESSICA:  It sounds like you’ve made a decision.

NOEL:  When you say that you’re ending the conversation and you need to be careful that you’re ending the conversation after all the viewpoints have come in.

CORALINE:  I worked along with junior developers and I do mentoring adwork of junior developers on my team. And I feel like it’s my job as a senior engineer to make sure that everyone’s voice is heard. I’m not in the position of authority in the team, I’m not the manager but I need to make sure that everyone has a chance to express his opinion because even as a senior, I have an influence. And if I say, “This is my opinion on how we do it,” the juniors are going to assume that I’ve done it before and that’s the way we should go. They may have a fresh perspective on things because they have not been doing it for 20 years and they don’t have that engrained habits and those sort of [inaudible] reactions to, “Oh, this is the natural solution to this problem.”

JESSICA:  That’s when the stupid questions are the best questions.

SAM:  Yeah. I feel like there’s something from the Picard Management Tips Twitter account awhile back about how you got to solicit everybody’s ideas independently and then come to a decision afterward.

NOEL:  Actually, [inaudible] non-technically, but the first time was when I was in college and I directed a show. I was the director of a small one-act play and I was asking one of my friends who’s the actor and I asked how it was going. And he was, “Noel, sometimes you just have to direct and give an opinion and tell us what the right answer is.” And I think you give everybody the chance to have their input, but at some point, you do actually have to pick the direction. The dynamic of when to do one and when to do the other is what makes [inaudible] a team like a [inaudible], one of the many things.

DAVID:  And getting the right choice. You’re going to shut down some of the conversation in order to increase the contrast and discrimination between the free variables that are left in the choice. And you have to get the free variables right and it’s so obvious when somebody is deliberately trying to manipulate the conversation by pre-deciding the only free variable that you care about.

NOEL:  Another thing worth mentioning is something that’s actionable that everybody here can do in their projects right now that will help us is to have team retrospectives on a fairly regular basis where you’re not under the gun or making a pressured decision, you get everybody in a room and you set up a structure where a lot of times in a retrospective like this, people start by writing down things they want to talk about on sticky notes or something like that which is often a way to get people into the conversation who wouldn’t otherwise jump into a conversation. And that’s a really good way to start identifying what are the pain points the team is actually having and try to find one of those pain points and take an action item that makes it better. That’s something that anybody on any team can start to do like this week is to have a team retrospective of just how things are going.

CORALINE:  In one job I had, we decided in our retrospectives that we would go in order when [inaudible] time to talk about the topics [inaudible], go in order from the most junior developers to the most senior developers to make sure that their concerns are addressed and also that their perspectives are recognized.

NOEL:  I think that’s fantastic.

CORALINE:  I think another thing that’s important especially for teams that have a mix of experiences is actually demonstrating that it’s safe to fail. In addition to retrospective, sometimes a project goes terribly wrong and the technical decision that you made early on was not the right decision. And you might want to have a post-mortem where you own up to it and say, “I thought that this was the right approach and I was wrong.”

As a senior developer, one of the most important things you can is ‘I was wrong’.

JAY:  It’s interesting how that kind of dovetails nicely to the beginning of the podcast in that it sounds like some questions around what point in time do I make this job into utilizing Stripe. What point in time do I pick up some of the stuff?

Noel, you mentioned a couple of alternatives there but there’s this whole process I think that happens before. That’s kind of where maybe some folks are well aware of, [inaudible] before determining I know I need to take payments for a thing, do I go through and look [inaudible] Stripe API documentation and kind of build up something of my own? Or can I really kind of hack something together that allows me to kind of put together an MVP and have more information and kind of go through the same process that you’re describing where there’s you and the people who care about you and they care about the thing that you’re trying to develop or if you’re working on a team. So, that’s kind of interesting. It seems we kind of making our way around in full circle here.

JESSICA:  Sometimes the hardest decision is when do we make the decision?

CORALINE:  I think we’re about at the end of our time. I would like to know, Noel or our panelists, what was your favorite thing that we talked about? What’s something you’re going to take away from the show and think about a little more after we’re done recording?

NOEL:  I think that taking back the thing that I took in from this is digging a little bit more about the impact our applications and how they work in real world context. That not the thing I came in with so that’s the thing I received from this conversation to go out and talk about. Not that it’s not something I’ve never thought about but it’s the thing that came to me from this show more stronger.

DAVID:  I think one of the more interesting things is we started off talking about how to take money on the web. And we ended off so far off in the weeds that we realize this is where the road needs to go. That it wasn’t like a distraction or a derailment. It was like a ‘no, this is where we want to go’. And I absolutely love that we threw out some things that we’re just like, “What are we going to do here?” And Noel just had. “Maybe we should try. Here’s a process that you can put in play. Try this at your next meeting.”

The book Crucial Conversations talks about a concept called the pool of shared meaning. When you have a really difficult subject to talk about, we all kind of stand around this pool and we throw ideas into it and we fish ideas out, and we come to a shared meaning here. And there are people who try to control the pool by withdrawing from it because they don’t feel safe and there people that will try to charge headlong into it to try and drive people away from the pool in order to enforce meaning.

And we talked a little bit about how a vice president has to be careful or someone in the senior leadership has to be careful that they don’t express an opinion that comes out sounding like a decision before people have put their input into the pool of meaning. And we talked a lot about how to get introverts to come forward. We started off talking about a lot of people saying, “I’m not going to go to the fight.”

This is less of a touch-point and more of a thing to touch on and I want to give this back to Noel. We talked a lot about how to get introverts to come forward. Is there more to that? Is there something that we could tell an introvert who’s sitting around the pool of shared meaning and nobody else has heard this podcast? What can we give you, dear listener, what can Noel give you to help you step forward and basically say, “Hey, what about this?”

NOEL:  You don’t want to necessarily be on the introvert – just like in a lot of other situations, you don’t want to be on the introvert to create an environment that makes them feel comfortable, like that’s on the group to create the environment that makes the person feel comfortable.

There’s a book that we had everybody here read called ‘Quiet’ which is about introverts. The author’s name is Susan Cain and it’s about introverts. The subtitle is ‘The Power of Introverts in a World That Can’t Stop Talking’. And it has a lot of how to allow introverts to have a role in the processes that are typically sort of dominated by loud voices.

CORALINE:  I would hope that our listeners one of the things they walk away with is the inspiration to look at their teams, look at their meetings, look at their discussions and see if they are in fact leaving room for everyone to participate equally.

SAM:  Yeah, and that doesn’t look like, at the very end, saying, “Hey, we haven’t got any questions,” and waiting 15 seconds and saying, “Okay, great.”

CORALINE:  Yes.

JESSICA:  I have a takeaway from what Dave just said which is we started talking about accepting payments on the web and we found something Greater Than Code.

[Laughter]

SAM:  Way to bring it home!

CORALINE:  It wasn’t weeds that we wanted into [inaudible].

JAY:  Is this the point where we all start chuckling and then we freeze and the credits rise up.

CORALINE:  [Laughs]

DAVID:  We’re all going to jump in the air and then freeze frame.

SAM:  You’re probably wondering how I got myself into this situation.

JESSICA:  Jay, did you have a takeaway?

JAY:  I was just ruminating on all the awesomeness that this is. Most point about – a good example is HR and Talent initiatives sometimes are trivialized until there’s [inaudible], your company’s name is in the press and then [inaudible] says, “You know, I’m working on hard problems but that shit is hard.” I’ll sum up what he said. I think that shows that if we watch [inaudible] trying to do here. If you want to work on the hard stuff, the hardest problems to solve are the things that are greater than code. And that’s what I’ve heard from Noel, so far, which says what I think I heard.

CORALINE:  That was awesome.

NOEL:  To tie it all the way back to the [inaudible] like a lot of the problems that are hard there become personal problems because they’re problems of how workflow works. How do we empower administrators? How do we decide who has the ability to do what? How do we decide what happens in strange conditions? All of those things are isomorphic to the problems that we have as software teams in terms of deciding complicated procedures and things like that.

SAM:  Honestly, I’m going to have to go back and listen to this call again three times just to get everything that everybody said. But one thing that really grabbed my attention was just a small snippet of something Jay said earlier about being not just allies but accomplices. And I really want to try and take that to heart. Maybe I should get a tattoo or something. There’s so much to unpack just from that little phrase. I loved the economy of words that you used there. I’m going to have think about them.

CORALINE:  This has been a really great conversation and I think it’s a really great first episode. Noel, I want to thank you so much for being a part of this. If people do want to buy your book, how do they get a hold of it?

NOEL:  The book is available at pragprog.com. It’s called Take My Money: Accepting Payments on the Web. Pragprog.com/book/nrwebpay I think is the URL. I also want to mention the cover which I really like. They picked a great stock image for it at shopping cart made out of a mouse cord and it’s one of my favorite things about the book. So, that’s pragprog.com. You can also follow me at Twitter @noelrap and you can follow me on the web at NoelRappin.com and Table XI which is a great place to work and a great place to work with. That’s TableXI.com.

CORALINE:  Great. Thank you so much. We hope everyone has enjoyed Dread Coder Roberts. Good night listeners. Good work, sleep well, and I’ll most likely see you in the morning.

[Laughter]

SAM:  You say that every night.

This episode was brought to you by the panelists and Patrons of >Code. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode. Managed and produced by @therubyrep of DevReps, LLC

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.