Collin: 0:00

Hey, Joel, how, uh, how's your week?

Joel: 0:02

pretty good. How was yours?

Collin: 0:04

It's been okay. I've been, uh, you know, I've been doing a lot of things and also not very much things at the same, not very many things at the same time. Um, one of the things, so I've been, uh, I had a, uh, tech screen on Friday, which I hadn't actually done one of those in a really long time, where you do like a coder pad and you're with another person and they. You have to like, solve a little, everybody knows what this is, where you have to solve a little algorithm, and, um, you know, it went okay, they're gonna, I'm going to the next stage, so that'll be, that's fun, cause I was, I haven't done it in so long, I was a little scared, I'm like, can I still do these? Like, it's been, like, years, I feel like, since I've had to do one of these, um, but, I don't know, it was, yeah, it was okay, and then, And I'd been thinking I may be confronted with this. So I had been doing some like, uh, HackerRank stuff, some of their puzzles, uh, that week to kind of get myself in the right headspace in case I'm confronted with these. Have you ever, have you ever done any like HackerRank, LeetCode, any of that stuff?

Joel: 1:06

No, I haven't.

Collin: 1:08

Yeah, it's the worst. I, it's basically like present you with a bunch of interview type problems, but they're all really mathy kind of things, and then the thing for me is it's like an interview, but if you couldn't talk to the person who was giving the interview. So, I kind of don't mind these questions as much in the context of an interview because I think part of it is that, you know, they want to see what you know, but I think another part of it is they want to see how you communicate. And the hardest part of those questions for me is always just actually getting out exactly what they want me to do. You know, just like understanding the problem correctly. And when I'm just, you know, presented with like, the HackerRank one is ridiculous, it'll present you with like three paragraphs of like backstory for this puzzle it wants you to do, and then the solution is like four lines of code. So it's really all just about parsing out what, what they actually were trying to tell you. So then you can do it, but it's really simple once you know it. And I don't know, I kind of, I don't know if I'm going to do it anymore. They're kind of killing my, my will to live because it's just all like, It's just like trivia. It's just like, have you seen this before? Do you know what this is? It's not really... I don't really think I'm learning because of it, so maybe I need to do something else.

Joel: 2:29

Right. Is there any, I wonder if there's any evidence that these are actually like good signals when you're interviewing someone? It sounds like complete bullshit to me.

Collin: 2:41

Yeah, I think it mostly is. Um, you know, they have to ask you something. I, I feel like interviews have gotten worse, if anything. Uh, I was, I was tooting about this a lot over the weekend. Um, in that, I think... A few years ago, everybody complained for a long time, being like, interviews are broken, the interview process is terrible, you know, we don't like doing whiteboarding problems, you know. And then I think the response to that has been, maybe it's not a response to that, maybe it's just a different reason and I don't know, but the response to that seems to have been to come up with something even worse. Uh, cause, and, and, and now I to me.

Joel: 3:27

Yeah,

Collin: 3:28

Because like, you can ask them whatever you're going to ask them. You can talk to them. It's like a human interaction where it used to be, I feel like most interviews were like you did a tech screen and you did like four hours where you meet everybody on the team and then you either got the job or you didn't. And that was it. And now it's all, there's a lot of these, like, we would like you to spend seven hours writing a technical document or something and things like this, or we're going to ask you to make this little app for us and it's going to take you six to eight hours. And I'm like, I just feel like the time commitment to do those things and also like the fact that you're doing them by yourself. I, I think I don't like the take home projects. I think I am not a fan of that.

Joel: 4:09

Yeah, take home projects are... I think that they can be a good way for like, to give someone an opportunity to show what they can do if they don't have anything they can point you to. Like, they don't have much of a portfolio or um, experience or all of the stuff that they've done maybe has been behind non disclosure agreements and they can't really share it. And I guess, like, as a company that's hiring, you do need to have some way of, like, filtering out a bunch of applicants, um, like, to try to find, like, who, who can actually code, like, who's actually able to write some code for this position. Um, and so maybe, like, I think it's good to give people an opportunity to do something, but they, I think that that needs to be very, very small. And then, and then you can work with those people that pass that, and then, like, actually spend time pairing with them. Um, it's, like, to make you do an eight hour project, I think is, is quite a lot.

Collin: 5:15

Yeah, it's a big ask. If it's like less than an hour, I think that's fine. I actually don't care then. Um, but if it's less than an hour, we could also do a phone call and we could just like do what I did with this guy, which is also pretty effective. I think people are afraid of making mistakes or whatever, and I understand that. I also think that, I think that the two places I worked that had the, like, best engineers I ever worked with, um, the process was basically just, they brought you in for an onsite, and then you found out at the day if you got the job, everybody met, and then they told you. Um, And those were like pretty big companies. I don't know why I'm hiding it. It's like I'm talking about Apple and Sonos. Like, those were the two companies that worked where like, I felt like they had some really high level engineers there. And I guess if I thought that... I guess I don't understand why if it was good enough for them, why all these other companies need something much more baroque. I guess I don't feel like the results are any better, because I've worked at companies where they do bigger and lesser processes and have it go on longer, and I don't feel like the result is any different. So if the result's not different, I don't know why we're making people put in, like, 30 hours of work to, like, do take home projects so they can work at your startup. That's kind of how I see it. If it was, like, provably better results, maybe that would be a different discussion. But anyway, I think the point here is I'm, I think I'm done with the hacker rank stuff. Uh, I did get a, I did get a, um, the Pragmatic Programmers have a book called, uh, Exercises for Programmers, and I did get that. Maybe I'll do that instead, because I think they're a little bit more, you know, it's like instructional, like they're trying to teach you as you go, but it also seemed like maybe it was a little too basic, so I, I don't know. Um, I'm going to try that one too. I'll report back. Uh. What have you been up to? You said you were reading a book that I recommended to you and liking it.

Joel: 7:17

Yeah, so, you recommended Code by, um, Charles Petzold, is that pronounced correctly? Um, and yeah, I've been really enjoying this, actually. I, it's, it's not a Ruby book, but it is about, I guess, how Ruby works behind the scenes, ultimately. It's about how computers work, um, from basic circuitry. And it's just really well written, really accessible. Um, there's a lot of stuff here that I already knew, but Where the gaps between like one concept and another concept were a little fuzzy. And so, um, yeah, it's been, it's been really fun going through it and kind of learning how all of these different pieces connect together. Um, like an example of a gap circuitry. Um, but then how those logic gates do addition, subtraction, um, store memory, like remember things, uh, or, um, you know, oscillate and create clocks, that kind of thing, um, I found it incredibly fascinating. Um, and... It's just, it's so well done. Like, it starts very, very basic. Like, you're communicating to, uh, a friend across the street with, um, Morse code, and kind of, like, builds up from there, um, and it's, yeah, I'm really enjoying it.

Collin: 8:54

Yeah, actually I think it starts even more basic. It starts is that it's like you both have a flashlight and you're like, maybe I could draw the letters in the air. And they're like, well, this doesn't work at all. And they're like, well, I could do so many clicks for however many, what letter it is. And then they're like... Or, basically that you end up coming up to that, like, Morse code simplifies it from that, like, a simple message would go from being, like, hundreds of flashes to, like, a low number of flashes.

Joel: 9:21

26 flashes for the letter Z.

Collin: 9:25

exactly. Yeah. Um.

Joel: 9:29

our American international

Collin: 9:30

Yeah, for our American audience. I really like that I like how it it starts off very simple Like I think somebody who wasn't like a programmer or something could read this book and understand it because it starts off Basically as like, you know first you have a flashlight and I think eventually he gets to like It turns into like a telegram and then he's like you need to send a

Joel: 9:50

So your friend is now next door, right?

Collin: 9:53

yeah, yeah

Joel: 9:54

you can't, you can't, like, flash a message across with a flashlight. It's, you gotta wire up some electrical wires between a light that's in your friend's bedroom and a switch that's in your bedroom.

Collin: 10:08

Yeah, and then eventually it gets to like, well now you want to send a telegram message like, across the country, so now you need a relay to like, relay the message forward or whatever, and then I think that ends up getting into where he starts talking about like, the logic stuff and like, the things you were talking about. it just kind of keeps building up.

Joel: 10:25

Yeah, I love how, I mean, it's just a wonderful lesson on abstraction as well. So, you, you build from basic switches and, um, relays and things. These logic gates... But then what you do is you draw a circle around them and you give that a name, right? You make, you make it a symbol that represents a concept like and, or, not and, not or.

Collin: 10:55

Yeah. You have a collection of these like, logic gates and things,

Joel: 10:59

right, and you use them to compose other ones, and you keep creating packages. And then, um, you build from that, like all of these other components, and you give those names, and then you build from those more components. Uh, and it's, yeah, I mean, abstraction goes all the way down to the zeros and ones. Um, the, the on's and off's that run your computer, and yeah, it's, it's cool. I, I, I can't wait to get to the end, which I, I hope is going to end up with basically, like, high level programming languages. This is, um, how they work.

Collin: 11:34

Yeah, it's pretty wild. You started a flashlight and then 40 or 50 years later, you're like writing a web app in Ruby.

Joel: 11:40

right.

Collin: 11:42

Need to catch up with you because I basically read it to the point you're at now in the first edition and they came out with the second edition and then, um, I was like, I should get that one. So now I need to catch up. I started it over, uh, in case they added a new, you know, a new Easter eggs in the beginning. Um, You were also telling me that you had made, so you've made some progress with, uh, we have big literal news.

Joel: 12:07

Yeah, literally some really big news. Um, yeah, no, so, uh, I've been working for the last few weeks to, uh, kind of, I've been building this library called Literal, um, that does a bunch of different things kind of related to writing Ruby in a more kind of Kotlin flavoured way. It's the best way I can describe it. Um, I've taken some ideas from Kotlin and other, other programming languages that I really like. Um, including just basic, like, functional programming ideas. Uh, and I'm trying to see what, like, a Ruby spin on that would look like. Um, and yeah, so, um... I've been converting a bunch of code from, uh, in the project where I work to, uh, to use this library and that, that project's just finished now. So, um, yeah, that's pretty, pretty exciting. Um, the project itself, the, like, literal is still very, very early. Um, very rough around the edges. API is still changing a lot, um, so I wouldn't recommend anyone necessarily use it, but, um, it's, this is kind of a process that I need to go through to get it to the point where I can say, yeah, this is an API that really works and, um, here's the 1. 0 that you can actually use and expect to be pretty stable for the next few years. Um, yeah, so that's a, that's a pretty major milestone.

Collin: 13:43

Do you feel like you've learned a lot about things that needed to change a little bit, like actually implementing it? Mm hmm.

Joel: 13:48

Yeah, Yeah. I found a bunch of different, um, like, types I hadn't thought I would need, um, that I've had to create, uh, and also just, like, using some of the collection patterns or, like, literal variants has been very much inspired by, uh, real use of that pattern. Um. Yeah, so it's, it's been incredibly, incredibly invaluable to actually, like, use it for real in an application while building it. The other thing I've been working on this week is basically just trying to scale up Sidekiq. So, um, we're currently running Sidekiq on... A bunch of, like, 2x dynos, and we're gonna convert those to Heroku performance L dynos, which means you have basically, um, I think it's like four core, four physical cores, and then with hypervisors it's like eight virtual cores in total so, like, trying to work on the infrastructure to, Deploy, like, multi core, multi process clusters of Sidekiq.

Collin: 14:58

So. Okay, so tell me about that then, like, what does that look like? I don't, I do not know as much about this as you, so like, what have you been learning with this?

Joel: 15:06

Yeah, so Sidekiq, basically, it's multi threaded, but it, it, by default, um, or like with Sidekiq and Sidekiq Pro, uh, it only runs on one process. So it's only going to use one of the CPUs of your machine. So if we were to deploy this on, um, on Heroku performance L dynos, we'd basically be getting essentially an eighth of the power that the machine had to offer us, um, and so there are some, there's a feature in Sidekiq Enterprise that lets you do like multi core stuff. think it's called Sidekiq Swarm, something like that. It's the only feature that we would be interested in using at the moment, so it kind of wasn't really something we wanted to go through the effort of, like, upgrading for. Um, and so I've just been working on, like, basically building a very simple process that can start and manage other processes. Basically, the proc file runs this one process, and then it will start up the eight processes that Sidekiq will run on and it will do, like, periodic health checks to make sure that the processes haven't died, or become zombie, or they're not using too much memory, too little memory, that kind of thing, and then it kind of handles, um, trying to shut them down gracefully, killing them if they've completely crashed and won't shut down gracefully. Uh, and then, ultimately restarting them, like replacing them with new processes. So I looked into a few different ways of... Doing this, um, and there are a few libraries.

Collin: 16:49

Just for having, like, multiple Sidekiq processes

Joel: 16:52

not specifically Sidekiq, but like multiple processes, um, but that gem was like really, seemed to be really poorly maintained. Um, as in, like, hadn't been updated in, like, six, seven years.

Collin: 17:05

Right, yeah. Mm

Joel: 17:06

and I've no idea what's going on behind the scenes. Wouldn't really know how to debug it if it went wrong. So I spent some time kind of just digging into solving this problem myself, because in the one sense, you want to offload a lot of complexity to libraries that other people are maintaining, but in another sense, if you are only going to use like a tiny bit of some library, and instead you can just have like, I don't know, 60 lines of code that do that thing, that you know inside out because you've written it from scratch, I think that can be really beneficial, um, and so I've been digging into, like, trying to figure, I've never really worked with process before in Ruby, the process module, learning how that works, learning how to, read how much memory a process is taking, um, that kind of thing. Learning about zombie processes, which is pretty cool.

Collin: 18:03

So it's a little lower level than you normally would be operating at then, but still in Ruby.

Joel: 18:08

Yeah, it's still in Ruby, and it's not even that low level, it's like, it's just, there's just a simple API for this stuff. I like the idea of killing zombies though, which is fun.

Collin: 18:22

That's fun. Um, well that's all very exciting. I've been doing some C programming. Um, because we, you and I talked about, uh, you and I, I was showing you some stuff in C, which was fun, because you're like, how do you do the namespaces? I'm like, there aren't namespaces. And you were

Joel: 18:41

it was so insane. You, honestly, you should write

Collin: 18:42

And you're like, what's a, you're like, what's a header file? I'm like, well, it's like this other file that, where you declare the functions.

Joel: 18:50

what we talked about into a blog post, because... You spent like 5 minutes explaining a few things to me, and C makes so much more sense now. Like, understanding what a header file does, like, it's actually really basic, and now I'm not intimidated when I see the headers in a C file. I'm not like, why is there this h thing? What's the difference between h and c? Um, or like... Uh, you're explaining pointers and what it means when you put a star behind something or an ampersand behind something.

Collin: 19:25

Yeah, pointers are definitely something that confuses people. And, um, and it is, I think a lot of it just has to do with that the syntax is a little weird.

Joel: 19:33

yeah.

Collin: 19:34

Because you use the star to both declare it, but also to dereference it. Which is to say, give me the thing that this is pointing to.

Joel: 19:42

Mhm,

Collin: 19:43

And so, it, it's a little bit confusing if you're not familiar with that. Um, yeah, maybe I will write a blog post about it. I kind of had the idea that... I, I don't know, I kind of want to write like a little command line utility or something using C just to like, show that I can, because I thought it'd just be a fun thing to do. Um, but I think the hardest part there is that I'm not like you, I don't just, it's not immediately clear, I can't, uh, you, you seem to not have a lot of trouble like inventing, uh, ideas for how you should, you know, do something like that, um, where I'm just like, I don't know what that would actually be, so, I'm trying to think of something that's like. Big enough, but also small enough, like, you know, smaller than creating a programming language. Uh, cause that's like a pretty big task and I probably won't finish it. Uh, but bigger than, you know, bigger than something that can be done in like a couple of files. Something that really like, shows some architecture and like things in it. So, I don't know, um. If you have any ideas, maybe we'll talk about that offline, but I, uh, I'm trying to think of just little, I don't know, little projects for myself that'd be fun. Um, I think the hardest part in C for me is that you know, the standard library doesn't give you a lot. So, um, there's a lot of kinds of things that... I don't know, just immediately become very difficult to do. And then I, I kind of lose interest and use a different language for it. But for things that are kind of doing like byte manipulation type stuff, it's pretty fun.

Joel: 21:15

mhm, yeah, yeah.

Collin: 21:16

if, if you're building something that is sort of like a Unix tool, you know? Where it's like, it gets standard in, and then it does something to it, and then it like writes it to a file or to standard out. That is, um, that, that is actually pretty fun to do in C, because that is sort of what it was, one of the things it was made for, I think. Yeah.

Joel: 21:41

There's just this global, it's like, it's like if you're using Ruby and you don't have any modules and you don't have any classes, you just have methods and variables. Is that, is that a fair description?

Collin: 21:53

That's exactly what it's like, yeah. There's just a global namespace.

Joel: 21:57

So I think, I think for someone like me coming from a background of writing Ruby, that's what you need to be told when you're learning C. Like, the C books seem to like, when I've, whenever I've read a book on C. I'm kind of going through one now. It seems to be, like, approaching it from this place of, like, oh, you're someone who has a computer science degree and needs to know all the details of C, as opposed to you're someone who's been programming for a really, really long time in a really high level language that's incredible and amazing, and now you need to unlearn all of these. wonderful little shortcuts and abstractions that you're used to using. And I feel like you could just do that in a very simple blog post. Like, see for Rubyists, imagine you're first of all, all the code you're writing needs to be as if you were writing Ruby, but where you just had methods and variables. Like, think about that. You have no namespaces at all.

Collin: 23:02

Yeah. Oh, and like data types are very different because you have like structs, but you don't have like classes or anything. Yeah. It's um, yeah, it's interesting. That makes sense to me that if you were coming from a language where you knew all of those things that going down, if they didn't explain to you that like this explicitly doesn't have it, it might be a little confusing. Interesting. Because... But that they wouldn't have written it that way. Cause if you were coming to C and you hadn't seen those things before, like namespaces and things are actually, it's actually like a more advanced concept. So like, it's just a more advanced concept that like C doesn't really have. I never actually programmed in a language that had namespaces until Swift came out.

Joel: 23:44

Right. Mm

Collin: 23:45

So, uh, so back in the objective C days, if we wanted to. Um, namespace something, we just gave it like a three, a two or three letter acronym at the beginning of the name of the class. So if I was making like, you know, uh, Collins, whatever, I'd just call it like CD something something, you know, CDFoo or whatever. And that's how we did namespaces. Mm

Joel: 24:10

it's like, you need to give me permission to write the bad code, in quotes. Like, if I'm thinking, like, this is what I want to do, and obviously I need to make a class, and like, have a namespace for this thing. And then, like, and then I'm, I'm thinking, looking at the C book, I'm like, how do I even create a class? This is insane, I don't know how to do that. But if you give me permission to just do it using a bunch of global methods and passing around basic data structures, like, I'm, like, that's what I needed to know, I think, to be comfortable using C. And I wonder if this is why I've really struggled with... Uh, learning things like Rust as well, because Rust is kind of, all the Rust books are written for C programmers,

Collin: 24:56

hmm, mm

Joel: 24:57

and so they're not really trying to unlearn you things either.

Collin: 25:01

yeah, that, that makes a lot of sense if you come from a language that is. Yeah, I've never thought about it, because I never went that direction, I only went the other direction. And so, like, for me it's been, I learned C and Objective C and Swift and then Ruby and whatever and Python, you know, these are languages. And so I've only ever been adding, I've never been subtracting. And so that's very different. All right, so I'm going to write that blog post this week. Um, I think the way to do it, so here's how I'm going to do it. I'm just going to make it like a series of very short posts and each one will like contain a little thing. So maybe the first thing will just be like, how do you get standard in? What does that look like? What is a header file? Like what is just basic stuff like you just talked about? And then maybe I can build it up to like a real app or something over time.

Joel: 25:49

Yeah, that sounds great.

Collin: 25:51

podcast.

Joel: 25:59

Awesome.

Collin: 26:00

Well, if you like the show, uh, and, uh, and we sure hope you do, uh, please support us by telling all your friends and, you know, telling iTunes and telling your friends, friends, et cetera. And, uh, we will see you next week.