In this conversation, Ben and Derrick discuss the challenges of growing a business and the decision to target specific market segments. They explore the trade-offs between serving a broad audience and focusing on a niche market. They also discuss the technical choices and architectural decisions in building a product, with Derrick sharing his positive experience with Elixir and the Phoenix framework.
Elixir and the Phoenix framework offer a maintainable and explicit approach to building applications.
Functional programming paradigms can simplify code organization and improve maintainability. Object-oriented programming and functional programming have different approaches to code organization and maintainability.
The active record pattern in Rails can lead to large and complex models, while the repository pattern in Phoenix provides a more modular and explicit approach.
Open source contributions can be seen as a good faith contribution to the commons and can provide benefits such as status and marketing opportunities.
Developers can improve their design skills by studying resources like the book 'Refactoring UI' and being introspective about user interfaces in their daily lives.
Chapters
Chapters
Introduction and Background
Savvy Cal and Horizontal Products
Choosing Between Niche and Broad Audience
Phoenix vs. Rails
Object Oriented vs. Functional Programming
The Motivations Behind Open Source Contributions
Improving Design Skills as a Technical Person
In this conversation, Ben and Derrick discuss the challenges of growing a business and the decision to target specific market segments. They explore the trade-offs between serving a broad audience and focusing on a niche market. They also discuss the technical choices and architectural decisions in building a product, with Derrick sharing his positive experience with Elixir and the Phoenix framework.
Elixir and the Phoenix framework offer a maintainable and explicit approach to building applications.
Functional programming paradigms can simplify code organization and improve maintainability. Object-oriented programming and functional programming have different approaches to code organization and maintainability.
The active record pattern in Rails can lead to large and complex models, while the repository pattern in Phoenix provides a more modular and explicit approach.
Open source contributions can be seen as a good faith contribution to the commons and can provide benefits such as status and marketing opportunities.
Developers can improve their design skills by studying resources like the book 'Refactoring UI' and being introspective about user interfaces in their daily lives.
(22:20) - Object Oriented vs. Functional Programming
(36:02) - The Motivations Behind Open Source Contributions
(43:20) - Improving Design Skills as a Technical Person
Creators & Guests
Host
Ben Orenstein
Co-founder @tuple.
Guest
Derrick Reimer
Founder of SavvyCal
What is The Tuple Podcast?
Ben Orenstein interviews great programmers about their craft.
Ben Orenstein:
Hello, sir.
Derrick Reimer:
Well, hello.
Ben Orenstein:
How you doing?
Derrick Reimer:
I'm doing pretty good. How are you?
Ben Orenstein:
I've been doing great. It's been a little bit.
Derrick Reimer:
I know. I'm grinning because this started out just like an art of product episode
Ben Orenstein:
It did. Yes.
Derrick Reimer:
Of of old.
Ben Orenstein:
Of of your. Of your. How many have we done? Like, I mean, we must have done a couple 100 AOPs. Right?
Derrick Reimer:
I'm pretty sure we crossed 200, but I don't have the exact number in my head.
Ben Orenstein:
Yep. So that's that's a lot of weeks. 1 a week for years
Derrick Reimer:
years. Yeah. Yeah.
Ben Orenstein:
But so for some people might not know you. I haven't been, we haven't done AOP in a little while. So you were my co host on this podcast for a long time where you and I would talk about, building our businesses. A couple of businesses actually appeared on that podcast over the years. We went through some transitions.
Ben Orenstein:
But you are you are a ridiculous human in some senses in that you are a very strong programmer and a really good designer and a good product person. So you have you have quite the collection of skills.
Derrick Reimer:
Well, thank you for saying that.
Ben Orenstein:
Yeah. Yeah. Totally. And that's not just for the podcast. You know I think that.
Ben Orenstein:
So you were the cofounder of Drip along with Rob Walling that people might know. You are now the founder of SavvyCal, which is a really excellent, find time on my calendar tool. Like, crank up to 11. I feel like it's like I feel like you kind of you are the tuple of scheduling where it's like, what if you just tried to make this but, like, you know, really, really good and, like, really sweat at all the details? Yeah.
Ben Orenstein:
Like, we are we have a team account. We use it internally. We use it externally. I, like, book a lot of personal things through it. And it just is, like, a really pleasant way to, like, send excellent sort of scheduling links to folks.
Derrick Reimer:
Well, thank you. I appreciate I appreciate the high praise.
Ben Orenstein:
Yeah. So props on all that. So we figured we would chat kinda, you know, for old time's sake. I saw you a couple of days ago. It was fun to see you.
Ben Orenstein:
Unlike AOP, which is a bit more was a bit more sort of day to day business focused. This is a bit more code focused, so we'll we'll get a little bit into some technical topics. But
Derrick Reimer:
like to get nerdy.
Ben Orenstein:
Yeah. Great. But maybe slightly on the business side. It seems like you are shipping features for sales teams recently. Is this like a a segment that you're going after?
Derrick Reimer:
It's a good question. Yeah. I mean, I think SavvyCal has been it's been a tricky road because it's inherently a very horizontal product. Right? So people probably a lot of people are familiar with Calendly if you haven't heard of SavvyCal, and we have chosen a pretty similar type of positioning in the market where it's where it's, like, you know, theoretically, anybody could use it.
Derrick Reimer:
Now, obviously, we we kind of try to attract, you know, people who have certain sensibilities and and care about quality, to be honest. You know? And so it it narrows it a little bit, but it's still generally speaking pretty broad. And, yeah, one of the one of the experiments of late has been, you know, should we try without totally making the product not something that your general, you know, entrepreneur or business person would like? You know, can we potentially narrow it just to touch on where we focus to try to try to hit some pockets of the market that maybe we're not resonating with a ton right now and, and unlock some more growth, which, you know, is is is very difficult for a horizontal product, I think, or probably any product, to be honest.
Derrick Reimer:
But, you know, especially horizontal where you're where, you know, we haven't been able to say have a leading headline on our marketing site that's like, we are scheduling for sales teams. Instead, it's like, we are a delightful way to find a time to meet or a thoughtful way or whatever. So, yeah, that's that's been one of the experiments. It's had it's had middling success, I would say, but, definitely, like, instinctually as a as a founder, I've I always feel like the closer you can get a product to the revenue in a business, the better position you're in. You know?
Derrick Reimer:
Mhmm. Customers are Yeah. Hopefully likely to value it more if you're, if you're helping drive revenue.
Ben Orenstein:
Totally. It's and it seems like sales teams pay for software. Like, they're down to buy stuff that helps them. Yeah. Totally.
Ben Orenstein:
Interesting. Do you wanna serve that market?
Derrick Reimer:
Well, that's the thing. Do I want to? You know, I think it's
Ben Orenstein:
Don't worry. They can't they're not listening. No one no one likes it.
Derrick Reimer:
Yeah. Yeah. Yeah. They don't listen to these nerd podcasts. Yeah.
Derrick Reimer:
I mean, I think I think it's always tricky too, like so there's you think you can think in verticals. Right? Like, sales teams or customer success teams or marketing teams or whatever. And then you can also kind of slice it in a different direction, and you can think about small teams, midsize, enterprise, large company. You know, there's all those different bucketings, and they're sort of imprecise.
Derrick Reimer:
And, you know, oftentimes, we don't even know what we mean when we say small business or midsize. But but, you know, think of, like, the types of customers that Basecamp serves or that Mailchimp serves or Calendly. Like, these companies generally, I feel like started their with their bread and butter as, you know, solopreneurs or small teams that that care about higher quality products and not necessarily trying to appeal to, you know, larger companies where the buying process is just different. Like, there's a finance team and there's procurement and there's, you know, oftentimes the people charged with buying products are not the same people who are using them. So there's there's a lot of kinda different dynamics to tap into, and and then often you're looking at higher price points and doing higher touch sales.
Derrick Reimer:
And so I feel like that's been the bigger the bigger thing for me to try to figure out, is, like, I feel like that's the the the whole game here. This being a founder is, like, figuring out, really what game you wanna play. And, and I think I still haven't totally figured it out with certainty because part of it's like, I also wanna grow my business, so I wanna go where the growth's gonna be. But how many of my ideals can I hold on to at the same time? And I know I have a natural bias towards towards serving the the small, you know, small businesses like myself, but then it's like, are you holding yourself back?
Derrick Reimer:
So I think that's those are the types of things that run through my brain when I think about that.
Ben Orenstein:
Yeah. That's that's tough. I so I'm getting a sense that, like, maybe this particular statement doesn't like you're not, like, drawn towards it necessarily Yeah. Spiritually. You're not, like, Yeah.
Ben Orenstein:
Dying to to do that. But, also, you have this broader goal of what number go up.
Derrick Reimer:
Right. No. Right.
Ben Orenstein:
Have successful business, that kind of thing, that maybe you're willing to sacrifice some of that perhaps. Yeah. Just feel like trade things off against each other. Mhmm. It does feel like man.
Ben Orenstein:
Yeah. You can you can, of course, go back and forth on this all the time, but, like, having a landing page where it's like, this tool for these people using this way and the right person finds it and they go, oh, perfect. Yes. This is what I want. And as, like, a product designer, thinking about a narrow niche probably just simplifies the the world so much versus
Derrick Reimer:
Oh, yeah.
Ben Orenstein:
You know, who could be using this? Coaches, therapists, whatever, Ben, makes it harder. And I think I mean, I think you've nailed the I feel like you have really nailed the general case Yeah. Of just like, this is a really good scheduling tool. It can handle a ton of different circumstances.
Ben Orenstein:
So I wonder how much more room there is to run on that front
Derrick Reimer:
Mhmm.
Ben Orenstein:
Mhmm. Versus being like, alright. We're gonna choose a lane, and now we can really go specialize on something.
Derrick Reimer:
Yeah. Yeah. And it's tough. I mean, I think I could probably rant about some of this stuff more broadly. Just how, like okay.
Derrick Reimer:
You know, a lot of us kind of got our start, looking at companies like 37 signals. Right? Who were sort of sort of projecting this vision into the world of, like, of basically kinda early stage how how SaaS works, you know, as a business model. And it's, like, it's this beautiful thing where you get to charge on recurring basis, and you can you can serve what they I think Jason Fried calls it, like, the fortune 5,000,000. You can serve, you know, the masses of businesses out there who are willing to pay a little bit of money each month for products, and you can build you can be a craftsperson, and you can build a really high quality product, and you can obviously, there's there's a a big element there of, like, getting massive distribution or enough to, to be able to build a meaningful growing business, that scales.
Derrick Reimer:
But so that's that's sort of the, an important detail that often gets kind of forgotten. Like, you need that element. But, like, so many other parts about their ethos, I feel like so many of us latched onto. And, now it's tough as, like, someone who identifies very much as, like, predominantly a craftsperson. Like, I I love building product, and I I like to think that my the special stuff I bring to the table and putting stuff into the market is like that it is higher quality and better.
Derrick Reimer:
And it's tough because I think a lot of a lot of, like, indie SaaS makers and bootstrappers and whatever you wanna call us, a lot of us have, like, switched over to figuring out that, like, that's a really hard road and there's not many, you know, marketing channels and distribution channels compared to, businesses where there's a higher price point, where maybe it's maybe it's more niche. Maybe it's, you know, doing higher touch sales, and you're figuring out how to how to sell to larger companies and and more power to anyone that goes that route. But, like, I'm like, I wonder if there's am I one of the last, of my kind trying to, like, replicate the dream that we all that we all kinda got inspired by early on, you know?
Ben Orenstein:
Yeah. We we argue arguably kind of have a similar problem in that our customer is feels fairly clear to me. Like, it's developers who are already convinced of the value of, like, synchronous collaboration. But is a good customer for us a company with 2 peep 2 programmers? Sure.
Ben Orenstein:
Yeah. That's totally fine. How about 3,000? Sure. Yeah.
Ben Orenstein:
Yeah. Okay. Just make sure to design for both those cases, and everything will be fine.
Derrick Reimer:
Right. Right.
Ben Orenstein:
It's like, oh, actually, that is it is kinda hard sometimes. Yeah. So there's always the, like, oh, what about Shopify? It's sort of how it comes up for us a lot of the time, when we're thinking of features. But, yeah, I I I don't know.
Ben Orenstein:
It's interesting to think. Like, how how badly do you want it? Are you willing like, are you gonna go to salesperson conferences? You know? Are you, you know, like and, like, it doesn't have to be you, but it's your company.
Derrick Reimer:
Yeah. Yeah. And if that's an important way to really get into that market, then it's then it's sort of like, well, I really wanna do that. And, and it does often feel like the decision between like, these sometimes these dichotomies emerge, and I have to try to figure out if they're false. You know?
Derrick Reimer:
Like like these, it's like, well, do you wanna do you wanna raise your prices and sell to enterprise, or are you happy just staying a little lifestyle business? And I'm like, how about neither? You know, I would like to I would like to grow. Obviously, I would like to, you know, to build even more flywheels to drive more growth because I'm ambitious. Don't get me wrong.
Derrick Reimer:
I want my business to be as successful as possible. But Yeah. Can I do that without doing the doing the enterprise sales thing? I wonder. Yeah.
Derrick Reimer:
You know?
Ben Orenstein:
Man, I was having these thought so we were we were at MicroConf this last week, which was, you know, great to see everybody. I had a nice time, but I found myself thinking, especially as I'm watching some of the talks, like where people are giving these, this like growth advice, like here's how you, here's how you grow a company. And my, and the thought was occurring to me, like, if how, like, I don't think there are any reliable answers to, like, make a company grow. And if you were in possession of a reliable answer to that, it is not, I don't know, like the sign of that would not be like you were on stage giving a talk about it to me. It would be you were becoming fantastically successful and wealthy growing your company.
Ben Orenstein:
Yeah. So yeah. The the even the idea of, like, oh, well, like, we'll just go enterprise, and then we'll start growing. Maybe. It's like, there's so much, I feel like there's like a little bit of alchemy here where there's so many factors and variables and timing and all this.
Ben Orenstein:
That's like almost all of the recipes to me are, like, maybe that'll work perhaps, like, test it out, try it, decide. I don't know. But I suspect there's not that much, alpha in, like, the things that everyone is sort of talking and thinking about and sharing is, like, the the classic growth tips.
Derrick Reimer:
Yeah. Yeah. I know. And I think I think probably the the one thing that sticks with me the most about this, because I think it's not fair to say that one path is necessarily easier than the other, because I think none of it's easy, you know, but I do think, you know, the way basically, if if you charge a low price point and you have a pretty low ceiling on the amount that someone can pay you or or the amount that, you know, the markets you're serving typically does pay you, then you just have a lot fewer options for going to market. Like, you have to be you have to be, I guess, really good at SEO, really good at content or some of these, like, extremely scalable, low cost channels.
Derrick Reimer:
And so, like, I think of, like, the traction book from from Gabriel Weinberg, you know, and there's, like, 20 something in there, and probably just a handful actually scaled down to the price point that I'm at. And so then you look at the you look at the companies that are that are that managed to break out and do really, really well. It was it was cool. Ben Chestnut from, Mailchimp, cofounder of Mailchimp was at MicroComp this year and did a little a little fireside chat. But it I think they're an example of, you know, they were in the market at the right time, and they did percolate for a while before actually, like, turning all their focus onto the product.
Derrick Reimer:
So I think they were able to sort of wait things out, and they got a little lucky in the fact that, like, they were kind of the best option for people who cared about quality and, you know, they just hit it at the right time, I suppose, And we're really good at at doing what they do. And so then they got a foothold in that space as, like, the the low cost slash freemium, you know, email service provider that creative people really like. And there was enough untapped demand that they were able to scale into that. Whereas it would probably be hard to, like, do Mailchimp all over again with the same exact, same exact pricing scheme. You know?
Ben Orenstein:
I think that's always true.
Derrick Reimer:
Yeah. There are these moments where, like, these things just work and then they don't work. And one could probably argue that if you have a more, you know, a higher price point product, then you you just have a lot more potential avenues to go to market through or potential avenues for distribution than than if you're just trying to, like, hit a massive wave of relatively low price point folks.
Ben Orenstein:
Yeah. That's probably true. Yeah. I'll talk about your stack a little bit.
Derrick Reimer:
Yeah. You can tell. Yeah. I'm coming out, digesting a lot of, businessy things coming off of MicroConf.
Ben Orenstein:
Oh, I can't yeah. I mean, you know, this is it's my sweet spot too. So I have to, like, drag myself a little bit. So you so SavvyCal is an Elixir app.
Derrick Reimer:
It is.
Ben Orenstein:
And so it's now been I think it's been enough years that you actually have some, like you can tell how it's gone because I think, like, evaluating the technical choice and architectural choice even in the 1st year or 2 is kind of like, yeah. Of course it's working well. Of course it's fast to add new things, and there's not that much mass there yet. But, like, you're definitely far enough along and the product is mature enough that there's been significantly there's there's substantially more functionality complexity. I'm sure you've probably done some substantial refractors and, and, and you've seen what it's like to add new things now.
Ben Orenstein:
So I'm curious how you feel like that has has gone for you.
Derrick Reimer:
Yeah. I will say that that is, definitely a choice that I don't regret. Elixir has been fantastic. And I feel like Phoenix is this was my hypothesis early on that Phoenix, which is kind of the the equivalent to Rails, but in the elixir, elixir ecosystem, really is to me, feels like the best parts of Rails. Like, the the parts of Rails that I really came to love and continued to love over time, I feel like made their way into Phoenix.
Derrick Reimer:
And then a lot of the parts where I sort of grew a little bit weary, you know, the particularly, the more magical elements of rails where, like, stuff is stuff is less explicit, I guess. And, like, I don't know, feels like, yeah. Magic's probably the right way to use it. Like, it's just a little bit harder to follow, a little bit more in direction, whatever. And some may call that some may call that, like, really well factored code.
Derrick Reimer:
But to me, like, a lot of that stuff just, you know, it became, more difficult to to, maintain as team size grew. I felt like, at Drip having maintained, like, a really large rails application for 8 years. You know? So so I feel like Phoenix is kinda the best of both worlds, just in terms of of maintainability and, really kind of thoughtful architecture.
Ben Orenstein:
Yeah. What stands out there for you? Because you say you sort of said, like, explicitness. It seems like it's a thing. Like, there's there's less magic reflection to sort of determine the name of the whatever.
Ben Orenstein:
Yeah. Why is it why does it feel better to you?
Derrick Reimer:
I mean, I think pretty much everything that the framework provides, you can you can easily hop to with, like, one step of indirection. So, like, you if you're in a controller and you wanna know, like, what's going on inside of that controller, like, there's a there's a thing that you use. It's like it's like a kind of a fancy import that, like, import some functionality into your controller that the framework provides. But, like, being able to inspect what those things are, is very easy to do. So, like, I'm relying a lot less on the documentation to try to, like, unravel where the the conventional or configuration stuff is coming from.
Derrick Reimer:
It's kind of just it's kind of just right there at the ready for you to for you to look at. And I just feel like in general, there's a lot more I think the functional paradigm lends itself really well to this where, you know, ultimately, it's just functions inside of modules, and you're passing data around. And there's Yep. There's a little bit to get used to and, you know, calling making method calls on objects in in Ruby, I will admit feels feels nice, but I think, again, it it often when you have this really long method chain that reads like a sentence that, you know, DHH loves, To me, like, that often ends up being, worse for for trying to, trying to maintain. So, like, the fact that you just take your data and you pass around between functions, and sometimes you decide your functions aren't organized properly and you move them into a different module, but that's really that's really the extent of it.
Derrick Reimer:
Right. I really enjoy that.
Ben Orenstein:
Yeah. Unlike, like, moving a method off an object onto another one where suddenly that method has access to different local data. Yeah. The functions are just taking their data. There's perceived having it passed in.
Ben Orenstein:
And so you you don't really care where they live, actually.
Derrick Reimer:
And I remember with with with rails, you know, like, I think we spent a lot of time, me individually early on and then as a team collectively trying to figure out where to put stuff. You know? Like, should we create these service objects that kind of tied together multiple objects? Or should everything be moved into a concern that we mix into our objects? And, I just feel like a lot of effort was spent in that area.
Derrick Reimer:
And, and still, like, the the kind of the rails conventional way of doing things, I think we found ourselves ditching some of that in the name of explicitness, but then we were kind of felt like we were a little bit off on our own island, like, doing things not quite the rails way. So we sort of had made up a way, which felt worse, you know, because then then it felt like we sort of abandoned some of the some of the benefits of conventional or configuration or just or just doing things the way the framework wants it done so that when you if you were to expand the team and bring on more rails developers, they would just kind of immediately know, you know, where to find stuff. It's like, felt like we had sort of abandoned the path at a certain point. And I don't think I don't think the same thing's happening in my elixir code base because I think the there are some loose paths for sure. Like, there's some, using bounded contexts is sort of a concept that that Phoenix brings in as as like an opinion on a way you should sort of organize your code.
Derrick Reimer:
And we basically follow that. But aside from that, there's not there's not a lot from what I've seen of of these, like, conventions that everyone expects you to be following or that the that the framework really wants you to to adhere to. And I think that's for the better. Interesting.
Ben Orenstein:
I'm sort of surprised, because I do I do feel like the conventions in rails are pretty darn handy.
Derrick Reimer:
I think a lot of them are for sure. But I think, yeah, things that the whole debate around fat model skinny controller, and then and then, like, models get too fat, and then where are you gonna put the stuff in the models? Like, I just kinda remembered that,
Ben Orenstein:
you
Derrick Reimer:
know, that became it's like when stuff gets sufficiently large, then the conventions kind of start bursting at the seams a little bit.
Ben Orenstein:
It's funny because to me yeah. This all just feels like it falls out of, like, object oriented versus functional programming.
Derrick Reimer:
Yeah.
Ben Orenstein:
Where, like and I think I I'm thinking of I think there's a Steve Yaghi piece called, like, verbs in the kingdom of nouns, which I think we wrote about Java, but it's the idea applies, I believe, which is to dramatically paraphrase based on a fuzzy memory of Mhmm. Of a piece I maybe was quoting. It's just, like, in o o, every time you wanna do something, you have to like, like, a verb. Every time you wanna add a method, it has to have be attached to a noun. It has to be, like, live in an object.
Ben Orenstein:
And so it's, like, just every time you just and and programs are fundamentally just just doing stuff. Right? They're they are verbing. They're not downing. They are, like, taking some data, doing some data, returning some data, like, doing something to it in between.
Ben Orenstein:
But if you need to find a noun to attach every single verb to, you end up in this we like, is it a service object that has, like, a one method called run? Is it on the user object? Or, like, is it on the user model? Because a lot of the data is on the user model, so it should live there. Well, it's already pretty big there.
Ben Orenstein:
So maybe it should do that. It should delegate somewhere else. I think I think a lot of that just disappears when you're like, it's fine. It's just a function, and it takes data. And it doesn't really matter where it is exactly.
Ben Orenstein:
There's a their modules are cool, but they're mostly just a namespace. Yeah. I think I've just been, like, pretty thoroughly, like, functional programming build. And, like, I'm not even sure this is rails versus Phoenix so much as just, like, what do you do when you are in an ops directed paradigm versus a functional one? Mhmm.
Derrick Reimer:
And I and I will say, like, I, because I was very curious when when, 37 signals released Campfire, their their once product, I did actually buy a copy of it because I just wanted to see, like, how does your architect code these days, you know? And so I think a lot of people bought it for that reason to kinda see, just, you know, see how they the people kind of the driving force behind Rails. How are they architecting code bases? And, and then DHH did a a live stream for, like, an hour and just, like, walked through the code base. And it was pretty fascinating because I think it was it it looks very, very clean and stuff is all kind of spread out across, you know, concerns and and, so models seem very short even though they're doing a lot.
Derrick Reimer:
And I think to a lot of people, that feels that feels like a win. That feels really good. And to me, as I watched him kind of walk through, like, how this stuff is kind of not entirely core to this, and I wanna be able to look in the file and just see the the stuff that's very specific to this object. So we're gonna move all this stuff into a concern. And maybe that concern will be shared between multiple objects, but none of that is really evident unless you do a lot of string searching and try to see, like, where all the places where this concern might be mixed into other other, models.
Derrick Reimer:
And at a certain point, after just kinda digesting this way of doing things, I just felt like, to me, this doesn't feel more explicit. It doesn't feel cleaner, even though it looks cleaner on the surface.
Ben Orenstein:
Yep. I think people tend to slightly overweight the value of it looks tidy and clean. Yeah. Like, oh, I've tucked all of these methods somewhere. It's not on my screen.
Ben Orenstein:
So when I look at this object, it looks like it's short. There's only like 10, 20 lines. Yes. 8 of them are includes that mix in a total of, like, 50 methods. And, also, I'm inheriting from active record or active model model or whatever it is these days.
Ben Orenstein:
And so now there's another 5,000 methods on this model. But it looks nice and tidy, so everything's cool. It's like, well, is that true? Or are in fact you just passing this massive monstrosity around this giant noun with so many verbs attached? And every time you wanna do something, you have to, like, get a handle on one of those.
Ben Orenstein:
I I understand the aesthetic appeal, and I I feel that motivation too. Yeah. But yeah. Have you have you actually if you're just pushing the piece around the plate, it seems like.
Derrick Reimer:
Yeah. Yeah. That's a good analogy. And, like, I remember being so obsessed in the early days of being a rails programmer on, like, having a 1 or 2 line method line long method only, you know? Like, like,
Ben Orenstein:
method length was such
Derrick Reimer:
such an emphasis, and I get it. I get it because you don't wanna you you still I'm not saying you shouldn't or think about organizing your your code well, but I just remember coming over into the functional paradigm, there was a lot more, I guess, acceptance of just, you know, keeping logic that should be collocated together, keeping it in one place even if that means, you have a long function. You know? And I I just I just found a lot more acceptance of that, and it kinda felt like, oh, finally, I I don't feel like I'm necessarily a a bad programmer in this ecosystem if I if I allow something to get a little long. You know?
Derrick Reimer:
Mhmm. Mhmm. Yeah. Totally.
Ben Orenstein:
Yep. That feels right. You know, we we age and we learn. We get a little more wise, hopefully. Few more years, we'll have a whole different set of opinions.
Ben Orenstein:
Figures crossed.
Derrick Reimer:
Another thing I'll point out from the from the Elixir ecosystem that's been really nice. So they have an ORM, you know, for interfacing with your database, but it follows the repository pattern, instead of the ACR record pattern. And I'm not an expert on these patterns, but I think the repository pattern lends itself well to to functional, I think, because you sort of have this you have this repository module that has functions like insert and get, and then you have queries that are a separate thing. And I know you can do some of this in active record. Like, you can use AREL or whatever they call it, and you can construct queries and pass them over.
Derrick Reimer:
But generally speaking, like, query formation and active record happens, kind of through the objects instead of through a separate a separate query mechanism. And, like, a lot of a lot of associations get kind of auto loaded in active record, which, you know, a big source of n plus one queries and stuff. And the, the ORM in Elixir called Ecto basically does does none of that. Like, it doesn't auto preload anything for you. So preloads are all explicit.
Derrick Reimer:
And so it's been really nice to have kind of both explicit preloading and separation of queries from actual operations. And then kind of in in between sitting in between there, like, a raw query for getting stuff, There's this concept of change sets where you can say, you know, pass a pass and, a struct in and then say, I wanna modify these few fields, and then that can sit in a change set, and you can keep passing that around and making additional layering on additional changes and validations, and then you pass that change set to the repo for persistence, and then it, and then it does the persistence to the database. So it's it's a really nice pattern. It takes a little getting used to, but, like, like, everything in moving from o to functional, but I have found it quite delightful and, like, basically eliminated a lot of the the sneaky n plus one queries that would sneak into the code base.
Ben Orenstein:
Interesting. I don't feel like I have a good picture of the, like, active record versus repository patterns. Do you feel like you have enough to, like, take a crack at that?
Derrick Reimer:
Oh, gosh. Well, I mean, I I think no. I I probably wouldn't do it proper treatment of, like, the actual, you know, Martin Fowler patterns or whatever.
Ben Orenstein:
Okay. What about what what about the concretions in rails and Phoenix? Like
Derrick Reimer:
Yeah. Okay. So as
Ben Orenstein:
you use them.
Derrick Reimer:
So in Rails, right, you if you want to, fetch a user, you call user dot get. Right? And you maybe pass in an ID user Yeah.
Ben Orenstein:
Use dot find or something.
Derrick Reimer:
Or find. Yeah. User dot find 1, and then you get back a user. And then if you want to make changes to that user, then what you would like. Set a set a different property on there and then call save.
Derrick Reimer:
And active record would just sort of magically figure it out, figure out what changed, since you last loaded it and then make the necessary updates to the database. Yep. And I think when, like, say you wanna get a list of users, it would be like user dot list.
Ben Orenstein:
Is that that kind of Gotcha. Dot all?
Derrick Reimer:
User dot all? You can see all my all of my rails, naming conventions are have slowly fallen out of my brain. Yep. So you go user dot all, and then say user has, you know, many, scheduling links. Okay?
Derrick Reimer:
Then you have an association on that. And remind me, how did those associations get loaded? Are they usually kind of auto loaded in Ramsland?
Ben Orenstein:
No. I think if you just said, I think if you said user dot all, it would not load the associated things. But if you
Derrick Reimer:
But if you called, like, user dot user dot links, you know, if you had a links association on in the user, then it would kind of magically
Ben Orenstein:
call that. Right? Yes. Yep.
Derrick Reimer:
Yeah. Okay. So I'll I'll kind of use that similar example for fetching, say, fetching a list of of users and their links in in Ectoland. So you would you might call repo dot all and the user, the user module. So it knows user module corresponds to a a schema type.
Derrick Reimer:
So reboot at all, and then you fetch all the users. There is no method on that. It's a user is just a a data structure. Right? So you can't just call, user dot links.
Derrick Reimer:
User does have a links property on it, but it defaults to being set as a Ecto not loaded data structure. So, like, if you tried to if you tried to use that, you're just it's like a kind of a a null state. And in order to fetch that, you have to explicitly call repo dot preload, pass in the user struct and the name of the association that you wanna preload in order to fetch it. And if you do that with a collection of users, so if you say repo dot preload and you give it a list of users and say, I want the links for all those users, then Ecto will figure out how to most efficiently fetch all of the links for all of the users you gave it. So basically, prevents you from being able to accidentally, you know, inside of a loop call, you know, give me the links for each of these users, and then you you do that in a really in efficient way.
Ben Orenstein:
Got it. So it's, like, rare it's, like, pretty much it's it's not making automatic additional database queries for you. You have to consciously decide to do that.
Derrick Reimer:
Yes. Yep.
Ben Orenstein:
And then is persisting stuff different?
Derrick Reimer:
Yeah. So persisting stuff, like, if I have a user and I want to, say, change their name, then I call. So there's a there's a another data structure called a change set, and you build basically, build these change sets and they represent modifications to an existing, data structure.
Ben Orenstein:
Mhmm. So
Derrick Reimer:
you pass it in and you say, I wanna cast a cert I want to allow a certain number of, certain attributes to be changed. So say they're coming in from a from a controller action or something, and you wanna allow first and last name to be changed on a user. Yep. So you can say, take this user, and you wanna cast the user and this user supply data that came from a controller, and you say, I wanna accept first name and last name. So then with that cast function, it basically builds a change set that represents kind of modifications to those two properties.
Derrick Reimer:
And then that change set, you can also add validation. So if you have a length validation on name or whatever, and it knows at any given state whether it's in an invalid state or valid. And then when you're ready to persist those changes, you pass the change set into a repo dot update function, and then that applies the actual changes to the database.
Ben Orenstein:
Interesting.
Derrick Reimer:
Yeah.
Ben Orenstein:
Do you manipulate manipulate the change that's directly sometimes? Like, programmatically, is that useful thing to be able to have, like, this thing that represents the change that's happening and you can, like, do stuff with it into it or ask it things.
Derrick Reimer:
Yeah. For sure. Like so I think in rails, we often would try to, like we'd sometimes build these, like, form objects that sort of, like, represented an abstract set of changes, you know? Right. Yep.
Derrick Reimer:
And that's basically what a change set is. So Yeah. Sometimes I build them just just to represent a collection of changes that ultimately affect, you know, several different, database tables. So, like, if I'm classic example for us in in SavvyCal, when a user signs up, they they give us name, first name, last name, and then the URL of their for their, like, kind of personal scope in SavvyCal. So, like, this this kind of registration form has fields that ultimately live on multiple multiple database tables.
Derrick Reimer:
There's, like, users table and a scopes table, and they're kind of related to each other. So I have this this change set that's sort of a it's an abstract change set. You know, it doesn't actually represent map directly to a database table. Yep. And I can take that user supplied input, run validations on it.
Derrick Reimer:
And if it is deemed valid, then I can pass what is already pre validated data into, change sets for each of those tables and persist those changes.
Ben Orenstein:
Interesting. Cool. Yes. Right when form objects are becoming quite popular is about when I'm bailed out of the rails world.
Derrick Reimer:
Yeah. So
Ben Orenstein:
Yep. That's the freshness in my mind. Yeah. So let's start with open source for a minute. You have open sourced some pieces of the SaviCal code base over the years, And you were tweeting recently that you're thinking about open sourcing the open graph image generation service.
Ben Orenstein:
Yeah. Which would be cool. How do you think about when to do that versus not? Like, you don't primarily, I think, sell to developers. So it's maybe the the the case is a bit weaker or different than usual.
Derrick Reimer:
Yeah.
Ben Orenstein:
For some companies, for, like, Oscar, for example.
Derrick Reimer:
Yep. It's a good question. I think I see open source contributions as really just, like, a good faith con contribution to the commons, you know. I mean, we benefit so much from open source software, like, the entire almost the entirety of SavvyCal is built on open source software. So I think those, you know, the the little packages we have let's see.
Derrick Reimer:
We have one for kind of our time zone logic. We've just, like, done a bunch of work cobbling together time zone data from different packages and sort of have, like, a unified unified way to to bundle all that up. And, it kind of felt like this feels library ish, and we already we already basically did all the work, for this in our application already. It's, like, relatively easy to just peel that away, and release it as a separate package. So I think a lot of a lot of the stuff we release is, like, it's not a ton of effort to do it, and it might benefit someone else.
Derrick Reimer:
And it's just generally kind of a a nice thing to do to contribute something back. The the Open Graph service, I feel like that's that's in that vein as well and also, like, kind of another opportunity just to, like, you know, get some attention from the community. I mean, there's a there's a marketing angle to it as well. Even though we don't primarily market to developers, I think we market to a lot of founders, and a lot of founders are, you know, it's particularly in the tech space, and that could be something that founders would appreciate. And, so there could be some a little bit of little bit of marketing there.
Derrick Reimer:
But, I mean, again, it's not it's not like a we wouldn't pin a whole lot on that. We wouldn't I don't necessarily have high expectations that it'll be a huge, you know, source of growth for us or anything. It's just it's just one more little thing to do.
Ben Orenstein:
Cool. Yeah. Yeah. And I I mean, I I loved your first answer of just, like, it's a good faith contribution to the comments. Awesome.
Ben Orenstein:
I'm convinced.
Derrick Reimer:
Yep.
Ben Orenstein:
I wanna live in a world where people think that way and do that.
Derrick Reimer:
Yeah. Because I I mean, I I'm amazed when I look at some of the projects that we rely on that are large in scale, but they're not so large that someone can be, like, full time employed to work on that thing. I'm just I'm just blown away that people are willing to spend their nights and weekends and maybe a little bit of time on the clock. But for the most part, their own free time just like maintaining these open source projects for sort of an indefinite period of time. I mean, it blows my mind.
Derrick Reimer:
And Yeah. I feel like I'm pretty selfish compared to that. Like, I'm mostly just taking I'm mostly just taking the open source projects and building stuff on them. So I don't know. It's my it's my little contribution I can make.
Ben Orenstein:
Yeah. It does feel it's kinda crazy. Like, you I don't think this is, like, a thing you might've you would've predicted if you'd known the things going into the, like, the the ingredients. It feels almost like a little bit of magic happened, and we shouldn't, like, look at it too closely or think about it too hard or ask too many questions because, like, something amazing happened, and it keeps working. And that's great.
Ben Orenstein:
Let's know just be careful.
Derrick Reimer:
Yeah. Yeah. I mean, I guess and I don't really know what fundamentally what are the incentives for someone who spends, you know, many, many, many hours a week maintaining a project for no monetary reward? Like, what's in it for them? You know?
Derrick Reimer:
And maybe it's just maybe it's just, I don't know. Do you have hypothesis on that? Like, what is it for
Ben Orenstein:
them? I think there actually is some status to be out there. Yeah. Like, if you are the the creator of a popular open source thing, that is Yeah. That's cred.
Derrick Reimer:
Some cred.
Ben Orenstein:
You are you are cooler than someone who doesn't do that in the circles that you probably care about. Yeah. You're gonna get invited to give conference talks that you wouldn't otherwise. Your coworkers might think you're more impressive otherwise. Yep.
Derrick Reimer:
Yep.
Ben Orenstein:
So I think there's some of that. But I think there's also, like, I think it's a probably a reasonably strong altruistic motivation. Like, you just actually do wanna be like, it it feels nice to be useful. And for people to be helped by something you did. I think that is just pleasurable.
Ben Orenstein:
And so seeing, wow, look at all these stars, look at all these downloads. Like, wow, I made something good. I think just actually does inherently feel pretty good, too. Yeah. Now I think overall, the amount of work that goes into the more popular things and the, like, the more complicated libraries.
Ben Orenstein:
I suspect that that eventually is not like, the the inherent rewards and the status boost are not enough anymore. And something, like, kind of special is happening there and or maybe, like, you're leading really hard on the altruism part or, like, maybe even just, like, inertia where it's like, well, I started this, and I feel like I kinda gotta keep it going. Yeah. So that's where I'm kinda like, wow. That that just kinda keeps working.
Ben Orenstein:
Interesting.
Derrick Reimer:
Yeah. Because there's a I mean, I've mostly just released small things, like, even before before I start releasing stuff from from kind of Savvy Cow, there's I had, like, a a Ruby Gem that's probably now at least 10 years old that helps you do, like, adding a a sequence number onto a model. So, like, think of, like, the GitHub issues, you know, how, like, they're scoped to a project and then it starts at issue 1 and goes to issue 2, and it naturally counts up. So it's not like a a global primary key that you're seeing there. It's a scoped sequence number for a particular, you know, particular scope.
Derrick Reimer:
And so I I had a use case for that 10 years ago. I can't even remember what project it was and released a a gem for that. And it still is in use today, But I'm a terrible maintainer because I don't even work with Ruby anymore. But I have there's a few people from the Ruby community who have stepped up to, like, help maintain it. And, that's kind of gone up and down on on activity, I guess.
Derrick Reimer:
But, but, yeah, it's like, it it's fun to to release something. I remember when I first released that and it got some uptake, like, it felt really good. But then a certain point, it comes down to, like, alright. Now it's either I can either spend the weekend, you know, hanging out with my wife or I can hack on this project and you can kinda and and a small library like this doesn't have a whole lot of issues and PRs being submitted on it. But if it was one where, like, every week, there's there's more issues, there's more effectively support tickets happening and more attempts to contribute.
Derrick Reimer:
That's just yeah. It's a lot of it's a lot of personal time you have to invest. Yeah. So I'm glad people do it.
Ben Orenstein:
Me too. Stop. Yes. Bless all of you. Mhmm.
Ben Orenstein:
Quickly or sort of sort of briefly, I at the top of the show, I introduced you as someone who is, like, developed, like, programming plus design chops. Recommendations for getting to, like, an MVP of design capability as a more technical person?
Derrick Reimer:
I would say so, Adam Wadden and Steve Schoger have a book called refactoring UI, And, I think I still have a testimonial quote on it that's like, this is the resource I wish I had when I was getting started. And I stand by that. I think it's a really good primer that's like, because I think that's what developers need is, like, a something that's not too theoretical. That's not too, like, art and design school, but it's, like, functional. Like, I think a lot of developers can become really good UI UX designers.
Derrick Reimer:
It it's a whole different beast to be like a graphic designer or an illustrator or something like that. Like, that feels like a whole different level of art, you know. But I think being able to snap together user interfaces and kinda develop sensibilities about, you know, how to place things and and how to make things usable, like, we can all be a bit introspective about, you know, encounters throughout our day where we interface with products. It doesn't even have to be necessarily software products. It could be physical products, you know, the buttons on your on your, washing machine or something.
Derrick Reimer:
And you you can just start to get a sense if you pay attention. Like, what makes sense about these things? What doesn't make sense about these things? What kind of kind of abstractions, translate? And I think I think a lot more people than they give themselves credit for can can develop proficiency for that.
Derrick Reimer:
I would say that's where my main strength is is in is in user interface stuff and primarily because I was just kind of a nerd about it. Like, I I grew up kind of looking closely at user interfaces and thinking, like, you know what? I could do this. I I think I know how to do this. And and then just and then just doing a bunch of it, you know?
Derrick Reimer:
So that's what I would say.
Ben Orenstein:
Cool. Awesome. Derek Reimer, thanks for coming by the podcast. It's good to catch up again after so long.
