Speaker 1: Hey, folks, Welcome back to another episode of the Ruby
Speaker 1: Rogues podcast. This week, I'm your host, Charles max Wood,
Speaker 1: and we are talking to Mike McQuaid.
Speaker 2: Mike, you came on before.
Speaker 1: We talked about homebrew and building Homebrew and work brew.
Speaker 2: And all the stuff you were doing at the time.
Speaker 1: Is there anything else you want people to know about
Speaker 1: by way of introduction or yeah?
Speaker 3: Not really all the same old stuff, Like I'm not
Speaker 3: kind of doing as much stuff on work brew nowadays.
Speaker 4: I'm doing even more stuff on Homebrew nowadays. So yeah,
Speaker 4: all good stuff. Nothing really has changed.
Speaker 2: Good deal.
Speaker 1: I use work or not work Brew, I use Homebrew
Speaker 1: all the time. So yeah, glad, pretty handy. It runs
Speaker 1: on Linux too, I think I think I wound up
Speaker 1: using it there somewhere.
Speaker 3: Yeah, yeah, it runs on Linux, and I guess because
Speaker 3: it's Linux. But we've still got a little a few
Speaker 3: tweaks there as well, on like WSL on Windows as well,
Speaker 3: so I've ended up playing wrong with it all my
Speaker 3: Windows gaming machine, which until recently been unsullied by Homebrew.
Speaker 2: Un slowly. I love it. Yeah. We we talked quite a.
Speaker 1: Bit about Homebrew and how it works last time, and
Speaker 1: I thought it'd be interesting because I find myself sometimes
Speaker 1: fiddling with like writing scripts or things like that on
Speaker 1: my on my machine and then thinking, you know, it
Speaker 1: wouldn't be too bad to kind of parlay this or
Speaker 1: these set the scripts into like a CLI. And so
Speaker 1: I was just curious, I don't even know where to
Speaker 1: start with that. But since you've kind of built a
Speaker 1: CLI that a lot of people use, I know you
Speaker 1: had other contributors, but yeah, let's say that I'm sitting
Speaker 1: on some stuff that I think belongs in the CLI.
Speaker 2: Where would you even start with something like that? Yeah?
Speaker 3: I think that's it's really good question because I think
Speaker 3: the a lot of this depends on I guess, like
Speaker 3: a lot of stuff in tech, right is like what
Speaker 3: does your scaling story look like? Right to be one
Speaker 3: of those boring people of like if it's just something
Speaker 3: that you're writing.
Speaker 4: For yourself to run it once and throw it away.
Speaker 3: Then you know, thinking about like the language you use,
Speaker 3: like you just want to reach for whatever is the
Speaker 3: most familiar to you, or I guess in personally nowadays,
Speaker 3: like whatever you think chat chpt can one shot a
Speaker 3: reasonable approximation of.
Speaker 4: What you want it to do, and then you can
Speaker 4: tweak it before you run it.
Speaker 2: But yeah, so like that way more than I care
Speaker 2: to admit.
Speaker 4: Oh for sure.
Speaker 3: I mean it's great because I feel like there's a
Speaker 3: lot of stuff around that where there's like scripts that
Speaker 3: previously we just wouldn't have written. And then now just
Speaker 3: being like, hey, I want to pull the state from
Speaker 3: the getab api and previously being like, oh, that's possible,
Speaker 3: but I really want to spend like two hours on this,
Speaker 3: and then it's not like well, I'll spend twenty seconds
Speaker 3: asking chat CHPT and look at the output and if
Speaker 3: it's wrong and then it doesn't matter. But yeah, so
Speaker 3: I guess that's the first thing. Is like, so for
Speaker 3: me personally, like I tend to reach for like the smallest, dirtiest,
Speaker 3: filthiest scripts for Bash because I'm pretty comfortable in Bash.
Speaker 3: There's Bash has like a huge amount of gotchas though,
Speaker 3: so as soon as it becomes even slightly load bearing,
Speaker 3: even for you, you probably want to go to like
Speaker 3: a no offense Bash authors like a real language, and
Speaker 3: at that point, you know, stuff's pretty interchangeable, like if
Speaker 3: we're on a Ruby podcast, So like Ruby is really
Speaker 3: good for like yeah, standalone single file cli script. That's
Speaker 3: what I would tend to kind of go for straight away.
Speaker 3: If you're a Python person. Python's pretty good for that
Speaker 3: type of stuff as well. I think, like, you know,
Speaker 3: if people don't have familiarity with those, I'd be surprised
Speaker 3: if they listen to a Brewery podcast. But then, you know,
Speaker 3: I'm sure you can probably do equivalent stuff in C
Speaker 3: sharp and various.
Speaker 4: Other right more obscure languages.
Speaker 3: But like, I guess that's where I would tend to
Speaker 3: go next is just be almost like, okay, how can
Speaker 3: I put in a single script and you can do
Speaker 3: some kind of neat stuff with Most people are familiar
Speaker 3: with Bungler for installing dependencies, but then most people are
Speaker 3: also like, okay, like bundler, I have to do like
Speaker 3: bundling stoll and bundle exec and.
Speaker 4: All this type of stuff.
Speaker 3: But actually you can do some cool stuff with bundler
Speaker 3: where you can actually define a gem file inside the
Speaker 3: script itself, so the first thing it does is shouts
Speaker 3: fall its dependencies installs them all, so that that can
Speaker 3: be again quite a nice way of extending some little
Speaker 3: basic scripts.
Speaker 1: Yeah, I just want to back up on that for
Speaker 1: a minute, because I ran into that somewhere I can't
Speaker 1: remember where, but yeah, it's just its own little syntax
Speaker 1: in there, isn't it.
Speaker 2: What exactly do you have to do in order to.
Speaker 3: Yeah, I can't remember the exact syntax with top my head,
Speaker 3: but yeah, basically, like, I mean, that's the nice thing
Speaker 3: about the state of Bundler and Ruby in twenty twenty
Speaker 3: five is if you're installing an even vaguely modern Ruby,
Speaker 3: it's going to come with a vaguely modern Ruby gems
Speaker 3: and Bundler out of the box, and then everything essentially
Speaker 3: you can do through the CLI you can also do
Speaker 3: through the Rubia guys instead. And that means that essentially
Speaker 3: every input that you would previously have poss as a parameter,
Speaker 3: you can poss in as a string or like your
Speaker 3: gem file instead of reading it from disc you can
Speaker 3: like have that be like a here doc in your
Speaker 3: Ruby script or whatever it might be.
Speaker 4: Yeah, Like so that's a nice way of getting there.
Speaker 3: So like, that's what I will tend to do is
Speaker 3: have like a little bit at the top of maybe
Speaker 3: one of my scripts that's like, hey, if I need
Speaker 3: this particular gem, then install this gem at the first
Speaker 3: time it's run, and then I don't need to like
Speaker 3: carry along the script and a gem file and whatever.
Speaker 3: I can just run it wherever I need to and
Speaker 3: however I need to.
Speaker 1: Yeah, I did find it. You require a bundler inline
Speaker 1: and then you do gem file do and then you
Speaker 1: basically put all your gem file stuff in there.
Speaker 2: So you do your source which is probably RubyGems.
Speaker 1: Dot org, and then you gem whatever and yeah, you
Speaker 1: just use your the domain specific language for the butler
Speaker 1: for the gem file. Yeah, and off it goes.
Speaker 2: It's pretty cool.
Speaker 3: So then when your script's getting a little bit more
Speaker 3: I guess load bearing, as we were saying as well,
Speaker 3: like that might be when you want to be like, hey,
Speaker 3: I want to have some like options parsing, and like
Speaker 3: the most basic way of doing that is just you know,
Speaker 3: you've got the rg V like array and you can
Speaker 3: go and.
Speaker 4: Say, okay, what's the first parameter, second parameter. But if
Speaker 4: you want to handle flags.
Speaker 3: And switches and being passed in different orders, there's like
Speaker 3: the Ruby again part of the standard library. There's the
Speaker 3: Ruby kind of option parser library, which is pretty good,
Speaker 3: pretty easy to use. If you're still in bashland, there's
Speaker 3: like sort of a Bash equivalent, but in my mind,
Speaker 3: even by the time I start getting towards like multiple
Speaker 3: argument parsing, it's like, that's again a nice sign that
Speaker 3: I probably want to go into Ruby, and yeah, use
Speaker 3: that kind of richer library. And there's also various gems
Speaker 3: that provide different dsls for whatever your preferences are in
Speaker 3: that area.
Speaker 1: Yeah, that makes sense. I know a lot of people
Speaker 1: also use Optimist. You used to be called trollo.
Speaker 2: Yep.
Speaker 1: If you're been around for a while, and it's like optimists,
Speaker 1: it's the same thing.
Speaker 2: Yeah, so do you have this reference.
Speaker 4: It's funny because I tend to.
Speaker 3: I tend to like not I tend to use just
Speaker 3: the most basic, like I'm going to pull stuff out
Speaker 3: of rg V until it hurts. I think it's also
Speaker 3: because I've been around in Homebrew and Ruby and whatever,
Speaker 3: like long enough it's like I'm aware of all of
Speaker 3: the kind of educases that you get there, and like
Speaker 3: if you delete a random part of r V, or
Speaker 3: if you jup it, or if you check for inclusion,
Speaker 3: like what.
Speaker 4: The various gotches are.
Speaker 3: So like I wouldn't necessarily recommend other people do what
Speaker 3: I do, but yeah, but I guess I don't have
Speaker 3: a particular library of that I prefer for this stuff
Speaker 3: and Homebrew because for a very long time, Homebrew kind
Speaker 3: of couldn't really by design use any Ruby libraries without fully.
Speaker 4: Vendoring them all, which was a big pain for us.
Speaker 3: Like Homebrew basically built its own argument parser and stuff
Speaker 3: like that. Even today, like Homebrew were a little bit
Speaker 3: I wouldn't say suspicious of other libraries, but it's like
Speaker 3: the we care. I guess this is a nice segue
Speaker 3: to the next thing you might start caring about with
Speaker 3: the CLI, which is like Homebrew nowadays, we really care
Speaker 3: about like the.
Speaker 4: Run time and almost like how long is.
Speaker 3: It going to take to essentially, you know, do the
Speaker 3: thing that you want it to do, So like how
Speaker 3: long how long until you can print a Hello World
Speaker 3: once you have all your libraries loaded and everything like that.
Speaker 3: And I think that's the type of thing where like
Speaker 3: if you have a script that you run once a
Speaker 3: month and it takes thirty seconds to run, you probably
Speaker 3: don't care if it takes five seconds or thirty seconds
Speaker 3: or a minute, right like it's but if you have
Speaker 3: a script that you're running in your shell, prompts say,
Speaker 3: and then your shell's not going to be print your
Speaker 3: shell prompts, not getting it printed until the script completes.
Speaker 4: All of a sudden, you maybe don't want to require
Speaker 4: that library.
Speaker 3: You may be want to do it by hand so
Speaker 3: that you can just boost it, or you may well
Speaker 3: be getting to the wards the point which Homebrew is.
Speaker 4: Not quite able to do.
Speaker 3: But some the other CLIs I've built more recently, I guess,
Speaker 3: like at work Brew and at GitHub or whatever, it's like, okay,
Speaker 3: you maybe want to reach for another language at this point.
Speaker 3: So Ruby is really good language. There's been a lot
Speaker 3: of performance optimization work that's gone into Ruby in the
Speaker 3: last five or ten years, but a lot of that
Speaker 3: comes from the shopifys and the gethubs, who are not
Speaker 3: focused on how can I make a CLI run as
Speaker 3: fast as I possibly can? But they're focused on like,
Speaker 3: how can I have a long lived Ruby process realistically
Speaker 3: running probably rails of Sinatra or whatever, which can serve
Speaker 3: as many requests.
Speaker 4: As possible as quickly as possible.
Speaker 3: Right, So that has more performance implications around like memory
Speaker 3: management and garbage collection and JITs and stuff like that,
Speaker 3: and things which rewards the longer execution of the application,
Speaker 3: which is the exact opposite of what CLI does. Unfortunately,
Speaker 3: some things like Ruber Coop have kind of got around
Speaker 3: that by having I forget what they call it, but
Speaker 3: there's basically a mode when you can essentially have Ruber
Speaker 3: cops sitting in the background and you end up sending
Speaker 3: requests to an already running process. I guess we could
Speaker 3: maybe a take that approach with Homebrew one day, but
Speaker 3: we've not yet. So instead we're generally concerned about like,
Speaker 3: how can you how can you shave that time down?
Speaker 3: How can you require as little as possible and push
Speaker 3: some logic into maybe Bash in home Brew's case. But
Speaker 3: when you're writing like a prophecy, a lie and that's
Speaker 3: you know, that looks like maybe nowadays probably the best
Speaker 3: choices would be something like gut rust or go, depending
Speaker 3: on your preferences.
Speaker 4: Like go, for example, is.
Speaker 3: If you're used to Ruby, it's a very sad language
Speaker 3: I think to write because it's you cannot be.
Speaker 2: Expressive, IM go right now?
Speaker 4: So yeah, so how have your experience has been with that?
Speaker 3: About like going from the delights of ruby Land to
Speaker 3: go land with the stuff?
Speaker 2: Yeah?
Speaker 1: Yeah, I don't love it. I mean I'm just barely
Speaker 1: getting into it. They use it at work, so yeah,
Speaker 1: back end engineer encompasses Ruby and go. Yeah, and mostly
Speaker 1: I get away with not doing a lot of Go,
Speaker 1: but yeah, they kind of expect and need you to.
Speaker 3: So yep, yeah, it's you. I feel like there's there's
Speaker 3: definitely been several schools of languages where the underlying methodology
Speaker 3: is like stop people from doing stupid stuff, and Ruby
Speaker 3: feels like it's almost as far in the other extreme
Speaker 3: as you can do, where it's like you can I mean,
Speaker 3: I'm sure you've reviewed some absolutely heenous Ruby code of
Speaker 3: the years where people have metaprogramming to an absurd yeah
Speaker 3: Goldberg level where it's impossible to figure out what's going on,
Speaker 3: but that also allows you to build incredible the powerful
Speaker 3: rails and all of this stuff, right and go.
Speaker 4: I'm sure you have the same Charles. I just end
Speaker 4: up feeling like.
Speaker 3: You know, this like twenty line switch statement could be
Speaker 3: one line of coding Ruby, but you know you don't
Speaker 3: let me have the you know, you've taken away the
Speaker 3: keys to this particular car, So I guess I have
Speaker 3: to write the twenty line switch tament.
Speaker 1: Yeah, I just have to say, I mean to a
Speaker 1: certain extent like control flow and things like that.
Speaker 2: It's all the same.
Speaker 1: You know, there's some funky stuff with like very variable
Speaker 1: assignment and functions and things like that, But yeah, it
Speaker 1: doesn't light up my soul like ruthe does.
Speaker 4: Yeah.
Speaker 3: Yeah, Like Go feels in many ways to me like
Speaker 3: a sort of much less verbost Java. Yeah, Like I
Speaker 3: wrote a bunch of Java back in the day when
Speaker 3: it was peak Java enterprise beans, and you know all
Speaker 3: this like accessive boiler plate, and there's a lot less
Speaker 3: at the boiler plate and Go.
Speaker 4: But it still feels like this non zero amounts. But yeah,
Speaker 4: so I'd say.
Speaker 3: I would still consider reaching for Go for a CLI
Speaker 3: if you really care about that.
Speaker 4: Like execution performance.
Speaker 3: So for example, I guess when I was at work
Speaker 3: group previously, I was working on the CLI there, which
Speaker 3: wrapped around Homebrew Cli.
Speaker 4: So we wanted to provide as little overhead as possible.
Speaker 3: And the amount of stuff you can do in zero
Speaker 3: point one of a second on modern hardware and Go
Speaker 3: compared to Ruby is like fairly spectacular. Like in Ruby
Speaker 3: you're really trying to make sure you avoid like any
Speaker 3: IO or significant significant computation or anything like that.
Speaker 4: Ross Road just just.
Speaker 3: Because of the virtues of it being like a natively
Speaker 3: compiled language.
Speaker 4: You can just do an awful lot of stuff much faster.
Speaker 3: And that the multi threatened story as well, is like
Speaker 3: because it's not the global interprets of walk or a
Speaker 3: come that's the Ruby name, but whatever the Ruby equipment is. Yeah,
Speaker 3: you can you can afford to just leading into the
Speaker 3: concurrency a lot harder.
Speaker 2: Yeah, that makes sense.
Speaker 1: So let's say that I want to build a CLI
Speaker 1: and I'm trying to think of like a super fun example.
Speaker 1: Let let's say that I'm gonna, you know, I'm gonna
Speaker 1: get an open ai ap apike and I'm gonna you know,
Speaker 1: I'm gonna make it talk to whatever, right, so you know,
Speaker 1: maybe it'll talk to multiple services there. Right, So I'm
Speaker 1: doing stuff maybe with the podcasts, which is kind of
Speaker 1: what I'm imagining, right, So I hand.
Speaker 2: Off my.
Speaker 1: Audio or video to whisper and it bought I being
Speaker 1: I got a transcript, right, and then maybe I hand
Speaker 1: the transcript off to d LLM and it does some stuff.
Speaker 1: A lot of this stuff I mean you would put
Speaker 1: on the back of like a rails app or anything
Speaker 1: else too, right, But you know, I want a command
Speaker 1: line interface just to make it super easy for me
Speaker 1: to kind of navigate through some of this stuff.
Speaker 2: Where would you recommend I start?
Speaker 3: Yeah, I mean, like for me with stuff like that
Speaker 3: tend to in some ways, that's a kind of general question.
Speaker 3: We like, how do you bolde software right? And I'm
Speaker 3: sure everyone has different ways, but like the way I've
Speaker 3: always liked to do it is essentially just try and
Speaker 3: write the Well, I'll give my pre ai answer first.
Speaker 3: My pre aions is essentially just right the filthiest, hockiest code,
Speaker 3: assuming that no one will ever read it, to just
Speaker 3: get the core thing done.
Speaker 4: So I guess in your case, it's like, okay, I
Speaker 4: want I.
Speaker 1: Would write a script and I would point there. I'm
Speaker 1: not going to do any argument.
Speaker 3: If I'm just going to assume an argument has been passed.
Speaker 3: I'm going to pull out the first argument. I'm gonna
Speaker 3: get the file, maybe the MP three file or whatever
Speaker 3: from the podcast on disc. I'm then going to load
Speaker 3: that into memory and then going to pass that off
Speaker 3: to Opening.
Speaker 4: Eyes Transcription API.
Speaker 3: I'm then going to pull down the result of that
Speaker 3: as like Jason or whatever. Then I'm going to immediately
Speaker 3: get that not store anywhere, stick that inter opreenning guys
Speaker 3: like im API do something with that, bring that down
Speaker 3: and then print the output right and essentially build it
Speaker 3: in such a way that there's no air handling. If
Speaker 3: anything is in any way not the happy path, then
Speaker 3: it will fail with a completely incomprehensible whatever message.
Speaker 4: Right.
Speaker 3: So, like generally that's the way I like to feel
Speaker 3: out how to do things initially, And like I think
Speaker 3: sometimes with like CLIs and stuff like that, it can
Speaker 3: be tempting to be like, oh, I'm going to add
Speaker 3: the options first, you know, because that's if you're almost
Speaker 3: like thinking from like top to bottom. That might be
Speaker 3: how you would think about it. But actually, like that's
Speaker 3: not really Probably the thing you cared the most about.
Speaker 3: You're trying to figure out is this thing even viable
Speaker 3: or useful or whatever. And every minute you spend fiddling
Speaker 3: with options is a minute you're not figuring that.
Speaker 2: Out right, right, not doing the quarteine that makes sense?
Speaker 1: And then so one thing that I'm looking at is
Speaker 1: so then do you just build the CLI around it
Speaker 1: so that you can say transcribe file nan yeah or exportant.
Speaker 3: So I again with this type of stuff, like I
Speaker 3: tend to go for like, keep everything in one file
Speaker 3: like until it starts falling over, right. And I would
Speaker 3: again to start with not even necessarily use any methods
Speaker 3: until I'm thinking about making things kind of dry and
Speaker 3: you know, I'm having to call the same thing multiple
Speaker 3: times or whatever. Right, So I just would tend to
Speaker 3: do that until it feels like it's getting too much.
Speaker 3: I don't know what that is, whether that's you know,
Speaker 3: a couple hundred lines, five hundred lines, one thousand lines whatever, right,
Speaker 3: and then start splitting up. You said, if you had
Speaker 3: commands like say you're passing like a transcribed command to
Speaker 3: do this, or like a read out loud command or
Speaker 3: you know, start a chat command or whatever, then that
Speaker 3: might be when I'm like, okay, well, logically there's like
Speaker 3: three different things this is doing. Probably the code between
Speaker 3: them is not actually that similar.
Speaker 4: So maybe these could all split out into.
Speaker 3: Separate files that are stored a bit separately and included
Speaker 3: separately and whatever. And again that's one of the pros
Speaker 3: and cons of kind of Ruby and Go and stuff
Speaker 3: like that, because in Ruby, okay, you've got those different files,
Speaker 3: but you've now once you've slit into multi files like
Speaker 3: if someone else is like, oh cool scripts, how can
Speaker 3: I use it? Then it goes from being like here's
Speaker 3: literally like the copy and pasted script contents to being like,
Speaker 3: you need to clone this repo.
Speaker 2: And here's how you want to ask this.
Speaker 3: Yeah exactly, So like okay, you could but make it
Speaker 3: a GEM and then they could gem install it. But
Speaker 3: like I'm showing my Homebrew maintainer bias here, but I've
Speaker 3: I personally I really like Ruby jams and equivalent to
Speaker 3: other languages. For like I want to library I'm writing Ruby.
Speaker 3: I want to library for Ruby. Right, I kind of
Speaker 3: resent it when I'm like, I want to install a
Speaker 3: tool that just happens to be written Ruby. I don't
Speaker 3: actually care what language this tool is written in, right,
Speaker 3: And I have to use MPM with JAM or pip
Speaker 3: whatever to install some run to cli. Like for me,
Speaker 3: I would always either reach for Homebrew or if it's
Speaker 3: just something my mate wrote, ideally, my mate just like
Speaker 3: sends me the script and I have like a dumping
Speaker 3: ground repo and I just like copying paste that file
Speaker 3: in's by report and then I can run it or
Speaker 3: modify it as I choose in future.
Speaker 1: Right, So that was that Yeah, you're you're talking around
Speaker 1: one of the things that I was going to ask, right,
Speaker 1: Because if it's just one file, it's like, Okay, stick
Speaker 1: this in your path, make it executable, bam, you're done, right,
Speaker 1: But if it's multiple files, yeah, I was trying to
Speaker 1: figure out, Okay, how do you package that?
Speaker 2: And I guess, yeah, you could use some thing like
Speaker 2: Homebrew or Yeah.
Speaker 1: I agree with you on the I mean, if it's
Speaker 1: a Ruby specific tool like Rake, I don't really have
Speaker 1: a problem with it being in Ruby gems. But yeah,
Speaker 1: like the I've used other CLIs. I think it's like
Speaker 1: the Heroku CLI or the Stripe cl I can't remember,
Speaker 1: but one or two of those. It was like, yeah,
Speaker 1: I had to go NPM install it, and I'm going, yeah,
Speaker 1: but this is not a code tool, yep. And that's yeah,
Speaker 1: I agree with you there. It's like, no, this this
Speaker 1: belongs in Homebrew or apt or YOUM or you know
Speaker 1: whatever whatever your package manager is for your operating system,
Speaker 1: where it's going to pull it in and say, hey,
Speaker 1: this is a utility you're going to use for other things. Right,
Speaker 1: it's an application essentially that runs on top of your OS.
Speaker 4: I just yah, Ruby podcast, it feels like a safe
Speaker 4: space to admit this.
Speaker 3: But yeah, like I my one is like NPM, where
Speaker 3: it's like I ideally I don't have no Jetz on
Speaker 3: my system at any given time, right, So like when
Speaker 3: when something sayss like, oh, the way to do this
Speaker 3: next step like step one NPM stall x and so well,
Speaker 3: actually there was a step zero which was installed no.
Speaker 4: J I and given this thing.
Speaker 3: That you're asking me to do is nothing to do
Speaker 3: the JavaScript, Like, I don't see why I have to
Speaker 3: do that, right, So often I'm like, Okay, I then
Speaker 3: go looking and I'm.
Speaker 4: Like, oh, is this is this already in Homebrew?
Speaker 3: And if not, maybe I package it and homebrew my
Speaker 3: own benefit and other people in future or whatever.
Speaker 4: But yeah, I've always felt that that's that.
Speaker 3: Yeah, the kind of I think that's a You've brought
Speaker 3: up a bigger question there about almost like distribution, and
Speaker 3: I think that's that's a bit more kind of messy
Speaker 3: and complicated because it ends up being like, well, what is.
Speaker 4: The distribution method?
Speaker 3: And Homebrew somewhat infamously, I think it might be one
Speaker 3: of the first, maybe even the first to the whole
Speaker 3: like cold to bash install the script that everyone is
Speaker 3: much the rides, but like, you know what, if you're
Speaker 3: installing something exactly, it works. But also like if you're
Speaker 3: trying to install something that's kind of like non trivial,
Speaker 3: like homebrew that involves cloning a pot and you know, again,
Speaker 3: it's like the MPAM install. Like we could say, okay,
Speaker 3: well step one get cloned, and so well I don't
Speaker 3: have GET on my machine. It's like, okay, well you
Speaker 3: need to still get. How do I do that? Well
Speaker 3: it's you whoops.
Speaker 1: Yeah, I guess that's my issue, right is I generally
Speaker 1: have noted NPM on my machine. Right I'm working in rails,
Speaker 1: you know, I need some kind of JavaScript run time,
Speaker 1: and so it's like, Okay, this feels weird, but I'll
Speaker 1: do it. But yeah, if it's a PIP install because
Speaker 1: I I never touched Python, or you know, if if
Speaker 1: it requires Go or something like that.
Speaker 2: Now these days I'm working on Go.
Speaker 1: But yeah, it's like, why do I have to install
Speaker 1: a programming language in order to get my tool when
Speaker 1: it doesn't really have anything to do with the programming language.
Speaker 2: And so yeah, just getting into you know that step.
Speaker 1: I guess some of these come like self packaged or
Speaker 1: when you do the install, then it'll you know, behind
Speaker 1: the scenes, it'll install either a standalone version of the
Speaker 1: laneguage or give you some way of building it on
Speaker 1: your machine, or sometimes it's just an executable that's pre
Speaker 1: built that you know, it has reasonable assumptions about what's
Speaker 1: already there. Yep, and so so that works. But yeah,
Speaker 1: so let's say that I am building a CLI. I
Speaker 1: write it in Ruby, you know, Yeah, I mean I
Speaker 1: can tell my friend to go get clone it, right
Speaker 1: if they're a programmer, and you know, and then it's like, okay,
Speaker 1: here's the command to run it. But yeah, let's say
Speaker 1: that it's something that's getting wider adoption and it needs
Speaker 1: that distribution right where it's.
Speaker 2: Hey, you know you're going to go run this on
Speaker 2: your own machine.
Speaker 1: Right, Maybe it's a fancy CLI that cleans up large
Speaker 1: files on my hard drive or something like that. Right,
Speaker 1: it's some other utility that does some of these other things.
Speaker 1: You know, it's helpful, and I don't need a UI
Speaker 1: for it, or at least not a complicated UI, big
Speaker 1: graphical UI.
Speaker 2: Yeah, how do I begin to package that up?
Speaker 4: Yeah?
Speaker 3: So again, probably unsurprisingly, my natural response to that is
Speaker 3: like Homebrew is pretty good, yeah, distributing software, right, So
Speaker 3: with Homebrew you can kind of stick it in a
Speaker 3: repo and then call like Brew, create dashtash, Ruby, point
Speaker 3: that at the repo and then humbrew will try its
Speaker 3: best to figure things out. But then you know, if
Speaker 3: it can't, you can fiddle with that and hombur can
Speaker 3: help you with that. And you know, if this is
Speaker 3: a thing that's pretty widespread use and you're packaging someone
Speaker 3: else's software or whatever, then you could submit it to
Speaker 3: the main repository and ChIL It'll be accepted fairly quickly
Speaker 3: and then everyone can benefit that. If not, we have
Speaker 3: this thing called called taps, which are like third party repositories.
Speaker 3: Basically that you can run a command Brew tap new,
Speaker 3: which basically will create a new.
Speaker 4: Tap for you.
Speaker 3: You can then push that up to get hub as
Speaker 3: a repo, and we spit out some nice CI workflows
Speaker 3: so you can use those free public repo actions minutes
Speaker 3: to put them to use, and then you could use
Speaker 3: that as your distribution method if you want instead, and
Speaker 3: then that could be a nice way of you know,
Speaker 3: regardless of what language you.
Speaker 4: Write it in, if you're doing Ruby or Python.
Speaker 3: Or Go or whatever. Then you can distribute your software
Speaker 3: that way pretty easily.
Speaker 1: So if there's any kind of setup or build step
Speaker 1: or anything like that, is there some version of like
Speaker 1: an install script or something that it runs or yeah.
Speaker 3: Yeah, So there's like in Homebrew's Ruby formula, which is
Speaker 3: kind of like our DSL for like building and installing software.
Speaker 3: Basically there's yeah, there's like an install method and basically
Speaker 3: you can much like a normal Ruby you can run
Speaker 3: a bunch of system commands in there. Like we try
Speaker 3: and do a reasonable guess of like, hey, if it's
Speaker 3: a Ruby project, you probably want to run like bundle
Speaker 3: install and then you know, stick a Ruby file in
Speaker 3: a bin directory somewhere and that probably gets you most
Speaker 3: of the way there. But yeah, but it's basically just
Speaker 3: like little nice dsls that can kind of help you
Speaker 3: get that software onto your machine. And it's I think
Speaker 3: one of the nice things about Homebrew is it's definitely
Speaker 3: of most of the packaging systems I've ever intacted with,
Speaker 3: and from what I hear from people, it's one of
Speaker 3: the easiest to just get started with like an existing
Speaker 3: piece of software, because essentially you're just like, Okay, run
Speaker 3: some commands which you can try yourself in Bash and
Speaker 3: then move stuff from one place or another, and then
Speaker 3: that's you.
Speaker 1: So I mean, in the case of Ruby, Homebrew already
Speaker 1: runs Ruby. But let's say that I reach for something
Speaker 1: like Go or Rust or maybe I'm using Python, right,
Speaker 1: and so I can't assume that the person whose machine
Speaker 1: is going to get installed on has you know, the
Speaker 1: language or language tools that I need in order to
Speaker 1: build and run it. How do you manage that kind
Speaker 1: of a thing.
Speaker 4: Yeah, so in Homebrew, that's we just have like a
Speaker 4: long line again with DSL.
Speaker 3: Depends on where you can basically say, okay, I need
Speaker 3: Ruby or this particular version of Ruby or whatever it
Speaker 3: may be.
Speaker 2: Where against all that globally?
Speaker 3: Yeah, yeah, so it install that, but Homebrew keeps track
Speaker 3: of Okay, did did you ask me to install Let's
Speaker 3: just say, say we have or openly night transcription thing,
Speaker 3: call it transcribey or whatever, right, and you might install
Speaker 3: it with Bruins School transcribe, So that would install Ruby
Speaker 3: automatically because that's what you said. But then in a
Speaker 3: year you're like, ah, you know, Ruby sucks or whatever.
Speaker 4: I'm going to rewrite this and go and then you
Speaker 4: switch your.
Speaker 3: Packaging to Go, then Homebrew knows when you ran Bruins
Speaker 3: School Truscribbe you weren't saying, hey, can I have Ruby
Speaker 3: and transcribing. You were just I just care about truanscriby.
Speaker 3: I don't care what trubscribey is written in.
Speaker 4: Right, So then if it.
Speaker 3: Changes in the future to Go, then Homebrew that knows like,
Speaker 3: oh well you never asked for Ruby.
Speaker 4: We don't need Ruby anymore.
Speaker 3: Let's give it a Ruby, right, And again the fun
Speaker 3: thing to Go as an example is like, and this
Speaker 3: is where it gets slightly different. I won't go into
Speaker 3: the details unless you're really interested of like if you're
Speaker 3: you're building it yourself versus if Homebrew builds it for you.
Speaker 3: But if humbrew builds it for you, then the nice
Speaker 3: thing about Go is because Go spits out binaries, then
Speaker 3: you don't even need to install GO on your system, right,
Speaker 3: you can probably use the finery that we have built
Speaker 3: for you, so then you can get it Ruby.
Speaker 4: You don't need Go.
Speaker 3: We need to instill GO when we're building it for
Speaker 3: you in our service, But on your system you don't
Speaker 3: need GO unless you're building a right from source as
Speaker 3: we would.
Speaker 2: Say, right, similar with Rust, Yeah, exactly.
Speaker 1: And it seems like with the approach that we're taking
Speaker 1: with Ruby or Python or something that's not compiled that way,
Speaker 1: or Node as another example, right, if it's running on
Speaker 1: any of those, the install node or install Python or
Speaker 1: install Ruby approach works fine on Linux or Mac or
Speaker 1: in the u SSL, yeah, WSL, whatever it is. I
Speaker 1: am not a Windows I help my wife with Windows,
Speaker 1: but she's not using the Linux emulator. So but yeah,
Speaker 1: so that works fine there. And then if you need
Speaker 1: to package it up for something like Windows, then then
Speaker 1: you're looking at another tool that's going to essentially package
Speaker 1: your language. Right, It's going to put your Ruby VM
Speaker 1: in the execute the ball so that you can run.
Speaker 3: Yeah, so that's when it starts to get a bit
Speaker 3: more messy, and different languages are optimized for that. So again,
Speaker 3: like going right back to our original, like I'm writing
Speaker 3: a CLI, so I think like one of the first
Speaker 3: questions I would probably have is like, what are the
Speaker 3: chances are that you're going to want to ship this
Speaker 3: to Windows users?
Speaker 4: Right?
Speaker 3: And if unless the chance is definitely not, then Ruby
Speaker 3: and Python and even more so things like Bash are
Speaker 3: you know, very easy to get started across when there's
Speaker 3: sorry across Linux and mac Os from the outset. But
Speaker 3: then when you have like a Windows story, that's when
Speaker 3: it starts to get a bit more messy. Like Windows ADS. Again,
Speaker 3: like plenty of PACKGEP managers and stuff like that, but
Speaker 3: your average Windows user is not going to be familiar
Speaker 3: with those, and even a lot of Windows developers don't
Speaker 3: necessarily use like package management as widespread as it is
Speaker 3: in the Linux and mac Os worlds. So that's when
Speaker 3: I would say, like the story that Go for example
Speaker 3: can do for you is I'm less clued up on
Speaker 3: Rust in this way, So I might excuse me any
Speaker 3: Rustians who are listening that I might not know quite
Speaker 3: as much about what Ross people are, but certainly I know.
Speaker 3: With Go, the nice thing is you can just build
Speaker 3: a single binary which you can then have run on
Speaker 3: a Windows machine and that will work as expected.
Speaker 2: Right.
Speaker 3: But the other nice thing with Go is it's the
Speaker 3: cross compilation story is very easily is very easy. So
Speaker 3: even if you only have access to a Mac machine,
Speaker 3: you can build the binary on your Mac for all
Speaker 3: mac OS versions essentially and Linux and Windows. And if
Speaker 3: you don't have access to those operating systems. You can
Speaker 3: have a reasonable degree of confidence that, unless you're doing
Speaker 3: kind of wackys specific stuff, that that binary will just
Speaker 3: run fine on all three HOSS and like that. That's
Speaker 3: a pretty appealing thing if you're building a CLI that
Speaker 3: you want to be used cross platform.
Speaker 1: Yeah, that makes sense. I'm a little curious getting into
Speaker 1: running it on Mac versus Linux? Like are it seems
Speaker 1: like for the most part things just generally work the
Speaker 1: same way. Are there meaningful differences that you need to
Speaker 1: be aware of in certain cases?
Speaker 4: Yes?
Speaker 3: I think most of the time you don't need to
Speaker 3: think too hard about things, and I think it's it's
Speaker 3: often relatively obvious when you're sort of starting to get
Speaker 3: a little bit more detailed. So, for example, one difference
Speaker 3: would be the you know, we're gonna really nerd out
Speaker 3: some nice os well like high level ors internals here.
Speaker 3: But you know, like mac os and Linux run different kernels, right,
Speaker 3: there's the Linux kernel and the mac os Darwin kerdile
Speaker 3: and then there's the stuff in user space as well,
Speaker 3: so like because yeah, like as you mentioned, like macOS
Speaker 3: came from like a BSD kernel land like most of
Speaker 3: the user space applications or BSD and on Linux, most
Speaker 3: of the user space applications.
Speaker 4: Might be g do once.
Speaker 3: And Apple won't do so because of GPLC three, which
Speaker 3: is a whole other, long and boring conversation. But yeah,
Speaker 3: So basically, like if you're calling out to various say
Speaker 3: like even Gret, right, Gret has arguments that will work
Speaker 3: on maquest and they will not work on Linux in
Speaker 3: the same way, and vice versa. So you might if
Speaker 3: you're shelling out to Gret, you might need to have
Speaker 3: like conditional logic based on the OS you're on. Or alternatively,
Speaker 3: instead of shelling out to Gret, you just say, Okay,
Speaker 3: I'm gonna instead like get all the lines and I'm
Speaker 3: going to iterate off the lines in Ruby and do
Speaker 3: things that way too. So I think with with like
Speaker 3: writing Ruby itself, like Ruby and Python are both generally
Speaker 3: written in such a way that like pretty much everything
Speaker 3: you would ever try and do is going to be
Speaker 3: cross platformed by default, Right, it's just various little gotcha's
Speaker 3: like shelling out or again, I can't remember this is
Speaker 3: still the case in twenty twenty five, I'm pretty sure
Speaker 3: it is. But like, by default, the next generally ships
Speaker 3: with a Letussure ship with a case sensitive file system
Speaker 3: and Macwest ships with a case insensitive file system. So
Speaker 3: if you're doing all your development on Mac and you
Speaker 3: have like some file that you read in from your
Speaker 3: repository or whatever, and it's uppercase a you know, Anti
Speaker 3: TERB with an opper case versus antique with a lyric
Speaker 3: ASA that will watch just final mac os if you're inconsistent.
Speaker 4: Between the repo data on disc and how you've written
Speaker 4: in your source codes.
Speaker 3: But then on the next that my plot right, So
Speaker 3: like these are types of little things that you need
Speaker 3: to care about when you're doing cross platform development.
Speaker 2: Gotcha.
Speaker 1: So yeah, I'm just trying to think through the rest
Speaker 1: of it. I'm imagining that. Yeah, if I split things
Speaker 1: up into files, what it's going to do is it's
Speaker 1: going to put all of my files into one place,
Speaker 1: put the executable in the path somewhere, and then the
Speaker 1: executable is going to be aware of where the things
Speaker 1: are and just have that in the load path essentially
Speaker 1: exactly exactly.
Speaker 2: Now, with testing.
Speaker 1: Are there specific things that you do when you test
Speaker 1: them or do you just kind of test the internal
Speaker 1: logic and assume that your flags and stuff work.
Speaker 3: Yeah, so that's a good question as well, because I think,
Speaker 3: particularly we've never really written a CLI before, you would
Speaker 3: probably think, particularly once you get to like the multiple
Speaker 3: files level of like, Okay, I'm going to write a
Speaker 3: bunch of unit tests for the internals and make sure
Speaker 3: that they work.
Speaker 4: My experience as a you know, longtime.
Speaker 3: CLIR is that like, actually, that is going to cause
Speaker 3: you a lot of pain unless you have at least
Speaker 3: some tests that are actually shelling out and running the
Speaker 3: script externally, right And we I guess relatively recently in Humbrew,
Speaker 3: which in my mind is probably like ten years ago,
Speaker 3: but that's recent as far as I'm conturned.
Speaker 4: Yeah, So we used to have.
Speaker 3: A lot of tests that would just you know, unit tests,
Speaker 3: and then we would just find that like really core
Speaker 3: functionality would break because all the internals, all the internal
Speaker 3: APIs we're working, you know, it's it's the tailors all
Speaker 3: the time with like unit test versus integration test, right of,
Speaker 3: like you can have all of your internal APIs working
Speaker 3: perfectly and are beautifully tested, but then when you fit
Speaker 3: them all together, things explode. So as a result, like
Speaker 3: I've always found with CLIs in particular, like really taking
Speaker 3: that sort of outside in testing approach is really nice
Speaker 3: to ensure that you're like, okay, so say again, we're
Speaker 3: talking about this opening CLI type thing. Like if I
Speaker 3: was writing a CI pipeline to test that, I would
Speaker 3: probably give giob actions my like either my or test
Speaker 3: open ei key, and I would have it in CI
Speaker 3: like actually trying to run a transcribe command on maybe
Speaker 3: like a single word or some very short amount of
Speaker 3: input data and actually making sure that as close to
Speaker 3: a real use of that application is actually being tested
Speaker 3: and working as expected, because all the kind of clever,
Speaker 3: like all the cleverer unit tests you might have will
Speaker 3: just otherwise fall over when you need them the most.
Speaker 2: Yeah, I like it makes sense. I'm gonna oh, go ahead.
Speaker 3: I was just gonna say, so another thing you might find,
Speaker 3: I guess as I've been talking about, like CLI performance,
Speaker 3: because it's sorts in front of my mind with this stuff.
Speaker 4: So there's a guy.
Speaker 3: Who's written loads of really helpful little CLIs and rust
Speaker 3: I forget his name off the top of my head,
Speaker 3: but we can find him Google him later or whatever.
Speaker 3: So he's got a really nice tool he's built called
Speaker 3: hyper Fine, which is a CLI benchmarking tool. Basically it
Speaker 3: does a bunch of other things, but that's what I've
Speaker 3: found it most useful for. So what that does is
Speaker 3: it takes this sort of outside and approach and you
Speaker 3: can say like, hey, I want you to run this
Speaker 3: command this many times and then tell me like what
Speaker 3: the performance characteristics are, or I want you to run
Speaker 3: this command and this command and tell me the difference
Speaker 3: between the two. So quite often when I'm doing like
Speaker 3: Homebrew performance work, the way I will measure the performance
Speaker 3: differences is like that command could include like checking out
Speaker 3: a brunch, or you can you should specify that as
Speaker 3: like preparatory command or whatever. So I'll say, okay, check
Speaker 3: out this brunch, run this Homebrew command, then check out
Speaker 3: this brunch, run this homboric command, and then it just
Speaker 3: has a nice little display of almost like well, when
Speaker 3: you run this command, it's one point four times faster
Speaker 3: on average, and that varies by like two percent like
Speaker 3: across the iterations, and it will I think everyone's at
Speaker 3: ten times by default, but you can you could say
Speaker 3: run this a thousand times or two times or whatever,
Speaker 3: and there's like as you might expect for kind of
Speaker 3: a beautiful like proper cli.
Speaker 4: Nerd cli like this.
Speaker 3: You know, there's like so many different options to twiddle
Speaker 3: every possible knob to get it to work exactly how
Speaker 3: you want it to. But yeah, but if you're ever
Speaker 3: in a world where you're like I really care about
Speaker 3: the perform Morman's implications of my cli, like that is
Speaker 3: the best tool I've ever used and works basically exactly
Speaker 3: how i want it to because it does that inside
Speaker 3: out testing right of like actually running the actual process
Speaker 3: and then measuring the actual time that like it runs forth.
Speaker 4: So big shout out the hyper fine.
Speaker 2: Yeah, the I found it on GitHub.
Speaker 1: It's David Peter and or shark dp is his gethub handle,
Speaker 1: And yeah, yeah, looks like a cool tool because.
Speaker 2: I wanted to switch gears a little bit.
Speaker 4: Yeah please, So I was.
Speaker 1: I wound up on your blog when I was getting
Speaker 1: ready for the episode, and you have an article on
Speaker 1: here and we've wound up talking about AI, and it
Speaker 1: seems like it's still the hot topic. It's funny because
Speaker 1: over the last i don't know, three four or five months,
Speaker 1: I've really started to use AI quite a bit. Sometimes
Speaker 1: I use it essentially to write most of the code,
Speaker 1: and then I have people, you know, get concern learned
Speaker 1: about whether AI is going to take people's jobs and
Speaker 1: things like that, which you address in your article here
Speaker 1: it says open source maintainers thrive in the LM era.
Speaker 1: You know, you address some of that, and you talk
Speaker 1: about how people are using lms and things like that.
Speaker 1: I'm just wondering, like, what's your experience using LLLM tools
Speaker 1: like Cursor or Copilot. And then the other question I
Speaker 1: have is, and you kind of address it here, is
Speaker 1: is there any hope for the people that are freaked
Speaker 1: out that AI is going to take their programming job?
Speaker 3: Yeah, so I guess I'll make sure I get to
Speaker 3: both of those. But yeah, I guess the experience wise,
Speaker 3: I've been probably using some sorts of tools and some
Speaker 3: cost of capacity since the very early days. So like
Speaker 3: back when Copilot was still an internal alpha, I get
Speaker 3: help based on I.
Speaker 4: Think GPT too to start with.
Speaker 3: Yeah, and opening I had publicly not really done anything
Speaker 3: except released a bunch of papers. Yeah, Like I was
Speaker 3: asked to test it internally essentially, and like I was
Speaker 3: known for being the type of person who was good
Speaker 3: if you wanted honest opinions of the things. I was
Speaker 3: testing because regardless of the political consequences, if you asked
Speaker 3: me to test some thing and I thought it was
Speaker 3: all trash, try to be nice about it, but like
Speaker 3: I would not tell you that it was great. I
Speaker 3: would tell you that it was not great. But yeah,
Speaker 3: So I remember trying this and being like this will
Speaker 3: because I'm sure people it's almost hard to even remember.
Speaker 3: But like if you put yourself back in whatever this
Speaker 3: was like twenty twenty one or something like that, Like
Speaker 3: you know, if someone had described what you're able to
Speaker 3: do now with Copola or Cursor and they said I
Speaker 3: built a thing that does this, you would be like
Speaker 3: your eyes would roll out your head and then you'd
Speaker 3: be like okay, like yeah, whatever. Like I've seen a
Speaker 3: lot of autocomplete, like right, it always sucks. It just
Speaker 3: gets in the way. It's annoying, it's not useful. Like
Speaker 3: I write Ruby now, the auto complaint in Ruby sucks.
Speaker 3: I don't really care and I don't really miss it
Speaker 3: anymore because I've got used to it and whatever. This
Speaker 3: is just yeah, nothing that I care about, right, and
Speaker 3: I try to and like my almost immediate reaction was
Speaker 3: like even in when it was way more limited, was like, wow,
Speaker 3: this is this is not like radically transformative yet, this
Speaker 3: is not incredibly workflow changing yet, but this is really good.
Speaker 4: And this is a lot better than I expected.
Speaker 3: And ironically, you could build a pretty damn good autocomplete
Speaker 3: without any specific knowledge of Ruby as a language, but
Speaker 3: just using this kind of LM technology. And I said
Speaker 3: to the team, I was like, yeah, I assumed this
Speaker 3: would be complete garbage and it's actually good, well done,
Speaker 3: Like can I keep using this please? So yeah, So
Speaker 3: I guess I went from that to use and copolitive.
Speaker 1: I just want to chime in that lines up with
Speaker 1: my early experience with a lot of it, where it
Speaker 1: was it was a little beyond autocomplete, and it didn't
Speaker 1: always give me what I wanted, Like sometimes it was
Speaker 1: like you are assuming that I am doing something wildly
Speaker 1: drastically different from what I'm doing, but it was it
Speaker 1: was right often enough to where it was like, Okay,
Speaker 1: I definitely want this turned on.
Speaker 3: And I think that's the thing like in the early
Speaker 3: days particularly, and I think maybe some people who tried
Speaker 3: stuff out too early of over index on this. I
Speaker 3: think it was very personal in terms of like what
Speaker 3: what's the hit rate? Because I mean, I find this
Speaker 3: with self engineers in general. Right, is there some selfware
Speaker 3: engineers I know who will completely genuinely, without any sense
Speaker 3: of irony, will express but this only solves the customer
Speaker 3: problem ninety nine percent at the time. Therefore it's pointless
Speaker 3: one percent of the time. Why would you ever do that?
Speaker 3: And so well, actually, for most people, if this makes
Speaker 3: things one hundred times faster ninety nine percent at the time,
Speaker 3: which I'm not saying AI does, but like in some
Speaker 3: declative software cases, things do, that's probably an enormous amount
Speaker 3: of business value for a lot of people, right, Right,
Speaker 3: But there's we have and I don't think it necessarily
Speaker 3: a bad thing, but we tend to have a streak
Speaker 3: as a you know, we're literally the people of zeros
Speaker 3: and ones, right, So it's like we want things to
Speaker 3: be perfect, and when things are perfect, it's easy to
Speaker 3: kind of fawardto the like, well one did I bother, like,
Speaker 3: you know, what's the point? Yeah, And I definitely think
Speaker 3: there's only lms, like the only copilot, it's like the
Speaker 3: autocompletion was you know, if that's wrong fifty.
Speaker 4: Percent of the time.
Speaker 3: There's a lot of people who just find it really
Speaker 3: really annoying, Whereas I'm the type.
Speaker 2: Of person, yeah, but it sped me way up.
Speaker 3: Exactly, Like Whereas I think I'm lazy enough that I'm
Speaker 3: like if fifty percent of the time I can just
Speaker 3: like I'm a reasonably fast type or I was never
Speaker 3: one of those like hyper fast. I've switched to the
Speaker 3: Vorac because it gets me an extra ten per second whatever,
Speaker 3: like VIM keyboard warrior types. So for me, like I'm like, oh, yeah,
Speaker 3: you know, like half as much typing some of the
Speaker 3: time is well worth it for me, right, and I
Speaker 3: can I feel able.
Speaker 4: To ignore the visual noise of it always.
Speaker 3: Trying to prompt me to do the wrong thing, right,
Speaker 3: And some people wait that and I guess it right,
Speaker 3: But yeah, I guess I would say if you're one
Speaker 3: of those people who I hated that in you know,
Speaker 3: maybe even six to twelve months ago, like you should
Speaker 3: check back in because things are changing, yeah very fast.
Speaker 2: Right.
Speaker 1: Yeah, So kind of getting into the question that I'm asking,
Speaker 1: I'm enjoying this, right, I'm not saying you didn't get
Speaker 1: to the point, of course. What I'm saying is so
Speaker 1: like this morning, right or last night, I think it
Speaker 1: was last night I started it, and then this morning
Speaker 1: I finished it. But you know, I'm expanding my podcast
Speaker 1: hosting system which also does courses in summits and coaching
Speaker 1: and podcasts and screencasts, right, because that's all stuff I
Speaker 1: want to offer off of the back of the podcasts.
Speaker 2: Right.
Speaker 1: I was like, okay, well, I've got this multi tenant
Speaker 1: setup going, and so I need people to be able
Speaker 1: to sign up, right and actually pay me to use
Speaker 1: the system. And so I said, hey, I need a
Speaker 1: sign up for him. And I mean, it wrote all
Speaker 1: the views and rails, It wrote all the management and
Speaker 1: the admin system, It wrote you know, and and it
Speaker 1: basically worked. I mean I had to tweak a couple
Speaker 1: of things because you know, it was like, okay, you
Speaker 1: you know, you.
Speaker 2: Got this wrong.
Speaker 1: And then when I asked to do something else, it
Speaker 1: changed it back and I had to go in and say, no,
Speaker 1: actually you did it wrong the first time.
Speaker 2: But I mean it it.
Speaker 1: Would have taken me a day or so to figure out,
Speaker 1: you know, to actually build it out on my own, right,
Speaker 1: go in and put everything together. It's all pretty basic stuff,
Speaker 1: but it I mean, it just wrote it in like
Speaker 1: twenty minutes, right, and then and then the tweaking took
Speaker 1: me probably another forty five minutes, and so I can
Speaker 1: see people looking.
Speaker 2: At it and going, this thing is going to take
Speaker 2: my job.
Speaker 3: Yeah, And I understand why people think that, and I guess, like,
Speaker 3: to me, it would be when someone with your level
Speaker 3: of experience, Charles, is able to do that and there
Speaker 3: is zero tweaking, and like, I've done this one hundred
Speaker 3: times in the last two weeks and never any point
Speaker 3: if I had to change a single character like that
Speaker 3: would be when I would be more concerned about being like, well,
Speaker 3: you know, maybe I still think the job of being
Speaker 3: a software engineer wouldn't go away in that case, because
Speaker 3: I think we are even outside of the programming. Right,
Speaker 3: my was cooking some sweet potato in the air fryer yesterday, right,
Speaker 3: and my wife and I both use Chattypata, and I
Speaker 3: transcribed at using voice, and she heard the way in
Speaker 3: which I speak to CHATCHYPT and the amount of context
Speaker 3: I gave it about like here's some facts about my
Speaker 3: particular sweet potato and how I like it, here's some
Speaker 3: facts about my air fryer and whatever.
Speaker 4: And she was like, wow, like you you said a
Speaker 4: lot of.
Speaker 3: Stuff there, whereas I would just be like cook sweet
Speaker 3: potato in air fryer, right, and the proplet she would
Speaker 3: get back would be pretty poor, And the prop that
Speaker 3: I get back is amazing, Right.
Speaker 4: So I guess some.
Speaker 3: People talk about like prompt engineering or context engineering or whatever,
Speaker 3: but like, I think there's more to it than that,
Speaker 3: and I think there's a reason why the experts in
Speaker 3: prompt engineering or context engineering don't just happen to be
Speaker 3: like international tennis players or philosophers or whatever. Like there's
Speaker 3: mostly software engineers, or at least software adjacent people, because like,
Speaker 3: this is still talking to computers, and computers still like
Speaker 3: to be talked to in a like LM's like to
Speaker 3: be talked to in a different way to you know,
Speaker 3: your CPU.
Speaker 4: But it's still sort of an art and a craft
Speaker 4: in that way.
Speaker 3: And like I can definitely imagine almost the worst case
Speaker 3: scenario of when you're gonna be writing a lot less
Speaker 3: code by hand than you ever were before, and for
Speaker 3: some people that really bums them out and freaks them out.
Speaker 3: But I still think that job of like I take
Speaker 3: customer requirements and turn them into software, that's still a job, right,
Speaker 3: And that's still a hard job, and it's still a
Speaker 3: job that someone like yourself, with a lot of experience
Speaker 3: you are able to work with LMS dramatically more effectively
Speaker 3: than a random person who started coding two months ago.
Speaker 2: Right, Yeah, I agree.
Speaker 1: There are a couple of things you kind of talked
Speaker 1: through that I want to touch on. I mean, one
Speaker 1: of them is, yeah, you figure out what essentially what
Speaker 1: context you have to give it, right, so you give
Speaker 1: it all of the information it needs so it can
Speaker 1: break it down and go okay that this is this
Speaker 1: is what I'm working with, and then yeah, it'll give
Speaker 1: you a much better response. One other thing that I
Speaker 1: found that just kind of comes with experience with the
Speaker 1: LLMS is that and this came up today, like I
Speaker 1: forgot to tell it I'm not using device on my
Speaker 1: Rails app, and so it actually said right because I
Speaker 1: told it. I was like, you need to send an
Speaker 1: email confirmation when people sign up for the system, right,
Speaker 1: not just a welcome email, because I need to confirm
Speaker 1: that their email works. And so it turned around and
Speaker 1: it said I see that you're using device confirmable and
Speaker 1: I immediately had to get in and stop it and
Speaker 1: say I am not using device right then, and then
Speaker 1: it did the right thing, and so.
Speaker 2: You know, I had to remember that.
Speaker 1: And so some of that with the prompt engineering, Yeah,
Speaker 1: you figure out what context it needs in order to
Speaker 1: make the right decision, and then you give it to it.
Speaker 1: And a lot of it, too, is just being thorough
Speaker 1: right so that it doesn't make any assumptions. I know,
Speaker 1: we're kind of answerpromorphizing the LM and it's just a
Speaker 1: predictive language model, but you know, yeah, it doesn't make
Speaker 1: any assumptions on what you want. And so yeah, some
Speaker 1: of it's going to just boil down to, yeah, I'm
Speaker 1: the human that's giving it a proper prompt that gives
Speaker 1: me better outputs. But the other thing is is that, yeah,
Speaker 1: I still find that I have to tweak it, or
Speaker 1: at least I have to verify it right. Even if
Speaker 1: I didn't have to touch it, I have to verify
Speaker 1: that it does the thing right. I have to spin
Speaker 1: up my app and go and click through it or
Speaker 1: write or if it's a CLI, you know, I have
Speaker 1: to run it a couple of different ways to make
Speaker 1: sure that it's still doing what I want.
Speaker 2: And so there's that too.
Speaker 1: And then the last thing that I'm going to just
Speaker 1: point out is like, I'm not seeing companies laying people
Speaker 1: off saying, well, you know, we're using the LLMS to
Speaker 1: enhance the capabilities of our programmers and so we don't
Speaker 1: need half of them anymore.
Speaker 2: We're not seeing yet.
Speaker 1: What we're seeing is we're seeing companies go, we can
Speaker 1: get ten times the work done or you know, five
Speaker 1: times the work done, are double the work done by
Speaker 1: having the engineers that we have use the tools.
Speaker 2: And I think that just accelerates.
Speaker 1: And I think any company that's shortsighted enough to turn
Speaker 1: around and go, we're going to lay off half of
Speaker 1: our technical workforce, their competitors are going to come in
Speaker 1: and eat them alive.
Speaker 2: Yeah.
Speaker 3: Yeah, I think that's some people that speculate that's the case,
Speaker 3: some companies hint towards that being the case, But I
Speaker 3: don't think it's. I think what you are seeing, and again,
Speaker 3: I think if we're talking about things that you can
Speaker 3: be freaked out about, is like, there's definitely been a
Speaker 3: big drop in hiring for juniors, right, like this measurable
Speaker 3: decrease in junior engineering positions. And I think there is
Speaker 3: this outstanding question of like, again, you and I have
Speaker 3: touched upon this already right, Like I say in that post.
Speaker 3: One of the reasons why I talk about like why
Speaker 3: I think open source maintainers are well clout for they
Speaker 3: for the llm ROR. Right, is that conversation you mentioned before,
Speaker 3: if you were talking about building something an open source project,
Speaker 3: you could have equally been describing almost identically, some.
Speaker 4: Contributor you've never worked with before.
Speaker 3: Right, It's like, oh, well, you know what, I opened
Speaker 3: an issue and then overnight some random person I never
Speaker 3: met before appeared.
Speaker 4: They made a pr like it was mostly.
Speaker 3: All right, I had to make some tweaks, and then
Speaker 3: I emerged it right like, And I actually think the
Speaker 3: trust and verification process looks very similar, right for someone
Speaker 3: like yourself with a lot of experience, someone like me
Speaker 3: with a lot of experience, particularly if you have a
Speaker 3: lot of experience with one code base you've worked with
Speaker 3: for a long period of time, like you're able to
Speaker 3: provide probably very in depth review of a relatively large
Speaker 3: amount of code in a very short amount of time
Speaker 3: in a way that makes these tools valuable to you.
Speaker 3: Right if you were you were unable to do that
Speaker 3: either because you lack the experience, you lack the contact
Speaker 3: with the codebase, you lack the program and buility yourself.
Speaker 4: Then all of a sudden you get end up in.
Speaker 3: This pre care position where it's like, okay, either I
Speaker 3: go one hundred miles an hour and like if this
Speaker 3: stuff breaks, I wonder how to fix it, and I
Speaker 3: won't know even really how to describe to the LLM,
Speaker 3: like what's gone wrong beyond just copy pasting error messages
Speaker 3: and when when that fails, like I'm just shit out lunk, right,
Speaker 3: or I slow down and I say, okay, I just I'm.
Speaker 4: Going to learn software the same way everyone learns software
Speaker 4: before LMS.
Speaker 3: Right, And then the people that I have to kind
Speaker 3: of have a bit of the FOMO or even potentially
Speaker 3: my management chain being like, hey, all the seniors are
Speaker 3: like twenty five or fifty percent more productive, now why
Speaker 3: aren't you? And it's I'm glad I'm not responsible for
Speaker 3: social engineering or whatever, because like I think that's a
Speaker 3: really hard question of like what are we going to
Speaker 3: do as an industry, because we can't just say we
Speaker 3: don't hire more juniors anymore, because that's not going to work.
Speaker 3: But at the same time, I don't think we have
Speaker 3: a really good answer for like what the juniors should definitely.
Speaker 4: Do to scale up, right.
Speaker 1: Like, Yeah, it's hard, Yeah, I like, I like, I
Speaker 1: completely agree with you. I think kind of reading between
Speaker 1: the lines on your blog post, it seems like part
Speaker 1: of the answer is having juniors or people who are
Speaker 1: at that level doing open source with you, right, because
Speaker 1: then it's not you don't have your boss or your
Speaker 1: company or the deadlines or things like that where people
Speaker 1: are going, why are you taking so long? And then
Speaker 1: the other thing is is that if you do take
Speaker 1: the extra minute, even if you're still generating the code
Speaker 1: with AI, to then ask the LM okay, explain to me.
Speaker 2: What you just did.
Speaker 1: Yep, right, you can start to get context for what
Speaker 1: it did and why it did it. Now it may
Speaker 1: not be giving you the best practice, but it's giving
Speaker 1: you at least some context for what it's working with,
Speaker 1: and in some cases it is.
Speaker 2: Going to be best practice or at least common practice.
Speaker 3: So and you're seeing that even with LMS now right now,
Speaker 3: like the kind of study mode and chat GPT and
Speaker 3: things like that, where I've played with that a little
Speaker 3: bit myself when I've been kind of trying to learn
Speaker 3: new things that I don't want to overlylean on the LM,
Speaker 3: and you know, it's kind of trying to do a
Speaker 3: bit of Socratic method stuff and all this sort of thing.
Speaker 3: But even with I think it's a great point for
Speaker 3: the open source where you know, there's a bunch of
Speaker 3: talented homer maintainers I know who are in some cases
Speaker 3: haven't had a tech job yet, are still in college
Speaker 3: or relatively recently out of college, and like their code
Speaker 3: reviewabilities for typical expectations of like a new engineer are
Speaker 3: like completely off the charts. Like some of them are
Speaker 3: dramatically better at code review than I am, having done it,
Speaker 3: you know, probably ten times as.
Speaker 4: Long as they have, but they've had a lot of
Speaker 4: experience doing this.
Speaker 3: And I think that might be part of the junior
Speaker 3: story is that I think we cycle we sort of
Speaker 3: had a little bit of an attitude I think for
Speaker 3: a while, at least in some cultures of companies I've
Speaker 3: seen where it's like, well, okay, we'll get everyone to
Speaker 3: view a bit of code, but really like the more
Speaker 3: senior people are going to be more responsible for doing
Speaker 3: the more in depth hardcore code review of like gnarly stuff, right,
Speaker 3: And that might be the culture that needs to change,
Speaker 3: but we're actually like, okay, rather than saying to the
Speaker 3: junior is like, hey, you just spend ninety five percent
Speaker 3: of your sign coding. Don't worry about this code review
Speaker 3: stuff too much. You'll figure it out as you go along.
Speaker 3: Maybe we need to flip around and be like, actually,
Speaker 3: you should spend ninety five percent of your time doing
Speaker 3: code review and don't worry about this coding stuff too much.
Speaker 3: If you read enough of other people's code, you're going
Speaker 3: to figure that out, right, And maybe that's where we go.
Speaker 3: And certainly that that would be an attitude that would
Speaker 3: make you more qualified with working with LMS better for sure.
Speaker 1: Right, you brought up code reviews and that that kind
Speaker 1: of reminded me of another thing, since we're talking about
Speaker 1: AI and things like that. So yesterday I put in
Speaker 1: a PR at work, and I asked some folks to
Speaker 1: review it, and I got on this morning and it
Speaker 1: still hadn't been reviewed. Whenever people get in and they
Speaker 1: see the message, I'm sure it'll get done. Anyway, When
Speaker 1: I checked it, get how asked me if I wanted
Speaker 1: Copilot to review my PR?
Speaker 2: So, how do you feel about that?
Speaker 3: Yeah, I've actually at work brew and now at Homebrew
Speaker 3: and some companies have done contracting with have enabled. In fact,
Speaker 3: I don't know if I've done this on humbrew actually,
Speaker 3: but basically, whenever I can, I enable enable copilot review
Speaker 3: of prs by default, and I think good. It's sort
Speaker 3: of so it has definitely caught a bunch of stuff
Speaker 3: that humans have not caught on my prs. Again, the
Speaker 3: false positive rate is like pretty high, but if what
Speaker 3: you're concerned about is like, hey, I want to make
Speaker 3: sure that someone is going to catch my typos again.
Speaker 3: Like another blog post I wrote a long time ago,
Speaker 3: and at this time, you know, this was whatever twenty
Speaker 3: eighteen or something, so we weren't even talking about AI
Speaker 3: and LMS, but I think it still kind of holds
Speaker 3: up is I wrote about like I called it like
Speaker 3: robot pedantry human empathy basically, And what I compared in
Speaker 3: that post was like, on the one side, like people
Speaker 3: are like ruber Cup, you can set to be like
Speaker 3: hyper anal right and like really really pedantic and people
Speaker 3: could actually be fairly tolerant of that. I actually quite
Speaker 3: like that when it's dial up to eleven like that.
Speaker 3: But if you, as a human give the same code
Speaker 3: review feedback as a ruber cup up to eleven.
Speaker 4: All your coworkers will hate you.
Speaker 3: Yeah, often, even if you have agreed on these coding
Speaker 3: guidelines as a group or whatever. There's something about like
Speaker 3: that level of pedantry, about like if someone typo something
Speaker 3: ten times going through and every single time being like
Speaker 3: typo typo, typo, typo typo, even if you use the
Speaker 3: gat up suggestion, so it's one click for them to
Speaker 3: fix it. Like, people don't like that. They really hate
Speaker 3: it when humans do that to them. But that's the
Speaker 3: expectation that robots will do that. So that's one thing
Speaker 3: I found is like useful on that side. But then again,
Speaker 3: like I said in that post, so part of why
Speaker 3: I wrote the post of the time is like there'd
Speaker 3: be more and more moved like ultimate shown and stuff
Speaker 3: like that, which I thought was really healthy and like CEI,
Speaker 3: but you were starting to see people being like, oh,
Speaker 3: the first time someone makes a poll request on my repo,
Speaker 3: we should congratulate that person, So let's write a bot
Speaker 3: to congratulate them. And I remember talking to a bunch
Speaker 3: of people and they were saying like, yeah, it just
Speaker 3: it feels completely meaningless when a bot says well done,
Speaker 3: good job, you are rockstar. Now it's like, you know,
Speaker 3: it's like I'm in some empty room by myself, and
Speaker 3: you know, over the Tanoi came a robotic voice saying
Speaker 3: you are great.
Speaker 4: You know.
Speaker 3: It's like whereas if a human says to you, hey, right,
Speaker 3: well done.
Speaker 4: Like I'm Pumpedy or here, like, that actually has an impact.
Speaker 3: So that's and I think this is the same thing
Speaker 3: with with kind of code of View and Copilot and
Speaker 3: these tools and whatever. Now it's just like, you know,
Speaker 3: like Copilot can give you a review where it points
Speaker 3: out your typo is more effectively than a human can,
Speaker 3: but Copilot can't say, wow, that was really cool, Like
Speaker 3: do you solve this in half the lines of code?
Speaker 4: I thought it's possible, Like this is a really elegant solution.
Speaker 4: Great job, right like.
Speaker 3: And that's again much as like the stuff about humans
Speaker 3: and jobs and whatever, right like, most of us are
Speaker 3: probably not going to be okay with spending forty hours
Speaker 3: a week exclusively communicating to an LM, Like we want
Speaker 3: to deal with humans who say nice things that they
Speaker 3: actually mean that are not in the prompt right like,
Speaker 3: and that does have more of an impact and that's
Speaker 3: I feel the same way with like code review, where
Speaker 3: it's like these are complementary tools, and the human code
Speaker 3: review and the code of view are sort of doing
Speaker 3: different things, but I'm glad that they're both there, and
Speaker 3: I wouldn't use one to entirely replace the oiler.
Speaker 1: So I guess the other question that I was asking
Speaker 1: is what AI tools are you using these days?
Speaker 3: Yeah, So for me, I'm mainly using like cursor as
Speaker 3: my kind of in editor like code completion thing, and
Speaker 3: like their agent modes kind of sporadically by again, I
Speaker 3: use it kind of in the in editor fashion. I
Speaker 3: still use chat GPT mainly for stuff where I'm just
Speaker 3: like asking it things where I'm going to probably write
Speaker 3: the code myself or with a bit of health, but
Speaker 3: like I basically use that insteady Google. And then the
Speaker 3: thing that has been interesting to me recently is so
Speaker 3: I started everyone was being like all my kind of
Speaker 3: AI forward friends were like, oh, you need to use
Speaker 3: cloud code, cloud code, so sign up play on cloud code.
Speaker 4: I was like, Okay, this is quite good. I can
Speaker 4: see the appeal.
Speaker 3: But I think just because I'm an open source maintainer,
Speaker 3: like there's this GitHub agent pr thing where you can Now,
Speaker 3: if you have Copilot for your organization or whatever, I'm
Speaker 3: not quite sure how the pricing and the enabling works
Speaker 3: or whatever, but it works on Humbrew essentially.
Speaker 4: So what you can do is.
Speaker 3: You can just assign an issue to Copilot and then
Speaker 3: it will just open a pr that's like, okay, I've
Speaker 3: tried to solve this issue for you, right, And this
Speaker 3: is good that we're having this conversation today because it's
Speaker 3: fairly timely because in the last week Humbrew had I
Speaker 3: think eight open bugs on the main kind of package
Speaker 3: manager repo that I review everything on. I was like,
Speaker 3: I'm just going to sign all of them to Copilot
Speaker 3: and see what happens. Right, And it's similar to the
Speaker 3: thing you described earlier right where it was like in
Speaker 3: most in a couple of cases it was like literally
Speaker 3: spot on first time.
Speaker 4: In most of the cases it required me to do
Speaker 4: the last.
Speaker 3: Like ten percent of the code right, and then in
Speaker 3: a couple of cases it was like twenty five percent
Speaker 3: of the way. They are pretty broken. I had to
Speaker 3: have quite a bit back and forth. I ended up
Speaker 3: kind of rewriting half of myself. But even then it
Speaker 3: sort of solved the empty page problem for me, And
Speaker 3: I think it's just something about me is like an
Speaker 3: open source maintainer that it feels good and nice to
Speaker 3: just be like assign issue PR, review PR, check out PR,
Speaker 3: to finish it off, march PR, and like that's the
Speaker 3: flow instead of like this thing that lives in my
Speaker 3: terminal that I need to check and whatever.
Speaker 1: Yeah, I like, I like you you brought up the
Speaker 1: empty page situation that that's a really good way of
Speaker 1: putting right, because I'll sit there and Okay, how do
Speaker 1: I need to put this? Okay, and then I kind
Speaker 1: of have an idea of how I wanted to go,
Speaker 1: and so I start kind of fiddle in with it, right,
Speaker 1: And instead I can just I can prompt the AI
Speaker 1: this is what I'm building. And sometimes I'll ask, you know,
Speaker 1: how should I start, And sometimes I'll just tell it
Speaker 1: to go for it.
Speaker 2: Yeah, I'm sure.
Speaker 3: And I found this as well, like sometimes when it's
Speaker 3: even when it's completely wrong.
Speaker 4: Yeah, you probably heard.
Speaker 3: That, like a comber who said this ages ago that
Speaker 3: like the quickest way to get a stack overflow answer
Speaker 3: is to answer your questions with the wrong answer.
Speaker 4: Yeah, and then everyone will jump in and be like, no,
Speaker 4: that questions wrong. Let me tell you how it actually is.
Speaker 3: Sometimes I feel like the same way with the LM stuff,
Speaker 3: where I'm like, yeah, sometimes it goes off and it
Speaker 3: doesn't completely fucking terrible.
Speaker 4: And I'm like, no, that's not how you do it.
Speaker 4: You obviously do it like this, and I'm like, oh, yeah,
Speaker 4: I figured out how to do it.
Speaker 2: Well.
Speaker 1: What's funny is that there were there were a couple
Speaker 1: of things that I was working on with the because
Speaker 1: I'm using Curser and agent mode. The main reason is
Speaker 1: is because my employer provides us with credits on co
Speaker 1: Pilot YEP on vs Code, which is what I'd kind
Speaker 1: of gotten used to, but I don't want to use
Speaker 1: works co Pilot credits on my personal stuff, and so
Speaker 1: I use Cursor for my personal stuff and Copilot for
Speaker 1: their stuff because I'm using the same gethub account for both.
Speaker 1: And so anyway, there have been a couple of times
Speaker 1: where I've pulled it to do something and it sits
Speaker 1: there and it flails right, It's like, yeah, I'm going
Speaker 1: to do this. Oh wait, I think I have a
Speaker 1: better approach, So I'm going to delete everything I just
Speaker 1: did and do it this way, and they'll do like
Speaker 1: two or three things and yeah, I'll finally just step
Speaker 1: in and say I've been watching you and actually I
Speaker 1: just want you to do it this way, and it'll
Speaker 1: just turn around that. Of course, it tells me I'm
Speaker 1: smart for saying that, right, And again it's like you're
Speaker 1: a machine, you know, but do it my way. And yeah,
Speaker 1: and so just because it gets it wrong doesn't mean
Speaker 1: that it can't get it right if you give it
Speaker 1: just a little more a direction.
Speaker 3: And to just speculate widely from a minute, I also
Speaker 3: have hypolthesis that maybe the reason why junior hiring could
Speaker 3: be done is the people who were previously responsible from
Speaker 3: entering those juniors are now essentially mentoring their lms because
Speaker 3: like again that flow you described earlier about like with
Speaker 3: rails and oh they thought I was using device and
Speaker 3: I wasn't like that. Again, ten years ago, you could
Speaker 3: have described some new talented junior person that you hired,
Speaker 3: right and oh wow, they saved me so much time
Speaker 3: and I had to do the last a little bit
Speaker 3: to help them over the line and whatever. I think
Speaker 3: the flow and also like the stuff you like and
Speaker 3: the stuff that's really frustrating and exhausting about it is
Speaker 3: kind of the same. And I personally couldn't imagine a
Speaker 3: day where I spend half my days supervising agentic AI
Speaker 3: workflows and then the other half doing the same thing
Speaker 3: with like junior folks who are struggling in the same way,
Speaker 3: or the worst of both worlds, which we're seeing in
Speaker 3: open source now, which is someone who is junior who
Speaker 3: is trying to use an AI agent to create a
Speaker 3: pull request. And obviously you can't really prove this, but
Speaker 3: like I had a PR today where which round a
Speaker 3: review they were responding, and then they would paste something
Speaker 3: into an issue comment with like the slash and characters
Speaker 3: in there rather than you lines, which makes it look
Speaker 3: like it was automated, And then I would ask.
Speaker 4: I'd be like, give a bunch of comments.
Speaker 3: But then one of the comments would be like, hey, like,
Speaker 3: you've added two extra options to the CLI.
Speaker 4: Which one of those are you using? Do you need
Speaker 4: both this functionality or just the functionality for one?
Speaker 3: Because if we just say the functionality, if you only
Speaker 3: you need for one, and they would just completely ignore
Speaker 3: these questions and just turn it into more code. And
Speaker 3: I had that AI feel that I'm sure you're familiar
Speaker 3: with Charles of just like more code every time.
Speaker 4: Every time.
Speaker 3: The solution is we're just going to add more code, right,
Speaker 3: And it got to the point where I was like,
Speaker 3: I'm just speaking to someone's cloud code through If I
Speaker 3: wanted that, I would be using cloud code.
Speaker 4: Myself, so I couldn't prove it.
Speaker 3: But I just closed the PR because I was like, sorry,
Speaker 3: feels like I'm speaking to an AI, not human. And
Speaker 3: I thought to myself, I'll probably just assign this issue
Speaker 3: to compile later and see how it does, and it's
Speaker 3: probably going to be easier than what we're doing.
Speaker 2: Oh gotcha.
Speaker 1: All right, Well, I've got to start wrapping up, so
Speaker 1: let's go ahead and do some picks and then we'll
Speaker 1: call it good. Before we do that, if people want
Speaker 1: to connect with you, if they have questions about Homebrew,
Speaker 1: or it sounds like you will help people out for
Speaker 1: hire or at least you used to, so if there's a
Speaker 1: place for people to hire you.
Speaker 2: I'd love to have that too.
Speaker 1: But yeah, how do people connect with you on any
Speaker 1: of those levels?
Speaker 2: Yeah?
Speaker 3: Sure, The best place for me is my website at
Speaker 3: Mike mccaid dot com.
Speaker 4: If you go there, that's called links to all my
Speaker 4: social media.
Speaker 3: It's got all my email, it's got talks or art
Speaker 3: schools and all the type of stuff anything you might
Speaker 3: want to know about me.
Speaker 4: That's basically the best kickoff point.
Speaker 1: They're awesome, all right, Well let's go ahead and do
Speaker 1: some pics. I will get us started. Boy, it's been
Speaker 1: a while since I've done this. I'm trying to think
Speaker 1: of what games I've been playing lately. Here's one that
Speaker 1: I'll do. So, I don't know if you do board
Speaker 1: games much, but yeah, I do a little, not huge amounts.
Speaker 2: Have you ever played.
Speaker 4: Again, like a couple of times. I've never been a
Speaker 4: DM or.
Speaker 1: Okay, So there's a game out there called Betrayal at
Speaker 1: House on the Hill, and I think that there's a
Speaker 1: book or a movie or something that related to it.
Speaker 2: Anyway.
Speaker 1: Essentially, you take your Scooby Dooe gang into a haunted
Speaker 1: house and you go explore the house until the how
Speaker 1: haunt starts and then you yeah, one of you becomes
Speaker 1: the trader and so then it's the Trader against the
Speaker 1: explorers until one of you wins, right, and so it
Speaker 1: gives you you know, and there are two books. There's
Speaker 1: the Trader's home, and there's the Explorer's Manual, and so
Speaker 1: the Explorer's Manual explains to them how they win, and
Speaker 1: the Trader's tom explains to the trader how they win.
Speaker 1: And the reason there are two books is because there's
Speaker 1: some things that the trader has to know that the
Speaker 1: explorers don't need to know, or it will let help
Speaker 1: them win if they knew. Anyway, so it does that. Well,
Speaker 1: there's a version of this called Betrayal of Balder's Gate.
Speaker 1: Balder's Gate is there's a video game, yeah, Balder's Gate,
Speaker 1: but Balder's Gate is a D and D location, and
Speaker 1: so if you ever look at anything that's Balder's Gate,
Speaker 1: you'll notice it's Wizards of the Coast, which is the
Speaker 1: company that does D and D and so anyway, so
Speaker 1: Betrayal at Balder's Gate is Betrayal at House on the
Speaker 1: Hill with the D and D elements from Balder's Gate.
Speaker 1: And so instead of exploring rooms, you're exploring areas. And
Speaker 1: you have the city like the streets, you have indoor areas,
Speaker 1: and then you've got the catacombs underneath the city, and
Speaker 1: so you can kind of explore or whatever you want
Speaker 1: and there's some differences, but yeah, the rest of the
Speaker 1: elements are the same. And so if you're kind of
Speaker 1: like that, it doesn't have like strong story elements. It
Speaker 1: really is just a you know, an explore and then
Speaker 1: you know, fight off the monsters game. But it's fun
Speaker 1: and yeah, I played it with my guys group a
Speaker 1: couple of weeks ago. Board game geek waits it at.
Speaker 1: I have six so you know, your casual gamers. It's
Speaker 1: mildly complicated, but not so complicated that, you know, folks
Speaker 1: that just like you know, a casual board game among friends,
Speaker 1: wouldn't just pick it up nice. So I'm going to
Speaker 1: pick that up. I'm going to pick that it came
Speaker 1: out in twenty seventeen. I don't know if it's still
Speaker 1: in print. That's the only caveat I have on that.
Speaker 1: And then on the other picks, yeah, I've really gotten
Speaker 1: into using the agent mode on Cursor, and so I'm
Speaker 1: going to pick that as well. Incidentally, I was just
Speaker 1: kind of goofing around and I thought, Okay, well, how
Speaker 1: much work would it be to get it to essentially
Speaker 1: vibe code React native app, a podcast subscription app.
Speaker 2: And I have to say that it did pretty good.
Speaker 1: It doesn't have all the features I want in it yet,
Speaker 1: but it's good enough to where I'm starting to think
Speaker 1: about whether or not I actually want to release the
Speaker 1: sucker onto the app stores. And so you know, and
Speaker 1: I'm not a React Native developer by any means though, again,
Speaker 1: that's another technology I want to pick up because we
Speaker 1: use it at work. So anyway, so I'm gonna I'm
Speaker 1: gonna pick that as well. And then within React Native,
Speaker 1: I'm using Expo.
Speaker 2: Yeah. Pretty cool. But yeah, Mike, what picks do you have?
Speaker 3: Yeah, so I guess my game related pick would probably
Speaker 3: be avowed. So that was recommended to be by don't
Speaker 3: know he's been on this pod before, but certainly legend
Speaker 3: of the Ruby community justin Searles. Oh yeah, sort of
Speaker 3: like you know, it's made by Obsidian. It's like a
Speaker 3: kind of Bethesda esque like story driven RPG and it's just,
Speaker 3: I don't know, like if you liked all those old
Speaker 3: school rpugs like Oblivion and Skyrim and whatever, it's got
Speaker 3: that vibe, but like lots of nice like quality of
Speaker 3: life things like, so if a character ever uses a
Speaker 3: sort of bit of jargon, you can just press a
Speaker 3: button and then a glossary pops up that sort of
Speaker 3: defines a specific bit of jargon they used, and I'm like, yeah,
Speaker 3: I want this in every RPG now, And like, you know,
Speaker 3: if you're a made you have a wand that casts
Speaker 3: stuff and it doesn't require man and you know, like
Speaker 3: lots of just like little things that have annoyed me
Speaker 3: in other games. So yeah, I'm enjoying just exploring that.
Speaker 3: I imagine it's one of those games I' probably gone
Speaker 3: hundred percent just because like the world is interesting enough.
Speaker 2: Yeah, what's it called again.
Speaker 3: It's called Avowed avowe D. And then my, I guess
Speaker 3: if you're not gamer like TV wise, we've been watching
Speaker 3: Tokyo Vice, which is pretty interesting about this guy who's
Speaker 3: a journalist and kind of lots of stuff with like
Speaker 3: organized crime in Japan. That's kind of what network it's
Speaker 3: on or whatever. But that's been good, so only two
Speaker 3: seasons of that. We're about halfway through the second season.
Speaker 3: Enjoying that a lot.
Speaker 4: And then I guess on the computer land.
Speaker 3: I guess, yeah, I mentioned it already, but I would
Speaker 3: probably say the copilot agent mode where you can assign
Speaker 3: it from assign it an issue and it will then
Speaker 3: create a pr there's a bunch of rough edges there,
Speaker 3: but there's something about the workflow that feels pretty different
Speaker 3: to like running agents locally, and has a different trust
Speaker 3: model in a good way in that like you can
Speaker 3: let it just run arbitrary commands and it's running in
Speaker 3: some random dog continuing and get ups infratructure that you
Speaker 3: don't care about compared to your local machine.
Speaker 4: But yeah, but for if you're someone who lives in
Speaker 4: prs all of the time.
Speaker 3: Then it might be worth seeing if that's an agent
Speaker 3: flow that works for you more than like some term
Speaker 3: or lap or some window in your right idea or whatever.
Speaker 2: Cool. Well, thanks for coming. This was fun.
Speaker 4: Yeah, thanks for having me always your fun line.
Speaker 1: Yeah, I'm gonna go ahead and wrap us up until
Speaker 1: next time, folks max out