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