Speaker 1: Hey, Welcome back to another episode of the Ruby Rogues podcast.
Speaker 1: This week, on our panel, we have Valentino Stole.
Speaker 2: Hey.
Speaker 1: Now, I'm Charles Maxwood from Top End Devs. I just
Speaker 1: wanted to do a quick call out AIDEV boot camp
Speaker 1: dot com. If you sign up within the next few weeks,
Speaker 1: I'm doing a forty five percent discount because I turned
Speaker 1: forty five on Saturday. And yeah, Bob's laughing. I'm going
Speaker 1: to take a little personal license here. So there's a
Speaker 1: political party I'm in county leadership, and we were talking
Speaker 1: about youth outreach and our party secretary is probably pretty
Speaker 1: close to Bob's age, and so we were chatting and
Speaker 1: we had like this twenty two to twenty three year
Speaker 1: old young woman who was talking to us about reaching
Speaker 1: out to younger people. And somebody goes, so, when we're
Speaker 1: talking about youth, who are we talking about? And he
Speaker 1: chimes in, and he goes and buddy under forty five.
Speaker 1: And so I felt young for like a week and
Speaker 1: a half and then I turned forty five. So anyway, Bill,
Speaker 1: now that's right, I'm old now. So anyway, we also
Speaker 1: have Uncle Bob Martin or Robert C. Martin as people
Speaker 1: know him. Bob, do you want to just say hello
Speaker 1: and let people know what you're up to these days?
Speaker 3: Hi? Yeah, what am I up to in these days? Well,
Speaker 3: I'm in the midst of writing the second edition of
Speaker 3: Clean Code. My publisher said, you know, you should do
Speaker 3: a second edition, and I thought that's probably a good idea.
Speaker 3: It's been about sixteen seventeen years. Yeah, So first draft
Speaker 3: is off to the publisher. They're going to send it
Speaker 3: out for review, then we'll do another scan through it,
Speaker 3: and I imagine we'll see it out mid next year.
Speaker 1: Good deal. You also released and this came up on
Speaker 1: the JavaScript Jabber Show and I was excited for it,
Speaker 1: and so we're definitely going to have you back on
Speaker 1: this show and that show to talk about it. But
Speaker 1: you released another book about historical programmers.
Speaker 3: We Programmers is the title of it. The publisher taught
Speaker 3: maybe we the Programmers was a little too much like
Speaker 3: the Declaration of Independence or the Constitution or something. So
Speaker 3: it's called We Programmers, which is a nice takeoff on
Speaker 3: Asimov's I Robot. I suppose it is a history of
Speaker 3: software programmers, starting with Babbage and then walking through the
Speaker 3: early twentieth century, early to mid twentieth century. So we
Speaker 3: get people like Dykestra and Hilbert and von Neuman and
Speaker 3: Touring and Grace Hopper and John Bacchus and of course
Speaker 3: the C Trio Dennis Ritchie and Ken Thompson and Brian Cernihan.
Speaker 3: And I focus on the technology. This is a book
Speaker 3: for programmers, So I talk about the machines themselves. You know,
Speaker 3: how many bits they were, their cycle times, what did
Speaker 3: the instructions look like, what kind of problems were they solving,
Speaker 3: how much memory did they have, what kind of memory
Speaker 3: it was.
Speaker 4: And I also focus a lot on the the personalities
Speaker 4: of the programmers, specifically their life struggles, because all of
Speaker 4: these people.
Speaker 3: Were human, and they were really interesting humans. They all
Speaker 3: had in the midst of this really deep technological struggle,
Speaker 3: they also had very human struggles. So it's a book
Speaker 3: about the human side of programmers, but with enough technology
Speaker 3: to attract the attention of programmers. So that's that's how
Speaker 3: the book goes.
Speaker 1: Yeah, well it's it's interesting to me just from the
Speaker 1: standpoint of yeah, I mean, they they're essentially doing what
Speaker 1: we do. The difference, I guess is that and this
Speaker 1: is the thing I like about good narratives, you know,
Speaker 1: a novel or whatever. Anyway is that you know, their
Speaker 1: challenges were different. They were inventing new ways of doing things.
Speaker 1: I guess the difference between some of the other books
Speaker 1: that I read in this is that we're, you know,
Speaker 1: unless it's a historical novel like this or you know,
Speaker 1: has to do with the past, right, we're still dealing
Speaker 1: with some of these things, or we benefit from the
Speaker 1: way that they invented to solve them.
Speaker 3: So it's easy to draw a line if you look
Speaker 3: at the technologies, and if you really dig into the technologies,
Speaker 3: it's easy to draw a line from there to hear right,
Speaker 3: And that line is this exponential curve which we called
Speaker 3: Moore's law back before Moore's law died. But it's very
Speaker 3: interesting to you look at the earlier mechanical machines, and
Speaker 3: then the electro mechanical machines, and then the vacuum tube machines,
Speaker 3: and then the transition machines, then the integrated circuit machines,
Speaker 3: and you can see this interesting curve. And the same
Speaker 3: thing happens with memory. You know, originally memory was just
Speaker 3: in gear positions, and then later on it was sound
Speaker 3: waves through tubes of mercury, and then it was charged
Speaker 3: dots on CRT screens, and then then finally it was
Speaker 3: core memory, real core, magnetic core, and then finally you
Speaker 3: know discs and solid state memory. So very very interesting
Speaker 3: and if you if you follow the deeper technology, you
Speaker 3: can see that thread really easy, and you can see
Speaker 3: the struggles of the hardware architects. They had no idea
Speaker 3: what programmers would needs. So the early machines had no
Speaker 3: way to call a subroutine, no way to store a
Speaker 3: return address, no way to uh anything on a stack. Right,
Speaker 3: the earliest machines had no jump instructions. They were just linear,
Speaker 3: linear steps and if you wanted to, if you want
Speaker 3: to have a loop, you would take the paper tape
Speaker 3: which drove the machine, and you would back it up
Speaker 3: and then let it run forward, and then you'd back
Speaker 3: it up again. Oh no way, yeah, yeah yeah, And
Speaker 3: the operators would have to check the registers to see
Speaker 3: whether or not the loop exit condition had been achieved.
Speaker 3: But you know, when you're only executting ten instructions a second,
Speaker 3: you can do that, and you know a good program
Speaker 3: will run for eighty hours with constant operator intervention.
Speaker 1: Well, I have to say, I'm living a charmed life.
Speaker 3: Yeah. Here we are communicating over the ancestors of these machines,
Speaker 3: you know, whipping bits around at a rather impressive rate.
Speaker 1: Yeah, that's amazing.
Speaker 3: Yes it is. Oh yes, exponential curves. Yeah, we have
Speaker 3: an effect over time.
Speaker 1: Yeah. Yeah, anyway, it's great stuff. I actually invited you
Speaker 1: to come on and talk about and it's this snippet.
Speaker 1: It's like, what three minutes, but it was it was interesting. Oh,
Speaker 1: tarras on on X says, so that's where you rolling
Speaker 1: your own loop comes from.
Speaker 3: Yes, they actually didn't do that. They would put the
Speaker 3: paper tape into a loop. They'd scotch tape it together.
Speaker 1: Yeah.
Speaker 3: Yeah, except one time they twisted it and then it
Speaker 3: was a mebias strip didn't execute.
Speaker 1: Well m m, all right, well let's dive in you.
Speaker 1: So this is this video. I don't know if you
Speaker 1: posted it or if somebody clipped it from a talk
Speaker 1: you gave, but.
Speaker 3: It's essentially from a talk. Yeah.
Speaker 1: Yeah, so music in the images that show up, and
Speaker 1: there's a guy that's massaging his temples.
Speaker 4: Right.
Speaker 1: Anyway, it's the problem with frameworks and what's interesting, you know,
Speaker 1: because we had a similar Ish conversation on Ruby or
Speaker 1: on JavaScript Jabber and so it'll come out probably around
Speaker 1: the same time as this one. What's interesting to me though,
Speaker 1: is that, like we you brought up Rails when we
Speaker 1: asked you about it, and then we like totally sidebarred
Speaker 1: into react and view and you know, and all the
Speaker 1: stuff there and trade offs with maybe he's Veldt or
Speaker 1: something like that, and the concerns that we're talking about.
Speaker 1: You know, the things our frameworks do for us in
Speaker 1: Ruby are I guess some ways similar, but in a
Speaker 1: lot of ways it's solving different concerns and different problems.
Speaker 1: And so I was kind of curious to see if
Speaker 1: we would have the same conversation here or if it
Speaker 1: be a bit different just from the standpoint. But uh,
Speaker 1: you know, you know, you know, just given the different technologies.
Speaker 1: So I keeping that in mind, I just kind of
Speaker 1: want to kind of let let you let it rip.
Speaker 1: You know what, what are the problems with frameworks, right?
Speaker 1: We all love ours.
Speaker 3: It was Rails that actually put me on this track, Okay,
Speaker 3: because I had been a tepid Rails programmer for a
Speaker 3: few years, you know, back when Rails was the big thing.
Speaker 3: I don't know what year, that was probably six or
Speaker 3: something like that.
Speaker 1: Yeah, about then that's when I got into it.
Speaker 3: Yeah, okay, So and I was diddling around with it,
Speaker 3: and I wrote a couple of applications for this or that,
Speaker 3: and then my son showed me an application that he
Speaker 3: had written, and I was just reading through it, and
Speaker 3: I noticed that the just the directory structure of his
Speaker 3: application yelled at me. It just said, ryls rails. I'm
Speaker 3: using Rails. And I thought, well, that's odd. Why is
Speaker 3: his directory structure so damned opinionated? And well, I mean
Speaker 3: that's because Rails is an opinionated frame, right, And that
Speaker 3: made me think, well, okay, should it be, or rather,
Speaker 3: should I allow Rails's opinionation to influence the structure of
Speaker 3: my application? Or should I make sure that I keep
Speaker 3: the opinionated structure of Rails at arm's length while I
Speaker 3: go ahead and use it. Can I keep all those
Speaker 3: opinions from leaking into my application and warping my application?
Speaker 3: And that's really what got me onto the thread of frameworks.
Speaker 3: And as I was thinking about that, I thought, well, okay,
Speaker 3: David is the author of Rails. David Hademeier Hansen, and
Speaker 3: he did it for his company. He did it for
Speaker 3: thirty seven signals, right, he did all that for him.
Speaker 3: He didn't do it for me. And the more I
Speaker 3: thought about it, the more I thought, you know, the
Speaker 3: more I commit to Rails, the more asymmetric this relationship becomes,
Speaker 3: because David is not making any commitment to me at all.
Speaker 3: He's not promising to maintain Rails in the direction I
Speaker 3: wanted to go. He's not promising to give me any
Speaker 3: features that I want. He's going to put in features
Speaker 3: that he wants, and if I like them, fine, If
Speaker 3: I don't, I can get lost. And he actually put
Speaker 3: you know, he went to a conference at one point,
Speaker 3: and he bunch of people at that conference, and up
Speaker 3: on the screen as he's standing there, right behind him
Speaker 3: were two words. The first one started with f androm.
Speaker 3: The second one started with why. And so I thought, yeah,
Speaker 3: I probably don't want to make a big commitment to
Speaker 3: an author who has no commitment to me. I don't
Speaker 3: mind using the stuff as long as I can kind
Speaker 3: of keep it at at some kind of a distance,
Speaker 3: build a little isolation layer, and prevent myself from being
Speaker 3: polluted and trapped in the uh In the opinionated structure
Speaker 3: that he is properly creating for himself.
Speaker 1: Yeah, it's it's interesting too. I'm just gonna kind of
Speaker 1: pile onto this idea a bit like if you go
Speaker 1: watch the last keynotes that that David gave at when
Speaker 1: we say David is DHH folks for the people that
Speaker 1: aren't following along.
Speaker 3: A guy, I hold him very high regard, by.
Speaker 1: The way, right, Yeah, I mean I've known David now
Speaker 1: for several years, and so I call him David, and
Speaker 1: I don't anyway, but he like, if you go watch
Speaker 1: the talks, right, he's talking about stuff that's terrific stuff, right,
Speaker 1: and it's like, oh I want that, Oh I love that.
Speaker 1: Oh I really But if you if you're paying attention
Speaker 1: to his talk, what he says is is, Hey, we're
Speaker 1: introducing this new thing and here's the problem. It's solved
Speaker 1: for us at base Camp, right, I mean, all every
Speaker 1: single thing it's and we had this problem at base
Speaker 1: camp and we solved it with this, and now you
Speaker 1: can use it too, right. And granted a lot of
Speaker 1: those are things that I want solved to and so
Speaker 1: I'm perfectly happy to pick them up. But but yeah,
Speaker 1: I mean the truth is is a lot of the
Speaker 1: stuff that ends up in Rails is stuff that they need.
Speaker 1: And then yeah, they do get contributions from other companies
Speaker 1: that have other concerns, and they'll they'll accept those, right,
Speaker 1: but you know, then it's solving some other person's problem
Speaker 1: that's can contributing to the framework. But the vast majority
Speaker 1: of the stuff that he goes up and announces, he
Speaker 1: basically says it, this solved this problem for us at
Speaker 1: base Camp.
Speaker 3: Yeah, and that's great. It's just maybe I can use
Speaker 3: that to solve my problem, and maybe there's a way
Speaker 3: that I can use it to solve my problem without
Speaker 3: making a gigantic commitment to it, without heerding from some
Speaker 3: base class that they wrote, or without you know, forcing
Speaker 3: my application to adopt the structure that they want.
Speaker 1: Yeah, Rails Magic, what do you think of Valentino.
Speaker 5: It's so it's hard because the structure of the application,
Speaker 5: if you're a contractor, as an example, a consultant, having
Speaker 5: that be the same for all of the applications that
Speaker 5: you have to look at is such a huge benefit, right,
Speaker 5: And having a lot of the things normalized, maybe not
Speaker 5: everything that reels normalized, but like the normality across like
Speaker 5: just like if you're looking at hundreds of applications right
Speaker 5: throughout a year, like you just save incredible amount of
Speaker 5: time and context, right, Like you don't have to rethink. Okay, well,
Speaker 5: uncle Bob today decided to use a different you know
Speaker 5: structure because you know maybe that it was a more
Speaker 5: appropriate design decision, right, But it's different than maybe some
Speaker 5: of the other ones that you know you more typically
Speaker 5: will take on. And so you have to like then
Speaker 5: have to reframe your thinking and gain regain context. And
Speaker 5: there is kind of developer loss across that. Uh even,
Speaker 5: but that's the trade off, right, Like you make that
Speaker 5: choice upfront, and it's your choice, right, So, but I
Speaker 5: mean thinking about bigger teams, like it becomes like really
Speaker 5: hard to like start like where do where do you
Speaker 5: see like in a larger team structure, like the value
Speaker 5: in like creating like the barrier to the framework, right,
Speaker 5: Like where where do you start to see Okay, like, uh,
Speaker 5: we have started to design our pieces of the application
Speaker 5: separate from the framework, Like when does that start to
Speaker 5: take off?
Speaker 4: Right?
Speaker 5: And where does where does that like really start to
Speaker 5: fit in the most obvious Well.
Speaker 3: I think that the first question that it would face
Speaker 3: is you know which framework should I use? Should I
Speaker 3: should I start with rails because a lot of people do, right,
Speaker 3: they just say, okay, we're just doing rails or whatever framework.
Speaker 3: It doesn't matter. I don't want to pick on rails
Speaker 3: too much here, Just you know, whatever the framework dujuur is.
Speaker 3: They'll say, Okay, let's try that because it's beautiful and
Speaker 3: it's gorgeous and we can go really fast. And is
Speaker 3: that the right decision to make up front? Or should
Speaker 3: you be thinking about? All right, we've got this application,
Speaker 3: and this application has a bunch of requirements, and we're
Speaker 3: going to need this kind of data storage, and we're
Speaker 3: gonna need this kind of computational structure, and what framework
Speaker 3: out there would help us with this? And is there
Speaker 3: a framework out there that would help us with this?
Speaker 3: Or maybe what we should do is write a little
Speaker 3: bit of it, get get a little bit of it going,
Speaker 3: and then see if there's a framework that fits into this.
Speaker 3: It would also be nice if the framework would be
Speaker 3: less demanding of commitment, like I'd like to use it
Speaker 3: off on the side, I'd like call it a little
Speaker 3: bit and I'd like it to be more of a
Speaker 3: library than you know, forcing forcing me to hand execution
Speaker 3: control over to it, and then it deigns to call
Speaker 3: me back when it needs to. I might want to
Speaker 3: maintain control of execution. I might, you know, or I
Speaker 3: might I might let it go. But I'd like to
Speaker 3: be able to make those decisions with enough information that
Speaker 3: I can do so in an informed way.
Speaker 1: So yeah, and this is this is kind of where
Speaker 1: you begin to lose me a little bit because I
Speaker 1: just I don't know, I don't know how you do this.
Speaker 1: I mean, do you pick up something simple like Sinatra
Speaker 1: or Rhoda or or or do you just start building
Speaker 1: the other pieces of your you know, maybe you build
Speaker 1: business logic, But I don't know, like, what's the approach
Speaker 1: here then to putting it off? Because yeah, rails gives me,
Speaker 1: like Valentino said, it kind of gives me a bookshelf
Speaker 1: and tells me where to put my stuff. Yeah, and
Speaker 1: it solves a bunch of stuff out of the gate.
Speaker 1: And so yeah, but at the same time, I really,
Speaker 1: you know, it sounds right, you know, especially you know,
Speaker 1: I kind of grew up programming under agile development stuff, right,
Speaker 1: And you'll never know as little now or as little
Speaker 1: as you do now. Kind of thing, And so if
Speaker 1: I can put it off and then realize, oh, you know,
Speaker 1: maybe Hanami or something else offers, you know, a different
Speaker 1: way to think about this that's more in line with
Speaker 1: what I want. But how do you do that? How
Speaker 1: do you start putting the pieces together without the framework? Then?
Speaker 3: Well, so frameworks solve a particular problem. They help you
Speaker 3: get things on the screen, they help they help you
Speaker 3: get things onto a disk, into a database of some kind,
Speaker 3: they help you talk through sockets. There's a whole bunch
Speaker 3: of things that frameworks allow you to do. But then
Speaker 3: you've got your application, and your application has other things
Speaker 3: that it needs to do. There's a reason that your
Speaker 3: application exists. There are business rules that don't have anything
Speaker 3: to do with the framework. They don't have anything to
Speaker 3: do with what's on the screen or what's in the database.
Speaker 3: None of that technology matters to the reason that the
Speaker 3: application exists. So you can create the core of an application.
Speaker 3: You can start with some business rules and you can
Speaker 3: just put those together. It's not hard to do. There's
Speaker 3: some calculations you've got to do, there's some perhaps some
Speaker 3: data storage you have to do, and don't you don't
Speaker 3: need to make a commitment to the screen or the database.
Speaker 3: You can build a little isolation layer that allows you
Speaker 3: to put things on a database, but without knowing what database.
Speaker 3: It is just a bunch of interfaces that you implement later.
Speaker 3: And there's some way to get things on the screen.
Speaker 3: You don't know exactly how you're going to get it
Speaker 3: on the screen, but you can at least arrange the
Speaker 3: data in a way that you know would eventually get
Speaker 3: on the screen. And you can do all of that
Speaker 3: without the framework without You can do it without a database.
Speaker 3: You can do it without any of the normal kinds
Speaker 3: of trappings that you would expect in an application. And
Speaker 3: then when you've got enough of it done, and it
Speaker 3: doesn't have to be the whole thing, obviously, but when
Speaker 3: you've got enough of it done, you look at it
Speaker 3: and think, Okay, what framework out there is really going
Speaker 3: to help me with this? I really need to get
Speaker 3: this on a web page. Maybe you haven't even thought
Speaker 3: about a web page yet, right, I really need to
Speaker 3: get this on a web page, and Rails is great
Speaker 3: at doing that. Maybe I should use Rails. But if
Speaker 3: I do use Rails, it would be really nice if
Speaker 3: I didn't have to pull all of that rails ecode
Speaker 3: to my application. Maybe I can put it all behind
Speaker 3: my isolation layer, and then I can call rails happily
Speaker 3: through my isolation layer and my application is not necessarily
Speaker 3: affected by rails. This is the way I like to
Speaker 3: start all applications. I like to start with the business
Speaker 3: rules first and then start feeling outwards and see how
Speaker 3: much how much of a framework I need. And in
Speaker 3: the last one, I told the story of Fitness, And
Speaker 3: in Fitness, you know, that was a web application. It's
Speaker 3: a wiki, and it's got a database, or at least
Speaker 3: we thought it would have a database. And we as
Speaker 3: we planned the whole thing out, we thought, well, we're
Speaker 3: going to need a web server, and there's a couple
Speaker 3: of open source web servers you could get. And didn't
Speaker 3: have a big framework in those days, but you know,
Speaker 3: the CANU project had a bunch of I think Apache
Speaker 3: had some web servers back in two thousand when we
Speaker 3: started this, and we thought, you know, maybe we'll get
Speaker 3: a database, and we had we thought we'd get my sequel,
Speaker 3: because you know, why wouldn't you, And then and then
Speaker 3: we just started building, but without any of that stuff.
Speaker 3: We just started building just and and what do you
Speaker 3: do with the wiki? The first thing you do is
Speaker 3: translate wiki text into HTML. Well, okay, that's pretty simple.
Speaker 3: Don't need you don't even need a web page for that.
Speaker 3: If you don't need a web server for that, all
Speaker 3: you need to do is look at the HTML. Uh.
Speaker 3: And if you want to get it up on a
Speaker 3: web page, it's awfully simple to get a browser and
Speaker 3: have it, you know, pull up from HTML from a
Speaker 3: flat file or something. So that was very simple. And
Speaker 3: at some point we thought, well, we've got to get
Speaker 3: it up. We got to talk to a browser, We've
Speaker 3: got to be able to talk to a browser. Something's
Speaker 3: got to serve these web pages that we're building. And
Speaker 3: we thought, well, let's let's go look at let's go
Speaker 3: look at the Apache thing. And then and then we thought, well,
Speaker 3: how hard is it to build a web server. Well,
Speaker 3: it turns out that's about three hundred lines of code.
Speaker 3: It's not very hard to serve a web page. Just really,
Speaker 3: all you're doing is opening up a socket and throwing
Speaker 3: stuff out of the socket. And we thought, well, why
Speaker 3: don't we just do that for the time being. You know,
Speaker 3: maybe we'll get Apache in there later, but for the
Speaker 3: time being We've got three hundred lines of code and
Speaker 3: it puts up web babes. It's just fine. And we
Speaker 3: kept on working on translating the markup. Eventually we needed
Speaker 3: a database, and we thought, well, we could get my
Speaker 3: sequel going, but be awfully simple to just store all
Speaker 3: these pages in a hash table, you know, and that
Speaker 3: kind of looks like a database from the outside looking in.
Speaker 3: You you can make calls against the hash table that
Speaker 3: looked like a database query. So we build a little
Speaker 3: interface that looked like a database query and put a
Speaker 3: hash table behind it, and kept on working and working,
Speaker 3: and we got the whole dog On program up and
Speaker 3: running old wiki and all of the stuff that it
Speaker 3: was doing, with lots of extra stuff that we were
Speaker 3: doing in fitness, and we didn't have a database, and
Speaker 3: we had our own little tiny web server. And then
Speaker 3: we thought, well, I mean, we got to get this
Speaker 3: stuff on discs somehow, because we can't just keep it
Speaker 3: in a hash table. And Michael Feathers was there at
Speaker 3: the time, and he just wrote a little thing that
Speaker 3: dumped it all out to a flat file, and now
Speaker 3: we had persistence. We didn't use my sequel for the persistence,
Speaker 3: and we didn't use apatche for the web server, and
Speaker 3: we put the whole dog On thing together. It's it's
Speaker 3: in one jar file and just turned it loose, and
Speaker 3: you know, people were using it and using it. I
Speaker 3: think it's still got a fairly significant user base today
Speaker 3: after twenty five years. So that that's a story of
Speaker 3: how I like to build from the inside out and
Speaker 3: feel my way towards the outside world.
Speaker 5: It's funny you mentioned it like that because I feel
Speaker 5: like from a real developer standpoint is like backwards where
Speaker 5: for sure, like you think about even just like the
Speaker 5: small design decisions where people you know, you'll create a
Speaker 5: service object which is just a class that like does
Speaker 5: one responsibility. But it's really like you have this design
Speaker 5: as a thing because like you have to do something
Speaker 5: separate from the framework, and there's form objects and all
Speaker 5: these different kind of objects that people have come up
Speaker 5: with to augment what they you know, to make their
Speaker 5: own thing kind of like to make a pattern out
Speaker 5: of like, you know something because almost like the framework
Speaker 5: is so like, uh, you know, opinionated, you want to
Speaker 5: make opinionated patterns, and so it does have like kind
Speaker 5: of that translating effect. But I like you're you're thinking
Speaker 5: of like boundaries for sure. I think like creating boundaries
Speaker 5: is like super important from like an applicant, like focusing
Speaker 5: on what like you're actually delivering for your users. That's unique, right,
Speaker 5: And like it's funny because like there's there's a Ruby
Speaker 5: gem called Packwork, you know, designed by Shopify, and if
Speaker 5: you haven't heard, it's like, uh, you know, a way
Speaker 5: of just like creating those boundaries in isolation within a
Speaker 5: real system, right, So it's like something that was created
Speaker 5: to snap into a Reels thing to isolate it from Reels,
Speaker 5: which is just a little bit funny because we're doing
Speaker 5: again working backwards and it's and it's super funny to
Speaker 5: me because like you know, this all comes from like
Speaker 5: every everything in Reels is built on Rack, which is
Speaker 5: like honestly a really great design framework because it has
Speaker 5: like at this bare minimum, it's just like you know,
Speaker 5: individual modules that you can drop or not write, and
Speaker 5: you can add and stack on however many you want,
Speaker 5: and all those individual pieces like uh you know, mutator
Speaker 5: or adjust the stack that it's in individually and in isolation.
Speaker 5: It's so it's easy to test, easy to swap in
Speaker 5: and out and I really like the design of RACK
Speaker 5: personally as a framework because it is like, you know,
Speaker 5: super modular, which is funny because reels is terms supposed
Speaker 5: to be modular, and a lot of ways it is
Speaker 5: you can start removing, you know, if you don't want
Speaker 5: active record for database, you don't have to use it.
Speaker 5: You don't have to just like use all the standards.
Speaker 5: And it's funny because like that was a common practice
Speaker 5: you know, in the early days of like even group
Speaker 5: on right, Like you would just like, oh, you have
Speaker 5: your your rails stack like explicitly defined in your setup
Speaker 5: and say, oh, yeah, I'm gonna use all of these
Speaker 5: things all the time. And now it's just like, well,
Speaker 5: we were just going to require reels and be done
Speaker 5: with it, and so it has kind of moved away
Speaker 5: from that. But I'm curious, like it when you're thinking
Speaker 5: about like, yeah, I just want to write something to
Speaker 5: disk and that works and that's fine. Like as like
Speaker 5: let's say like something became super popular and you started
Speaker 5: to have like a lot of people working on it
Speaker 5: and having to like get up to speed with all
Speaker 5: these individual like customizations, Like at what point where's the
Speaker 5: diminishing return there?
Speaker 4: Right?
Speaker 5: Like where is it, Like, Okay, we built all these
Speaker 5: custom things that people have to manage over time and
Speaker 5: make sure our secure and and things like that, Like
Speaker 5: where where do you stop? Like do you go down
Speaker 5: and like build compiler code? Like you know, like, uh,
Speaker 5: what is your reasoning on? Like you know, what is
Speaker 5: something worth like implementing custom versus like just adopted in
Speaker 5: the framework.
Speaker 3: Well, A lot of it for me, A lot of
Speaker 3: it is control. How much control do I have over
Speaker 3: the parts of my system? And if I if I
Speaker 3: surrender to a database plug in of some kind, like
Speaker 3: my sequel or something else, I lose control over that
Speaker 3: and that's now under somebody else's control. And I'm I
Speaker 3: am a I don't want to say I'm a slave,
Speaker 3: but I'm I am a subject to the whims of
Speaker 3: whatever they do. And that bothers me. So I want
Speaker 3: to I want to put a little isolation in there now.
Speaker 3: I'm not going to rewrite a compiler. I don't need
Speaker 3: a new language. I trust that the language is not
Speaker 3: going to do stupid things. And that's not always a
Speaker 3: good trust. I mean I left C plus plus, you know,
Speaker 3: and I left Java eventually too, because they you know,
Speaker 3: standards committees. As soon as the language gets into a
Speaker 3: standards committee, I think the end is in sight because
Speaker 3: they're just going to keep on going and going and
Speaker 3: going and adding more and more deluged crap into the language,
Speaker 3: and at some point you have to get a simple language.
Speaker 3: But for the like for fitness example, going back to
Speaker 3: the fitness example, we chose Java as the language because
Speaker 3: it was kind of the obvious choice in the day.
Speaker 3: And it's still all written in Java, and it's fine,
Speaker 3: everybody's happy with it. Okay, great, I'm not going to
Speaker 3: do another big project in Java because you know, it's
Speaker 3: it's way out of control at this point. So I
Speaker 3: look at that and think, I want to keep control
Speaker 3: over as much of this system as I can and
Speaker 3: relinquish as little control as possible. And I can do
Speaker 3: that by trusting the vendors that I get, like the
Speaker 3: Java language, and then building isolation barriers to all of
Speaker 3: the things I don't trust. Interesting, I don't know if
Speaker 3: that answered your question.
Speaker 5: I guess, so, I guess I'm My concern with like
Speaker 5: anything custom is maintenance costs, right, Like yeah, and so
Speaker 5: like that's the first thing I think about any time
Speaker 5: I create something new, that isn't like just some standard
Speaker 5: thing that most people know, it's all like what.
Speaker 3: Yeah. I think that happened to us with Fitness was
Speaker 3: that the amount of code that we had to invest
Speaker 3: in these things that you would normally do with a
Speaker 3: framework was minimal. I mean, the maintenance costs were almost
Speaker 3: non existence. We didn't need and in the end, we
Speaker 3: didn't need a relational database. We didn't know that upfront.
Speaker 3: Upfront we thought we would need one. In the end
Speaker 3: we didn't need one. And what does it take to
Speaker 3: take a hashtable and dump it out to flat files. It's,
Speaker 3: you know, not a lot of code. We didn't need
Speaker 3: a web server because we put one together. Three hundred
Speaker 3: lines of code, a lot of lot to maintain there.
Speaker 3: So one of the things that I've found is that
Speaker 3: if I'm careful about making these these framework like decisions,
Speaker 3: I may be able to replace the bulk of a
Speaker 3: framework with something much simpler that's easier to maintain than
Speaker 3: the framework is.
Speaker 1: So I'm just trying to think here then, because you know,
Speaker 1: somebody could listen to this and be forgiven for thinking,
Speaker 1: Oh so Bob's advocating that maybe we don't use frameworks.
Speaker 3: Yeah, no, that's not what I'm advocating.
Speaker 1: Right, So my question then is, okay, so what point
Speaker 1: do you consider adopting a framework, Because, as you said before,
Speaker 1: a lot of times people go in and it's like,
Speaker 1: I need a new web thingy that does whatever it
Speaker 1: is that I need done, and we use rails for
Speaker 1: everything else here, So we're just gonna stamp rails on
Speaker 1: it and go, and you're advocating for maybe a more
Speaker 1: measured approach where you solve some of the other problems. First, yeah,
Speaker 1: so what point in this life cycle do I go, oh, well,
Speaker 1: maybe you know, maybe I do need a framework, or
Speaker 1: maybe I don't need a framework.
Speaker 3: There's several several decision points there, right, First, so number
Speaker 3: one is you've maybe you've got a little bit of
Speaker 3: an application going, you haven't invested in a framework yet,
Speaker 3: You've got a few business rules cooking, and then you think,
Speaker 3: all right, you know, I need something to help me
Speaker 3: with X. Whatever XES might be putting things in the database,
Speaker 3: might be getting things on the screen, might be pushing
Speaker 3: things out to a service, whatever X is. I need
Speaker 3: help with this X thing. And if the first thing
Speaker 3: I would do is look at, well, how hard is
Speaker 3: this X? Thing to do myself. And if it's easy
Speaker 3: enough to do myself, you know, like writing a hash
Speaker 3: table out to a flat file, Well, I'm gonna do
Speaker 3: that first. Now, my my, my supposition there is that
Speaker 3: that won't last. And that, by the way, that's the
Speaker 3: way we felt about the fitness decision. We thought that
Speaker 3: the writing it out to a flat file is a stopgap.
Speaker 3: We thought we would still go to a relational database.
Speaker 3: We just never did. So that's the first thing is
Speaker 3: I would I would say, Okay, is there some way
Speaker 3: I can get close to this X thing that I
Speaker 3: need by doing something myself, something simple, something really stupidly simple,
Speaker 3: and that'll that'll give me more time, and I might
Speaker 3: have to go to a framework to solve X or
Speaker 3: maybe not. Now at some point you think, okay, I
Speaker 3: gotta get to the framework. I did this recently with
Speaker 3: another application I was working on. I was trying to
Speaker 3: stay away from a gooey framework and I didn't want
Speaker 3: to do it. I didn't want it. And then in
Speaker 3: the end I thought, okay, I just can't deal with
Speaker 3: all the little editing fields and the double clicking and
Speaker 3: the cursor blinking and all that stuff. I don't want
Speaker 3: to have to write all that code myself. I'm just
Speaker 3: gonna have to use a guy framework, and unfortunately I
Speaker 3: picked the wrong one. I picked Swing, and so now
Speaker 3: I'm gonna pickle. I don't have to get rid of Swing,
Speaker 3: tear it out of there and replace it with something else.
Speaker 3: But you do eventually you face that, right that there's
Speaker 3: this point where X you can't do X yourself. So
Speaker 3: now you've got two options. You know you're gonna have
Speaker 3: to use a framework. Do you commit to the framework
Speaker 3: and live with it forever, or do you isolate yourself
Speaker 3: from the framework. The mistake I made with Swing is
Speaker 3: that I did not properly isolate myself from Swing, because
Speaker 3: Swing is not an isolatable framework. If you use Swing,
Speaker 3: you have to commit to it, and so I committed
Speaker 3: to it, and now now I'm in a pickle. I've
Speaker 3: got to dump it and throw it away. But sometimes
Speaker 3: you can take a step into a framework but keep
Speaker 3: it isolated enough so that you can feel it out
Speaker 3: and defer the defer the commitment. Use it, but defer
Speaker 3: the commitment for a while, and you may find it
Speaker 3: that's sufficient, or you may in the end just say
Speaker 3: now there's no way I can do this without making
Speaker 3: a commitment. And I understand the cost and the risk
Speaker 3: of making the commitment, but it's worth it. And that's
Speaker 3: that's the chain of decision making that I wish people
Speaker 3: would make. What I see people do is say, Man,
Speaker 3: we got this new application to do, let's fire up rails. Guilty, Okay,
Speaker 3: I do that. Maybe maybe that's not the first decision
Speaker 3: to make.
Speaker 5: Yeah, I mean speaking to this though, like it's hard.
Speaker 5: So the whole like premise of like DAHG and the
Speaker 5: one person framework and rails is like the core principle
Speaker 5: is you know, as he states, conceptual compression, right like
Speaker 5: basically hiding away all the details that most people won't
Speaker 5: have to know so they don't have to know it
Speaker 5: and so like, because I know, like, especially as you're
Speaker 5: early on coding, even middle right like, it's hard to
Speaker 5: create abstractions, right Like, it's hard to choose the right naming,
Speaker 5: choose the right communication layers, right and so like these
Speaker 5: are very hard like design problems and challenges that most
Speaker 5: people will face. And it's easy to make mess right
Speaker 5: like if you start, especially if you start from nothing,
Speaker 5: like you can very easily Okay, And I'm just gonna
Speaker 5: make like I'm gonna start with just like a command
Speaker 5: line application and it's one script and it has five lines,
Speaker 5: and it's just gonna like I'll put standard out right
Speaker 5: and like that's the application, and like next thing, you know,
Speaker 5: you have, like you know, a thousand lines of code
Speaker 5: that's all like you know, entangled, and like you know,
Speaker 5: it's very easy to blow things up, and so like
Speaker 5: where like at what point do you like where where
Speaker 5: do you like recommend people like to look for like
Speaker 5: building better abstractions and like how to like make these
Speaker 5: design choices Like it's you know, you don't want to
Speaker 5: end up basically like designing up front too much, too right,
Speaker 5: Like how how do you find that balance?
Speaker 3: Well, I've been writing code for you know, well over
Speaker 3: fifty years. So for me, the creation of abstractions, I
Speaker 3: think he.
Speaker 1: Just said he's been coding longer than we've been breathing, Valentino,
Speaker 1: not collectively. I told you I'm forty five.
Speaker 3: But yeah, well so you know, make creating abstractions for
Speaker 3: me is a relatively simple thing. I can envision the
Speaker 3: system in my mind and see where all the pieces
Speaker 3: are and figure out the abstraction. It's not very difficult
Speaker 3: for me. I can imagine, however, that people who are
Speaker 3: much newer to programming find that to be something of
Speaker 3: a challenge. I remember that I certainly did when I
Speaker 3: was in my twenties, right that you know, made a
Speaker 3: lot of mistakes. And how do you deal with that?
Speaker 3: You get some old people on your team, is what
Speaker 3: you do. You get some guys who know what they're doing,
Speaker 3: and you have them be the team leaders, and you
Speaker 3: you know, you know they can be the fore man
Speaker 3: and they can say, okay, guys, you know we don't
Speaker 3: need to ruge. Yes, the framework is fancy and it's
Speaker 3: very nice, but let's try this one little thing first.
Speaker 3: See if we can. Can you see if we can.
Speaker 6: Slowly and any wisdom you can impart here on like
Speaker 6: maybe like what you're thinking is when you're like trying
Speaker 6: to like, let's say, like you have a task at
Speaker 6: hand that you know, you have this problem you're trying
Speaker 6: to solve, Like what's the first.
Speaker 5: Thing you start to do to maybe tease out what
Speaker 5: the abstractions are and how to model things.
Speaker 3: So there's a frame of mind that I like to
Speaker 3: put myself into, which is to find the underlying abstraction,
Speaker 3: and to find the underlying abstraction, you have to divorce
Speaker 3: the whole problem from detail. So you have to enumerate
Speaker 3: all the details. Now, the details are all enumerated in
Speaker 3: the requirements. When you get a bunch of requirements, what
Speaker 3: you are getting is a load of details, because that's
Speaker 3: what all the marketing people and all the business people,
Speaker 3: they're all writing down the details. And you have to
Speaker 3: look at this and you have to go, Okay, all
Speaker 3: these details are driving at something else, something core, and
Speaker 3: so one by one you subtract out the details and
Speaker 3: you envision where this thing is actually trying to go.
Speaker 3: So they you know, they'll give you a whole bunch
Speaker 3: of wireframes and the supposition, of course, is that this
Speaker 3: is going to be on a screen, and it's probably
Speaker 3: on the web, and they've got you know, Webby like buttons,
Speaker 3: and they've got Webby like scroll bars and dialogue boxes
Speaker 3: that would come up on a web and the requirements
Speaker 3: just look like it's web And then you say, okay,
Speaker 3: get rid of all these details. What is really going
Speaker 3: on in here? Bit by bit, you rip away the
Speaker 3: details one by one, and then you stare at what's
Speaker 3: left over and if you can, if you can describe
Speaker 3: the purpose of the application without using any of the detailed.
Speaker 2: Words the web page or the dialogue box, or the
Speaker 2: button or clicking or dragging, if you can, if you
Speaker 2: can say what this application does without mentioning any of
Speaker 2: those details, then you are close to the underlying abstraction.
Speaker 3: And then at that point you can start building back up. So, okay,
Speaker 3: now I get it. Now I know what this application
Speaker 3: is actually doing. I know the core loop, I know
Speaker 3: what the steps are inside, and now I can start
Speaker 3: to build it. And you know, maybe it shouldn't go
Speaker 3: on a web page, maybe it should go on something else.
Speaker 3: And maybe maybe we shouldn't store the data in Oracle.
Speaker 3: Maybe maybe it should go somewhere else. You know, maybe
Speaker 3: maybe this core idea is better implemented with a different
Speaker 3: set of details. But you can't get there until until
Speaker 3: you've gotten rid of all those details. And that that
Speaker 3: that just takes will and effort right to just stare
Speaker 3: at the problem and reduce it down to the barest
Speaker 3: bones and then then then re reinflated, but reinflated in
Speaker 3: a direction that is better for everybody.
Speaker 1: Yeah, well, it's it's interesting too, because I think you
Speaker 1: also one thing, well you you kind of said it
Speaker 1: when you started, But it's like when I'm helping my
Speaker 1: kids with their math homework. You know, Valentino asked, well,
Speaker 1: how do you how do you tease out those abstractions?
Speaker 1: And you said, well, I've been programming for fifty years,
Speaker 1: and you know, I help my kids with their math problems. Right,
Speaker 1: I'll look at it and I'll say that's wrong, right,
Speaker 1: and they're like, well, how did you how did you
Speaker 1: figure that out so fast? Well, I've been doing math
Speaker 1: for a really long time, and I've done it lots
Speaker 1: and lots of times, and so I think I think
Speaker 1: a lot of this is also just getting in solving
Speaker 1: these kinds of problems and doing a whole bunch of
Speaker 1: this dirty work and figuring out, oh, okay, when I
Speaker 1: see this, it means this, you know, you know, you
Speaker 1: start doing some of that mental pattern matching because you've
Speaker 1: you've done it so many times, right, and and so
Speaker 1: I think there's a lot there. But yeah, I love
Speaker 1: the approach that you outline, because yeah, a lot of
Speaker 1: times it is it's just down to grit and you know,
Speaker 1: moving away from those abstractions. Now I have to say
Speaker 1: that a lot of so the you know that you
Speaker 1: get the wireframe and all that stuff. See, I need
Speaker 1: you to come and explain to the clients that I
Speaker 1: often work with that the application is not the wireframe,
Speaker 1: because I'll tell you when I show up to a
Speaker 1: stand up meeting or a demo meeting, they want to
Speaker 1: see all of the stuff that you told me to ignore. Yeah,
Speaker 1: and so how do you balance this, right? How do
Speaker 1: you balance out the Okay, this is an app that
Speaker 1: does X, Y and z, right, Like, right now, I'm
Speaker 1: working on an app that tracks transactions and does a
Speaker 1: whole bunch of math for hedge funds right at its core. Right,
Speaker 1: But if they don't see the stuff on the screen,
Speaker 1: then they aren't happy people. And so how do you
Speaker 1: balance that out?
Speaker 3: Well?
Speaker 1: Right, because they want the rails stuff that, right, all
Speaker 1: that stuff that I got from my framework they want
Speaker 1: it now.
Speaker 3: Well, yeah, they think they want it because that's how
Speaker 3: they envision it, right, right. They have a vision of
Speaker 3: it and they're envisioning it that way, which is fine.
Speaker 3: And one of the ways you can One of the
Speaker 3: ways you can do that is to give them glimpses. So,
Speaker 3: for example, one of the things that we did long
Speaker 3: long ago, is we used Fitness. Fitness is a an
Speaker 3: acceptance testing frame. So you enter data into tables and
Speaker 3: it'll send that data into your application, and then it
Speaker 3: will compare that with the results that are in the
Speaker 3: table as well and see if you pass or fail.
Speaker 3: So you pose a test as a set of table data.
Speaker 3: And what's interesting about that is that since it's a wiki,
Speaker 3: you can change the data in the table. So a
Speaker 3: very nice thing to do for marketing people and users
Speaker 3: is to give them an interface like that where all
Speaker 3: the calculations are being done, and then you give them
Speaker 3: a simple interface something like Fitness or something else doesn't
Speaker 3: really matter, and let them fiddle. And they could see
Speaker 3: they can see the actual business rules executing, which is
Speaker 3: really what they want to see. They want to see
Speaker 3: the business rules executing, right. They understand that if the
Speaker 3: form is a little different, it doesn't matter. They want
Speaker 3: to see the business rules executing. They gave you wireframes
Speaker 3: because they thought that was the best way. They also
Speaker 3: have another viewpoint, which is the customer outward looking viewpoint.
Speaker 3: They think that these wireframes are the best way to
Speaker 3: communicate with the customer. Yes, fine, fine, but let's make
Speaker 3: sure that we're doing the calculations correctly first, and oh, look,
Speaker 3: we'll just put it up on some dumb little thing.
Speaker 3: We don't have to invest in a horrible framework. We
Speaker 3: can just toss it up and look at it, and
Speaker 3: you can fiddle with it and play with it and
Speaker 3: see if we're doing that part right, because let's get
Speaker 3: that part right first, and then we can figure out
Speaker 3: how to get it upon the screen with all the
Speaker 3: dragon drop booy stuff, and maybe, you know, maybe by
Speaker 3: then your ideas will change about how that ought. Just
Speaker 3: look to the customer. One of the things about details
Speaker 3: is the details are the things that change the core.
Speaker 3: Business rules don't, but they don't very much. But all
Speaker 3: those core deats, all those details, all those things that
Speaker 3: are on the wireframes, all those things that are in
Speaker 3: the requirements, they are the things that change the most frequently.
Speaker 3: So you want to kind of get them outside of
Speaker 3: the of the core so the core can remain safe
Speaker 3: from the volatility out here.
Speaker 1: Right. This kind of reminds me of the talk. I'll
Speaker 1: have to go find it, booz. I think it was
Speaker 1: Gary Bernhardt that talked about having the He talked about
Speaker 1: having the core of his app and then he had
Speaker 1: all the yep, and I think somebody else talked about
Speaker 1: some of the similar ideas with like hexagonal architecture and
Speaker 1: things like that.
Speaker 3: Yeah, it's all part of it. Yeah, all these architectures,
Speaker 3: we all have the same general idea. Hexagonal architecture, clean architecture,
Speaker 3: ports and adapters, all of them have the same basic idea. Right,
Speaker 3: get the details out here because they're vulnerable, Get the
Speaker 3: business rules in here because they're not vulnerable. And these
Speaker 3: are the family jewels here, you want those, right, everything
Speaker 3: else out here, well, you can fiddle it that.
Speaker 1: Yeah.
Speaker 5: So I want to quickly talk about framework speed, right,
Speaker 5: Like one of the biggest points of using a framework
Speaker 5: is just like speed of development, right, because you have
Speaker 5: all these normalizations. Everybody's familiar with all the things, and
Speaker 5: you can tie into all the framework things that they
Speaker 5: you know, are their opinionated. Just go with the opinions
Speaker 5: and you can skip a lot of steps.
Speaker 3: Yep.
Speaker 5: So, like how can we start to like simultaneously create
Speaker 5: the barriers without reducing that speed, or like how can
Speaker 5: we keep up the speed at the same time? Like
Speaker 5: at what point do you say, I mean obviously for
Speaker 5: like the business rules, it makes sense to slow down
Speaker 5: because those are the most important. But I mean next
Speaker 5: to that, like, once you have those like isolated and resolved, Like,
Speaker 5: at what points do you make those trade offs to
Speaker 5: slow down?
Speaker 3: Well, okay, you're saying you're saying something that I'm not
Speaker 3: quite sure is the premise is correct, Like you like
Speaker 3: slowing down. So I don't think there's a problem with
Speaker 3: using a framework as long as you can touch it lightly. Right.
Speaker 3: So let's say that you've got some business rules and
Speaker 3: you think they're pretty good, and you want to get
Speaker 3: those up on a screen, and you don't want to
Speaker 3: invest in writing your own screen stuff. So you think, okay,
Speaker 3: I'll use this framework, but I'm going to use the
Speaker 3: framework lightly. I'm not going to dive in and do
Speaker 3: every fancy thing that the framework is allowing me to do.
Speaker 3: I'm going to just get some dumb stuff on the
Speaker 3: screen without a lot of nonsense for the moment. Now,
Speaker 3: that doesn't take you a lot of time. It's not
Speaker 3: going to stop you. It's not going to slow you down. Right,
Speaker 3: It's going to give you and your customers information that
Speaker 3: they can then use to take the next step. And
Speaker 3: at the next step, you think, well, that next step
Speaker 3: is probably going to make me do a bigger commitment
Speaker 3: to the framework. Is there some way I can isolate
Speaker 3: myself or do I just have to decide to make
Speaker 3: the commitment to the framework and live with that commitment.
Speaker 5: Let me let me sure you're an example of like
Speaker 5: the of a slowdown from isolation. Right, Like, so, let's
Speaker 5: say somebody has a task and they wanted to create
Speaker 5: a quick store. They didn't want to use active record,
Speaker 5: they didn't want to store in a database completely understandable,
Speaker 5: and basically what they've built starts to evolve into a
Speaker 5: more complex storage solution where it starts to be more
Speaker 5: complicated to understand. As an example, right like, let's say
Speaker 5: they're storing everything as a hash and you know you
Speaker 5: have to like have multidimensions in the hash to make
Speaker 5: sense of the data that's relational, and it starts to
Speaker 5: become more complex for other people to come in and
Speaker 5: understand it rather than just like a single person. So
Speaker 5: that's just like one small example of like a slowdown.
Speaker 5: Right It's like creating some unfamiliar territory in an abstraction
Speaker 5: that at the time was maybe a good choice, but
Speaker 5: has evolved to something that now is more complicated. Like,
Speaker 5: I know for you, it's probably easy to see that, oh,
Speaker 5: like this is becoming this is taking on too much
Speaker 5: at a certain point in your abstraction. Right, how do
Speaker 5: you like, how do you surface these things across your team?
Speaker 3: Right?
Speaker 5: Like, is it just like peer review is enough or
Speaker 5: are there like planning steps that you take to prevent it?
Speaker 3: Well, peer review would be a good thing to do,
Speaker 3: especially if you've got some experienced people on the team.
Speaker 3: Better than peer review would be pair programming. Right, So
Speaker 3: if you've got an experienced guy and he sits down
Speaker 3: with a younger guy, and the younger guy has been
Speaker 3: doing this this clever little data thing, you know. Look, look,
Speaker 3: I didn't use the database. I did this instead. I'm
Speaker 3: using name value pairs everywhere, and it's just so cool.
Speaker 3: And the experienced guy sits down with that and says, yeah,
Speaker 3: that is pretty cool. And now let me tell you
Speaker 3: what bad thing is going to happen to you because
Speaker 3: you're doing that. And let's see if we can construct
Speaker 3: an interface between what you've done and what the application
Speaker 3: is so that in the event that we need to
Speaker 3: get away from your clever little name value pairs, we
Speaker 3: can actually use a different structure. This is architect level stuff, right.
Speaker 3: Somebody who is they've got ten years of experience, fifteen
Speaker 3: years of experience, and they can look at what is
Speaker 3: going on and say, hmm, yeah, we need to protect
Speaker 3: ourselves and rearrange this a little bit. Most of the
Speaker 3: questions you've fired at me are I could rephrase as
Speaker 3: how do I deal with the fact that everybody here
Speaker 3: is under twenty five? Okay? And you know there's just
Speaker 3: no good way to do that. It's important to have
Speaker 3: people on the team that are experienced enough to prevent
Speaker 3: the prevent the problems. Now. One of the problems with
Speaker 3: making the commitment because at some point you may have
Speaker 3: to decide I'm going to commit to this framework. I'm
Speaker 3: going to live with that. But one of the things
Speaker 3: you need to be able to foresee when you make
Speaker 3: that commit is just what kind of an impediment the
Speaker 3: framework is going to be? What things now that you've
Speaker 3: made the commitment, what things is it going to work
Speaker 3: against me? At? What things will it prevent me from doing?
Speaker 3: And that's a significant issue because as applications grow and
Speaker 3: as they get more complicated, the initial help that the
Speaker 3: framework gives you will often turn into a drag, something
Speaker 3: that slows you down. Then now you've made the commitment,
Speaker 3: you're going to be slow, and the more you want
Speaker 3: to do with it, the slower you're going to get
Speaker 3: because it's fighting you at every turn. The opinions of
Speaker 3: the framework are no longer the opinions of the application,
Speaker 3: but you're stuck with the opinions of the framework. So
Speaker 3: when you make that decision to commit, make sure you're
Speaker 3: looking ahead far enough so that it's like, Okay, this
Speaker 3: application really is going to go in the direction of
Speaker 3: the framework for the next five years. Uh, and we're
Speaker 3: not going to run into any of these impediments. That's
Speaker 3: a tough decision to make. Again, that takes somebody with
Speaker 3: a few years experience.
Speaker 1: Yeah. One thing that's interesting because you're you're talking about
Speaker 1: this and this kind of came to mind. I don't
Speaker 1: know if it makes the point perfectly, but it illustrates
Speaker 1: it to a certain degree. So, like I said, I'm
Speaker 1: working on this application that you know, manages a hedge fund,
Speaker 1: and so when you import transactions into it from another system,
Speaker 1: you know, through a CSV or you know, some third
Speaker 1: party API, it has to recalculate the you know, the
Speaker 1: basically the balance sheet for the hedge fund. And at
Speaker 1: a certain point they were using all the railisms in
Speaker 1: the app and it was super slow. It took forever
Speaker 1: to calculate all those calculations right to work through all
Speaker 1: the transactions, and you know, because it had to tally
Speaker 1: stuff at each transaction. And so I started looking at
Speaker 1: it and started working with it, and realized that I
Speaker 1: could do a lot of the work in the database, right,
Speaker 1: so I was moving out of the framework. The problem
Speaker 1: that I ran into was that rails it does give
Speaker 1: you this nice interface to say, here's a sequel string,
Speaker 1: do stuff, But then I was in this world of
Speaker 1: I've got this really complicated sequel string that I've got
Speaker 1: to manage, and the framework didn't really help me with
Speaker 1: it at all. And then also figured out that a
Speaker 1: lot of the stuff I wanted to do was with
Speaker 1: just common table expressions, which is a feature in postgris cool,
Speaker 1: and that it had been brought into later versions of
Speaker 1: the framework. So now all of a sudden, if I
Speaker 1: want to use this version, I've got to I've got
Speaker 1: to update, and I've got to adopt all the other
Speaker 1: things to get to the newer version. And so that's
Speaker 1: where some of this stuff came to light for me, right,
Speaker 1: And so there's all kinds of other stuff that I
Speaker 1: am doing super fast because I'm so familiar with rails, right,
Speaker 1: And I think, you know, just to point it out,
Speaker 1: we're not bagging on frameworks. We're just saying there are
Speaker 1: trade offs you have to make if you're going to
Speaker 1: use them. And so in this case, now, yeah, I'm
Speaker 1: making another commitment to another version, and I have to
Speaker 1: take on everything else that comes with the new version
Speaker 1: of the framework. You guys are real quiet, like I
Speaker 1: either said something brilliant or dumb.
Speaker 3: So you stated in an undeniable truth that does happen.
Speaker 3: And I've seen that kind of thing happen more than
Speaker 3: one time, where you get involved with the framework and
Speaker 3: it's great for the first three months, and then the
Speaker 3: next three months it's like and then the three months
Speaker 3: after that is like help.
Speaker 1: Yeah, but in this case, it's not in my way.
Speaker 1: It just doesn't offer what I need. And in order
Speaker 1: to get what I think I need, I've got to
Speaker 1: make another commitment.
Speaker 3: Yes, yeah, and rearrange a bunch of stuff. So then
Speaker 3: you've got to solve.
Speaker 1: What I'm trying to get.
Speaker 5: Yeah, this brings up a great point about dependency management, right,
Speaker 5: and like taking on new dependencies in general, like obviously
Speaker 5: has to be weighed. But like, I guess my biggest
Speaker 5: thing that I still struggle with is how do you
Speaker 5: say something that you're trying to integrate and use just
Speaker 5: because you don't understand how it all works and it's
Speaker 5: going to take too much time to tease that apart, right,
Speaker 5: Like I don't build rockets. I'm not going to buy
Speaker 5: a rocket engine and take it apart and like replace something, right,
Speaker 5: because it's gonna take too much time to learn all
Speaker 5: that stuff, right yeh. So and sometimes using a dependency
Speaker 5: gives it affords you that ability, right, and it's a great,
Speaker 5: great tool to use.
Speaker 3: So I guess what I'm getting on is like how do.
Speaker 5: You weigh those things when you're trying to reason about
Speaker 5: the framework? And that this framework is great to use
Speaker 5: because it solves these things that I don't have time
Speaker 5: to reason about, Like do you weigh that as part
Speaker 5: of your design choices or do you try and just
Speaker 5: focus on where your limits are first and then circle
Speaker 5: back to the framework, like you know, where's the cutoff.
Speaker 3: Where's the cutoff? Well, obviously this is a judgment call,
Speaker 3: and the judgment requires some experience. But you know, if
Speaker 3: I'm going to embark upon a real simple app and
Speaker 3: I know it's simple, and I know it's not going
Speaker 3: to be and it's not going to grow over the years,
Speaker 3: it's just going to be a nice, simple little thing,
Speaker 3: and there's a framework out there that just does that.
Speaker 3: I'm going to use that framework. I'm going to make
Speaker 3: a commitment to the framework. I'm gonna use it. And Okay,
Speaker 3: I'm pretty sure that application is not going to grow.
Speaker 3: I could get burned by that decision, but it's not
Speaker 3: going to grow. It's fine, and you know, nine times
Speaker 3: out of ten that'll be the right choice. Then then
Speaker 3: you come up with another application. This application. The guys
Speaker 3: asking for this are serious. They're they're looking ten years
Speaker 3: down the line and they want they want some significant
Speaker 3: stuff done. And so then you think, okay, I could
Speaker 3: get the first year going and really easy with the framework,
Speaker 3: and then after that they'd probably be hell to pay.
Speaker 3: That might be the right decision, might be the right
Speaker 3: decision because you've got time to market issues and startup
Speaker 3: issues and stuff like that, but it might not be
Speaker 3: the right decision. It's worth thinking about that one. It's
Speaker 3: worth saying, Okay, you know, maybe there's a shorter path
Speaker 3: to get to a high value, high value first release
Speaker 3: without making a commitment to something that is going to
Speaker 3: really hurt me a year or two down the line. Now, again,
Speaker 3: all that's just all judgment call. But the first thing
Speaker 3: you want to do is make that judgment call. Put
Speaker 3: it in your head that you're going to make the
Speaker 3: judgment call, and then you're gonna have to live with it.
Speaker 3: The thing you don't want to do is just say, Yep,
Speaker 3: we're going to the framework. No thought, just framework. That's
Speaker 3: what you don't want.
Speaker 5: Yeah, make the decision to follow that up. Like, you know,
Speaker 5: are there things in frameworks that lead you there?
Speaker 4: Right?
Speaker 5: Like are you looking at problems and being like, yeah,
Speaker 5: this framework would be perfect for this thing because of X, Right, Like,
Speaker 5: are there obvious draws to you for you know, some
Speaker 5: frameworks for some purposes?
Speaker 3: Well sure, I mean the demo applications are often very evocative.
Speaker 3: So you look at the demos and and you think, oh, yeah,
Speaker 3: it's exactly what I want to do. And I don't
Speaker 3: think I'm ever gonna want to do more than that.
Speaker 3: You know, why wouldn't I use the framework? Of course,
Speaker 3: I'm going to use the framework at that point, once
Speaker 3: I've made you know, once I've been a little bit
Speaker 3: careful about it. Exactly a good thing to do with frameworks,
Speaker 3: you guys. This doesn't apply to you, guys, but a
Speaker 3: good thing to do with frameworks is just to get
Speaker 3: a framework and write a dumb app, just so that
Speaker 3: you know, you know how how easier hard it is
Speaker 3: for that first puncture, and then then you can help
Speaker 3: that will help you make some decisions as well. You
Speaker 3: guys are long past that. But some people who are
Speaker 3: new and thinking, oh, let's just get you know, whipped
Speaker 3: you do framework out here, and it'll just be perfect.
Speaker 3: Write a couple of apps, little things, just throw away apps,
Speaker 3: just so that you know.
Speaker 1: Yeah, I was going to say, you know, essentially, the
Speaker 1: point that I think both of you are making is
Speaker 1: knowing that you're going to have to make this judgment
Speaker 1: call at some point, right whether or not to pick
Speaker 1: up a framework or a particular framework. Yeah, you can
Speaker 1: take steps to say what do I need to know
Speaker 1: in order to make the right decision, and so then
Speaker 1: it gets into yeah, what do I need to know
Speaker 1: about the framework? What do I need to understand about
Speaker 1: my application and the problems I'm trying to solve, and
Speaker 1: then you can kind of get them to you know, Okay,
Speaker 1: I got this point information and this point of information,
Speaker 1: and I still need a little bit more information here
Speaker 1: and right. So then you start getting closer to being
Speaker 1: able to make a decision one way or the other,
Speaker 1: and the decision may be not yet.
Speaker 5: Yeah, so yeah, yeah, I was semi hopeful with all
Speaker 5: these new AI generator things. As an example, Bolt dot
Speaker 5: new right, like you just say, you give them all
Speaker 5: your the requirements and then they're just like, you know,
Speaker 5: it can help get your demo app ready. Obviously there
Speaker 5: are some dangers there long term vision mind. Yeah, as
Speaker 5: we've outlined here, you know, are there any like is
Speaker 5: there any path to like something in the middle there
Speaker 5: that can help you get and gather the requirements to
Speaker 5: the more modular steps that you need to take rather
Speaker 5: than all at once kind of thing.
Speaker 3: So the application that I've been working on for the
Speaker 3: last couple of years is a it's a a browser
Speaker 3: for a social network. And I started on this and
Speaker 3: I thought, okay, I really don't want to get a
Speaker 3: gooe framework in here. So I found some dumb little
Speaker 3: thing helps me do graphics on the screen. It's really
Speaker 3: low level, you know, like I can put a dot here,
Speaker 3: I can put a character there. It doesn't have any
Speaker 3: dialogue boxes or editing or anything like. This is really
Speaker 3: bare bones. And I I started using that, and you know,
Speaker 3: I was able to get some stuff on the screen.
Speaker 3: But the problems that I needed to solve, we're not
Speaker 3: getting things on the screen. The problems I needed to
Speaker 3: solve were all these web socket things. I had dozens
Speaker 3: of web sockets and I had to be able to
Speaker 3: turn them on and turn them off. And I needed
Speaker 3: to be able to unpack and pack these packets, and
Speaker 3: there was all kinds of cryptography gunk going on. So
Speaker 3: I spent a lot of time on that, and then
Speaker 3: I could get, you know, a couple of words on
Speaker 3: the screen, and I thought, oh, it's really cool. You know,
Speaker 3: I'm actually receiving messages and I can send messages and
Speaker 3: now look at that. And then then I needed to
Speaker 3: edit them, and you know, editing stuff on the screen.
Speaker 3: That's a nightmare. I did not want to write, you know,
Speaker 3: inside Macintosh again, I did not want to write the
Speaker 3: whole gooey framework. And that's when I chose Swing. I
Speaker 3: made this. I made this decision, and it was the
Speaker 3: decision to commit, and I made it based on the
Speaker 3: fact that a lot of other apps had committed to Swing. Okay, probably, okay,
Speaker 3: I can commit to Swing. I already had the guts
Speaker 3: of it, right, I had all the web socket stuff,
Speaker 3: and I had all the fancy decryption and all that
Speaker 3: stuff was going on. I just needed to bolt Swing
Speaker 3: on and I had a nice isolation barrier and the Okay,
Speaker 3: I can probably slip this in. No, there's just no way.
Speaker 3: Swing is just so horribly opinionated, and I've fought through
Speaker 3: that for a year. Just made the wrong choice, wrong
Speaker 3: judgment call. I just can't go on with this application.
Speaker 3: I'm going to have to rip Swing out and replace
Speaker 3: it with something better. And that's going to happen to
Speaker 3: all of us. You know, we are all going to
Speaker 3: make the wrong judgment call and find out about it
Speaker 3: a year later. That's just the way software is. And Okay,
Speaker 3: you've got to kind of look look at that with
Speaker 3: clear eyes and realize, Okay, I'm going to make this
Speaker 3: call and I hope it works out. It might not,
Speaker 3: but don't make call frivolously, right, right, So just use
Speaker 3: the amount of information you got solved. There's an old
Speaker 3: saying it and it comes out of God, where was it?
Speaker 3: I think it was the moon is a harsh mistress.
Speaker 3: Do you ever read that book?
Speaker 5: That's a great book.
Speaker 3: Let me tell you a little story about that one before.
Speaker 3: But in that book there is a quote, and the
Speaker 3: quote is, when faced with something you don't understand, do
Speaker 3: any part of it you do understand, and then look
Speaker 3: at the overall problem again, which is just the basic incrementalism.
Speaker 3: Step right, break it into increments. Don't leap into the
Speaker 3: whole thing. Break it into increments, Solve little bits that
Speaker 3: you do understand or or that you have a chance
Speaker 3: of understanding, and then you can look out order a
Speaker 3: little bit and it'll look different.
Speaker 1: Yeah.
Speaker 3: Great advice.
Speaker 1: Yep. All right, Well I'm gonna push us the pics. Okay,
Speaker 1: this has been so good, Yeah, Valentino, do you want
Speaker 1: to start us off?
Speaker 3: Sure?
Speaker 5: Yeah, all my pics today. I have some awesome coworkers
Speaker 5: and they've been releasing some open source stuff, so I
Speaker 5: wanted to share what they've been working on because it's
Speaker 5: pretty pretty fun stuff. The first one comes from my
Speaker 5: coworker Jordan. He created this gem called Reprise and actually
Speaker 5: uses Rust to make a performance like schedules. So like
Speaker 5: if you use a gem called ice Cube or something
Speaker 5: like this, lets you like define ranges and and have
Speaker 5: like a schedule object that can iterate over things really quickly.
Speaker 3: Uh.
Speaker 5: And he he built it uh using like a Rust
Speaker 5: toolkit that snaps in to the Ruby subsystem called Magnets,
Speaker 5: which is pretty sweet, uh to solve the specific problem.
Speaker 5: Really cool jem. The other one is uh I co
Speaker 5: worker David. He created this uh, this reapol a long
Speaker 5: time ago called Octo.
Speaker 4: UH.
Speaker 5: That's like a knowledge management app that you run locally
Speaker 5: on your system and it's just like really fully featured,
Speaker 5: has and then encryption encryption support, and it's cross platform
Speaker 5: and has all kinds of crazy support in there, and
Speaker 5: you can think of it kind of like Obsidian or
Speaker 5: something like that, but fully open source.
Speaker 3: Uh.
Speaker 5: And the last one is something I haven't gotten to
Speaker 5: play with yet.
Speaker 3: Uh, but.
Speaker 5: My coworker Rob he created this thing called Cambian and
Speaker 5: it's basically a way to configure come all and set
Speaker 5: it up really easily on a Buntu and Debian systems,
Speaker 5: So it's like a configuration tool for comal to just
Speaker 5: make it easy. So that's that's really neat as well.
Speaker 1: Awesome, all right, I'm gonna jump into mine at some
Speaker 1: of those. Am gonna go try out? By the way,
Speaker 1: that's like, oh, I'm working on that. So the first
Speaker 1: one I'm gonna pick. I always do a board game.
Speaker 1: The one that I've been playing with my friends lately
Speaker 1: is Heat and it's a racing game. So your marker
Speaker 1: on the board is race car. The cargoes around the
Speaker 1: track at different points, you get to a curve, and
Speaker 1: if you take the curve too fast, right, so if
Speaker 1: it's like a two curve, and the way you move
Speaker 1: is you you put down cards face down. Everybody does
Speaker 1: this at the same time, and then you just go
Speaker 1: from the front of the pack to the back, and
Speaker 1: everybody flips their cards over and then moves however many
Speaker 1: they put down, and there's some factors in it that'll
Speaker 1: make you go faster or slower. Right, you can put
Speaker 1: one down that you flip cards until you get, you know,
Speaker 1: a card with a mark on it, and then you
Speaker 1: go that many. So if you go around the curve
Speaker 1: too fast, then you take on that much heat. So
Speaker 1: if it's a two curve and you go six, you
Speaker 1: take on four heat. If you run out of heat
Speaker 1: in your engine, then you spin out and you basically
Speaker 1: have to go back to the curve and take the
Speaker 1: curve at a decent speed, and at that point you
Speaker 1: can't go over because you're out of heat in your engine.
Speaker 1: There are ways to cool off, a lot of catch
Speaker 1: up mechanisms that made it a lot of fun. But yeah,
Speaker 1: I mean, that's essential the the crux of the game, right,
Speaker 1: and you can you can draft and then pass other cars.
Speaker 1: You can. I mean, there there are other rules, and
Speaker 1: there are like four or five racetracks. There are game
Speaker 1: boards that come in the in the game. It's really
Speaker 1: really fun. Board game Geek waits it at two point
Speaker 1: one nine, which is, you know it it has enough
Speaker 1: going on to be interesting, but a casual gamer wouldn't
Speaker 1: you know, play it and then say this is way
Speaker 1: too complicated. So I'm gonna pick that. I'm gonna put
Speaker 1: the links to it the board game Geek and then
Speaker 1: Amazon links into the the chat here, and then I've
Speaker 1: got a couple of books that I read. I actually
Speaker 1: listened to them on audible. One of them is Hit
Speaker 1: Refresh by Satia Nadella. Satia is the CEO of Microsoft,
Speaker 1: and he basically so the book is a little bit
Speaker 1: I don't want to say it's like dated, but it
Speaker 1: you know, it's not up to like twenty twenty four,
Speaker 1: and so it ends, you know, in the late twenty teens,
Speaker 1: you know, maybe around twenty twenty. And so he talks
Speaker 1: about basically him taking over Microsoft and then kind of
Speaker 1: leading it into this new age with cloud and stuff
Speaker 1: like that, and talks about his background and stuff like that.
Speaker 1: Is it is really really good. I really enjoyed it.
Speaker 1: The other one that I listened to, and this is
Speaker 1: also a company kind of takeover turnaround book is American
Speaker 1: Icon by Bryce Hoffman. And this one is the turnaround
Speaker 1: of Ford Motor Company and Bryce Hoffman. So Hit Refresh
Speaker 1: is an autobiography. Ish Satia is the primary author American Icon.
Speaker 1: He's an industry what journalist, I guess, and so he
Speaker 1: got a lot of the inside track from a lot
Speaker 1: of the people in forward and then wrote the book.
Speaker 1: And anyway, it was it was really fascinating just to
Speaker 1: listen through. Oh, this is how we solved this, This
Speaker 1: is how we solved that. And you know, it goes
Speaker 1: through the recession in two thousand and eight, and you
Speaker 1: know some of the deals they were trying to work
Speaker 1: out with the government, which I'll admit I don't love
Speaker 1: corporate welfare from the government, but it was interesting to
Speaker 1: see the approaches and how they dealt with people and
Speaker 1: how they did all this stuff. So I'm going to
Speaker 1: pick that. And then lastly, I think I might have
Speaker 1: mentioned a few times that I am running on a
Speaker 1: boon tou Now. I bought a desktop. The place I
Speaker 1: got to from my laptop. When I'd run Docker and
Speaker 1: run the stuff for any of my clients, my laptop
Speaker 1: would just slow way down. And I was starting to
Speaker 1: get into AI and that would slow way down too,
Speaker 1: And so I decided I need a newer machine, and
Speaker 1: so I started looking within the Mac ecosystem. Decided pretty
Speaker 1: quickly that what I needed was not a laptop, and
Speaker 1: so I looked at the MacPro and it was like
Speaker 1: twelve grand for the one that I was thinking I wanted,
Speaker 1: and I was like, that was a tough pill to swallow,
Speaker 1: especially since my income's kind of been up and down
Speaker 1: this year, but I was slow getting my client work
Speaker 1: done because I'd have to wait for it to run
Speaker 1: all the tests and stuff and take forever. So I
Speaker 1: looked around and DHH was recommending the framework laptop, and
Speaker 1: I thought, oh, that looks nice. But again, I had
Speaker 1: decided that the laptop was probably not going to give
Speaker 1: me the horsepower I wanted. And so they the folks
Speaker 1: on there, and I don't know if he recommended it
Speaker 1: or somebody else did, but they were all talking about
Speaker 1: a computer company called System seventy six, and so I
Speaker 1: ordered from them. It did take a bit of time
Speaker 1: because they custom build the desktop and then send it
Speaker 1: to you, but this this one cost me like thirty
Speaker 1: three hundred dollars instead of twelve thousand dollars. And so
Speaker 1: that's what I am running on right now, and it's
Speaker 1: been terrific. I've had to adjust to running on Linux
Speaker 1: instead of on Mac, but I've been pretty happy with it.
Speaker 1: I know other people do work on Windows.
Speaker 3: I just.
Speaker 1: I don't know. I've kind of gotten let me put
Speaker 1: it this way. So my wife, my mother in law,
Speaker 1: and everybody else right that's not a tech person that
Speaker 1: I know runs on Windows and it I just get
Speaker 1: tired of the maintenance hassle that I run into on Windows.
Speaker 1: And the other thing is is that you have to
Speaker 1: run it through, you know, all the stuff that I do.
Speaker 1: I typically wind up running through the Linux emulator system
Speaker 1: that they have. It's into Windows, which works okay, right,
Speaker 1: I don't hate it, but it was just like, oh,
Speaker 1: I could just run everything on Linux, because That's how
Speaker 1: I'm running my life anyway, right, I mean, all my
Speaker 1: code deployees to Linux. And so yeah, I've been I've
Speaker 1: been very very happy with it. It does essentially everything
Speaker 1: that I want it to. The only things I've run
Speaker 1: into that it can't do is you'll notice that I
Speaker 1: have the green screen set up behind me. If I
Speaker 1: want to run the green screen. I kind of have
Speaker 1: finagled things so that I can run the management software
Speaker 1: for the video mixer on Wine, but it still doesn't
Speaker 1: quite work the same as it does on the Mac.
Speaker 1: So I may just wind up doing all my streaming
Speaker 1: and recording on my Mac. And then because I still
Speaker 1: have my MacBook Pro, but I just I won't run
Speaker 1: all the other heavy duty stuff. And then if I
Speaker 1: get in a pinch, gimp and stuff work fine for
Speaker 1: the image editing and stuff. But you know, I have
Speaker 1: the Adobe tools on my mac Book Pro and so
Speaker 1: I'll run that there too, But I mean everything else,
Speaker 1: it's just been and it's such a terrific dev environment.
Speaker 1: I just I can't say enough good things. So System
Speaker 1: seventy six is my last pick, Bob, do you have
Speaker 1: some picks for us?
Speaker 3: Well, I thought i'd i'd jump into some science fiction
Speaker 3: books since that's my genre, and we had talked about
Speaker 3: the Moon as a harsh mistress. There is an alternate
Speaker 3: reality version of that story, and then and the the
Speaker 3: name of the book is The Powers of the Earth
Speaker 3: and it's written by Travis Corkran, if I remember correctly,
Speaker 3: and it's absolutely hysterical and and dead serious at the
Speaker 3: same time. It's it is, it is the story of
Speaker 3: the Moon is a harsh mistress, but told in a
Speaker 3: very modern meaning, current day political environment. So very funny
Speaker 3: in a number of ways and very serious in another
Speaker 3: a bunch of ways. So that's one book worth the read.
Speaker 3: There's a there's actually two books in the serious plus
Speaker 3: plus a bunch of short stories, all of them worth reading.
Speaker 3: Travis is software developer, so there's tons of easter eggs,
Speaker 3: you know, if you're a programmer, tons of easter eggs
Speaker 3: in there. And I think he's off in the northeast somewhere,
Speaker 3: living on a on a farm or something. Now some
Speaker 3: programmers do that. Another book that's book series that I
Speaker 3: found great, this goes back about five six years, is
Speaker 3: the whole Bob of Verse series by Dennessee Taylor. I
Speaker 3: think it is. And this is again it's the story
Speaker 3: of a software developer, and I think I think that
Speaker 3: Taylor is a software developer too, And it's the story
Speaker 3: of a software developer named Bob who sells his company,
Speaker 3: makes a fortune, and the first thing he decides to
Speaker 3: do is sign a contract so that his head will
Speaker 3: be frozen in the case he dies and he'll be
Speaker 3: reawakened in some future time. And he walks out of
Speaker 3: that after signing the contract. He walks out of the
Speaker 3: door and gets hit by a car and he wakes
Speaker 3: up as the brain of a spaceship. After that, everything
Speaker 3: gets very interesting. It's a great story, and it goes
Speaker 3: on for several several books, some of which are just hysterical,
Speaker 3: and they're all very funny and ironic and marginally plausible.
Speaker 3: So that's a cool book, marginally plausible. Yeah, okay, And
Speaker 3: then the last one is a new one and the
Speaker 3: author's name is I can't remember the name of the book,
Speaker 3: bok is Theft of Fire. Uh. And this this book
Speaker 3: I have been Oh, Devin Ericson. Devin Erickson is the author.
Speaker 3: I've been a hard sci fi guy for a long time,
Speaker 3: and I've been very disappointed with the late genre of
Speaker 3: sci fi because there's not a lot of good hard
Speaker 3: sci fi. If you you know, you know, Mars was
Speaker 3: a great story. Okay, yeah, we're yeah, the Martian that
Speaker 3: Weir writes good stuff. But uh, there's been a lot
Speaker 3: of kind of fluffy sci fi. This one is great.
Speaker 3: It's just great, good, good hard sci fi, a great premise,
Speaker 3: great characters. So I'm very very excited about this book.
Speaker 3: I read the first and he's supposedly in the midst
Speaker 3: of writing the second one. So I'm dying to get
Speaker 3: my hand on that Theft of Fire by Devin Ericson.
Speaker 3: So my hope is that there's a rebirth in the
Speaker 3: hard sci fi genre.
Speaker 1: Nice, all right, Well, I am also just gonna plug
Speaker 1: your book, We Programmers. It's on Amazon. You go buy it.
Speaker 1: Right now, and yeah, I'll look forward to Clean Coders
Speaker 1: second Edition, all right, well, thanks Bob,