(Anchor.fm link)

Most developers don't write, and most don't need much theory. Universities don't want to teach you to shovel. The very best heads-down developer in the world is still one you've never heard of. Having a balance of seniority on a team makes a better team. Writing is important: a good StackOverflow answer can save a lot of minutes.

Links We Mention

• CodeWithHugo
• Hugo Di Francesco’s Twitter
• RCS version control system
• CVS version control system
• Network File System (NFS)
• Andrew File System
• Training in the Mountains in Wooden Sandals
• Reg Braithwaite
• Greater Than Code Podcast
• Storytime with Managers Podcast
• De Morgan’s Laws
• Truth Tables
• Loop invariants
• Tail recursion
• SML/NJ
• Miranda Programming Language
• Allspaw’s essay on how to be a senior engineer
• Alan Kay
• Sandi Metz
• Jest JS Test Runner
• The Future of PHP: Is It a Dead Programming Language?

Transcript

Noah Gibbs: Hello, this is Noah Gibbs on Computer Science: Just the Useful Bits. I am here today with Hugo Di Francesco from London, and we’re gonna talk about that thing we talk about: what parts of computer science are useful to him, useless to him or superpowers. Hugo, great to have you here today.

Hugo Di Francesco: Hi.

Noah Gibbs: So tell me a little bit about how you learned to, you know, do this thing we do. How you learned to write code for a living,

Hugo Di Francesco: I guess I don’t have the usual story of starting really young, but I guess I was always kind of interested. So I guess my first memory of doing something close to programming was programming things like dialogues in RPG Maker. So it’s like a game maker. But that that though, like, if this is the answer, if you put in this amount, then the reply will be that. That’s probably the first, yeah, actual bit of programming. I guess I did. I’d always tried to get into it when I was younger. The same as a lot of people, I guess, playing video games, I was like, how hard is it to do that and never really managed to get it off the ground. Really, I dabbled a bit and tried to even set up Java, Pascal, those kinds of languages. But obviously, as someone quite young, you’re kind of like, it allows me to do maths, kind of. So you might not be that interested. And it’s a it’s a big gap between that and making games and doing anything like that. So that’s kind of how it started. And then I didn’t actually write, like, real code until I got to university. So I went to University College London. And yeah, they had a decent program, I guess we’ll get more into it as the episode goes on. But every year, they give you a practical project. So yeah, by the end of my first year, I was very comfortable. And then that allowed me to get my first internship. And then from then on, it was a lot of learning on the job. I guess this this goes back to the whole point of this podcast, which is I learned a lot at university, but I learned a lot by just being more immersed in industry quite early on.

Noah Gibbs: Yeah, absolutely. I mean, learning on the job is clearly a major way that software developers learn. And at the same time, you know, some folks claim that the university beforehand helps a lot, and basically makes that a lot more productive. And other folks, claim it doesn’t at all. So a couple of things we talked about that you might be interested in talking about on the podcast, we talked about source control, we talked about basic data structures. Now the source control thing was interesting to me, partly because I’m used to boot camps teaching that, but my university didn’t. And a lot of other folks, you know, told me that their university didn’t. So you learned, you learned source control in uni?

Hugo Di Francesco: Yes. So there’s two sides to it, I guess. So there’s the whole we had a bunch of practical projects. And the moment you’re working on a team, some people try to do it in Google Drive, or Dropbox or something like that. And very quickly, it kind of devolves into a mess, right? So yeah, even within the first couple of months, they paired us up and they suggested we should use it. So they didn’t particularly teach it and then later, obviously, with with lots of group projects, people got reasonably good at it. And most projects, you were using it. But that’s kind of, yeah, they expect you to learn in your own time, and they push you towards… Oh, you should probably look at this. But they didn’t actually hold your hand or anything. Towards the middle of the degree, I took an optional module, which was about tooling in general, more than just source control. And obviously, a big chunk of it is source control. And it was quite interesting in that, again, it didn’t actually teach you how to use it, it was just like, this is how it’s built. This is how it works, right? I feel like a lot of university teaching is like that, where they, yeah, they dig down into how it works, rather than how you would use it. And so I guess that is also, I understand the point of a lot of people saying, oh, it doesn’t actually teach you how to do the thing, right? It teaches you all this other stuff that is maybe useful, but it’s kind of like, understanding how Git works, probably means you know what those error messages mean, but it doesn’t mean that you kind of you’re a good expert in terms of using it at the command line and solving conflicts and all that stuff. Like you might understand how I mean, I guess you understand the big concepts, right? So you’ll understand the difference between a two way merge those kinds of like, I guess the the key words, if that makes sense. So in a way, I think a lot of the teaching is like, you see all those keywords, so you know that they exist. And you know, it kind of takes that fear away of like, you’re not lost, you’re kind of, you’ve seen this before, even though you might have looked at it from potentially the other side of it from like, how you implement get rather than how do I actually fix this merge conflict, right?

Noah Gibbs: Yeah, well, Git actually is a great example of something that can use a fair bit of theory before you you wait too deep into it. So that sounds really useful to me. I’ll say the contrast with my university experience there is not even as much about the source control, although I certainly never took a developer tools class, as it sounds like you had a lot, a lot more group projects than I did. Often we got along without doing that kind of thing just because there were so few group projects. And so often you weren’t coordinating with anybody and if you’re doing it all by yourself, I mean, if you happen to know source control that can be useful, but it’s not necessarily such a big deal that you’d go out and learn it if you didn’t already know it.

Hugo Di Francesco: Yeah, so that was a big thing. I think it was everything from like pair work, right? Where you could probably get away without, but very quickly, when you’re actively collaborating on the same piece of code, you realize that it’s just easier to do it with source control. And then yeah, every year, there was one or two kind of couple month projects, right? So in the long running projects, yeah, you’re gonna end up with different people working on different things, but also people working on the same thing. And GitHub just yeah, very naturally became the go to. The great thing about the group projects, I guess, is that there might have been a kind of skills difference between different people, right, but like that there was never any kind of conflict about whether it was a good idea to use source control. So that was a win in the bag I think, I don’t think anyone ever really argued that it’s about… Some people might have been like, I’m not necessarily the best. So I might need a hand, but it was very collaborative. And I think that’s a that’s a big university thing, right, is you actually end up learning quite a lot from your peers, possibly more than you get from all the lectures and standardized exams that you take, right?

Noah Gibbs: Often? Well, that’s interesting to me, because so I’m an old guy, when I went to university source control meant RCS and CVS, both of which are far worse than, than what you’re used to, I don’t actually recommend you go back and learn them. There’s not the slightest reason to. But they definitely gave a lot less benefit than good modern source control does. And so you did hear a lot more people, students and otherwise, who just argued against source control and thought it was a bad idea, which when you’re using RCS to me is more understandable. It really was not good.

Hugo Di Francesco: Yeah. The interesting bit is that, yeah, I came along, and cloud was already a thing, right? So everyone knows, like, anyone doing a computer science degree, when I was doing one would be fine, like Google Drive, Dropbox. And then so going from there to GitHub is not a massive stretch, right? It’s just like, Okay, so this is basically that just a bit better for source, right? So we’re kind of like, okay, that’s great, like, perfect, it allows us to collaborate. So I think it’s not necessarily even just the tools themselves. It’s actually the in a way, the cloud infrastructure that has helped quite a lot, right?

Noah Gibbs: Yeah. And that was weird. I went to Carnegie Mellon. And so we had a shared file system that all of the the machines on campus used. And so weirdly, we did kind of have cloud storage, it was just more like NFS, if you’ve ever used NFS, than it was like, say Dropbox. AFS, the Andrew File System.

Hugo Di Francesco: Yeah. I mean, so it came pretty naturally. And that kind of goes back to my experience with did my CS degree, prepare me well. And yeah, it’s still like a lot of the top line items like knowing about, I don’t know, functional programming, even though the language they taught us is like totally academic and completely useless, right? Knowing about like, type systems, and how to build the compiler and all this stuff, right? A lot of the time, you don’t use it, but that one time where you do, it helps quite a lot. And even if you never, I think it just, it almost becomes like a culture thing, right? Like when people make a joke about compilers, your kind of like, you can do a follow up joke, right? So I don’t know that that’s a great thing or a bad thing. But it’s almost like a cultural thing. That, yeah, you have a base in a lot of concepts, right? So it gives you a bit of breadth. And it also makes it a lot less scary, right? Because yeah, I don’t know, learning JavaScript or HTML, or, I don’t know, React right? After they forced you to write research papers about clock synchronization or something. It’s like reading documentation is a lot less daunting, right? Even if it’s a horrible like, Java doc or something with like, thousands of classes, you’re probably like, at least I could search this right.

Noah Gibbs: So you’re basically saying that reading and writing in academic language is excellent preparation for these things because it’s so much harder than anything, a real job would involve that it doesn’t matter that it’s useless. You’ve still got to practice in something harder. So it’s sort of training in the mountains, like, like running wearing wooden sandals?

Hugo Di Francesco: Yeah, it’s the opposite of training wheels. It’s like, here you go, you’re in your F1 car, and then you just, you learn to drive in your F1 car, and you can then just drive your average to that. Right.

Noah Gibbs: Okay. You know, I don’t I don’t think I’ve heard anybody put forward that that perspective yet. So well done. You’ve you’ve, you’ve surprised me a bit. I appreciate it.

Hugo Di Francesco: Yeah, well, I don’t know. Yeah, I still don’t know that that’s necessarily a good thing, right? Because it does push a lot of people away because it is scarier than it needs to be, right?

Noah Gibbs: Many of the things you said didn’t sound like you were saying there were good things. I mean, when you talk about it as a cultural match, I didn’t get the impression you were saying “and we should,” in fact, you you kind of said the opposite. I got the impression you were saying people do use this as a culture match. And it’s terrible that there’s all this sort of gatekeeping and I wish they wouldn’t… Also if they’re going to do this sort of arbitrary silly gatekeeping you can at least make sure you’re on the right side of the gate. Is that roughly what you were saying?

Hugo Di Francesco: Yeah, I mean, it’s at the same time I kind of understand why it hobbles along and kind of works as it does, right? First of all, the Universities take ages to adapt, then you’ve got the kind of, I guess, it’s a, yeah, like, like you were saying, gatekeeping, right? People take their experiences. And it’s, I wouldn’t say traumatizing, but I guess it could be for some people. And then you’ve got those experiences of like, yeah, you’re dumped into a research paper or on some, like, compiler project that you’re like, I don’t know where where to start and where to finish. And then they expect everybody else to be like that, right? And that doesn’t really transfer that well to the real world if that makes sense. Like a really diverse team and career changes and people from, I guess it’s called non-traditional backgrounds now, or…

Noah Gibbs: That’s often what what we say, non traditional backgrounds often means anything other than… Got into university at around 18, did a four to six year program, then immediately went into full time computer science employment and continued that for the duration of your career, possibly with the occasional vacation, and then stop. That seems to be the traditional background, when we use the phrase non-traditional backgrounds, either that or we’re talking about it being white or Asian men. Fair enough. That is the vast majority of people who do what we do.

Hugo Di Francesco: For me, it worked. But then I don’t know that it was all necessary. Right? That’s the other thing.

Noah Gibbs: Sure, there’s a wonderful thing that Reg Braithwaite, a wonderful grumpy old man who talks about programming stuff, there’s a wonderful thing he points out that it used to be… He’s older than I am. So he points out how things you know, we’re at about that timeframe. It used to be that to apply for a job, it was assumed that you would include a handwriting sample. You needed to be able to do good handwriting, possibly with a fountain pen, depending on exactly when you were talking about. And it was was treated as a black mark against you if you couldn’t produce good handwriting. And it’s not that he’s against good handwriting. In fact, he actually says he’s good at handwriting. And so that that worked in his favor, but it’s still the same kind of silly gatekeeping. You know, it’s applying an extra thing, like you say, a thing that doesn’t need to be there. I’m really lucky that they don’t require good handwriting with a fountain pen at this point. I’m hopeless at it.

Hugo Di Francesco: Yeah, it doesn’t help that all these platforms to kind of filter applicants and all that crop up as well. Right? So it’s like, oh, you don’t have a CS degree? Like there’s a comic strip, right? where it’s like, oh, let’s just get rid of half the CVS because we don’t work with unlucky people. Right? It’s just like, Yeah, okay. So I mean, on the on the flip side of it, right, a bunch of people in my course, in my year, or the couple years around, that came out having done very little code, right, because you can, it’s like if looking like you’re studying concepts, and you need to learn how to apply the algorithm by hand, right? I don’t I don’t know that many people that necessarily do that every day, right? It’s useful to be able to write it out by hand when you need to write so it’ll be like, once a month, or if you’re working on really hard problems once a week, or whatever. But yeah, I mean, there’s, there’s a lot of, I feel like there’s a lot of jobs out there where you could just, I don’t know, a lot of agency work, where it’s like, put up this marketing website, I don’t know how much computer science, you really need to do that, right? It’s like, it’s probably more useful to know how to wrangle WordPress, or write good HTML and CSS or set up a server. Right. And that kind of skill set rather than I know how to do all these things with trees and all that.

Noah Gibbs: I certainly think that’s fair. Universities are interesting, because in my experience, and again, it may be different from your university, I don’t know, they’re often aggressively uninterested in that kind of thing. There was a fellow who explained the structure of Carnegie Mellon’s older computer science degree, and how they used to require something other than computer science to be taken in, in concert with it, you had to have another major or another minor, something besides computers, because computers were considered tools. And while you might get a civil engineering degree, you wouldn’t get a degree in shoveling. And in the same way, they didn’t just give you a degree in computers. But you could add it on if you also got a degree in something worthwhile.

Hugo Di Francesco: Yeah, I guess that’s where computer science versus software engineering comes, right? It’s kind of like if you’re looking to the academic path to… In computer science ends up being a lot of even if you want to do the hard stuff, so that the computer science stuff, you end up somewhere in maths, right? Or logic, things like that, proving things. Or you end up applying it to another field, right? So it’ll be things like, you come out with a computer science degree or master’s degree, and then you go do machine learning for medical imaging or things like that, right? So from both ends, I guess you can see it, but it’s kind of it’s not quite the same direction that everyone who wants to go code for a living or write software for a living needs to go through, right, because it’s kind of… It’s related and it’s mostly useful, but it’s kind of like if you think of university trying to set you up for an academic career, then it’s kind of like, well, really what they’re gearing you towards is either maths or applied concepts to another field, right. And that that second part obviously applies to software engineering, but it’s there’s a lot of things that you need to do to not go academic with that, right? So all the academic skills kind of don’t really help you that much if you’re not going to end up in academia.

Noah Gibbs: Yeah, occasionally you’ll come across a program that sort of thinks it’s a trade school, like one of those little schools that trains you to be a phlebotomist or, you know, other immediately applicable-to-a-job skills. But yeah, you don’t see very many universities that want to do that with computer science. I know Carnegie Mellon prided itself on how well it prepared people for jobs in general. And it was still awfully academic compared to a modern boot camp. I would say a modern boot camp is probably a lot closer to the idea of a trade school.

Hugo Di Francesco: Yeah, well, so I think UCL was was very similar. But the big thing they did was just give you semi industrial projects, right? It’s kind of… They try to bring stakeholders either from other parts of the university or even outside the school to be your stakeholders for project. So that gives you kind of almost freelancer type experience, which is good and that they had a bunch of courses around project management. I think, one time they even had like an ethics and law-ish type, of course, which had essay writing. And a lot of people were very unhappy with that. Because apparently, people who go into computer science, it’s because they don’t like writing essays.

Noah Gibbs: Yeah, Carnegie Mellon was big on writing. A lot of, a lot of folks, us and the artists both had to do a lot of writing. And we all grumbled about it. No, that makes sense. Although having you do a law and ethics class seems kind of, kind of prescient, given some of the modern problems we’re seeing in the computer field.

Hugo Di Francesco: I think that that point you made about Carnegie Mellon priding itself on preparing you for work, I think you still are in the same kind of spot, but they’re still not close enough, if that makes sense, right? It’s still got a lot of kind of baggage of this is how in general University teaching is, and this is how we teach computer science. And I mean, a lot of the… Even your guest lecturers, that are supposed to be industry experts, they’ve spent 40 years in the field. And a lot of the time, that means that the past, I don’t know, 15 to 20 years, at the very least, they’ll not have been in the trenches coding anymore, right? Like, you don’t necessarily see someone who’s just kind of coasting along as a developer, ending up in a classroom setting at a university with a with a guest lecturer spot, right? So there, there’s also that representation side of it, which is like people who do most of the work, probably don’t look a lot like the people you see out there representing developers, if that makes sense. So maybe something we were saying before we started recording, which is on a lot of podcasts, it’s a lot of the developer relations, kind of famous developers in inverted commas maybe? And in a way that kind of doesn’t, isn’t everybody’s experience, right? Like, not everybody gets to do writing for most of the day, right? Not everybody is writing demos for a living or teaching for a living within a company. Right? Yeah, it’s it’s just interesting to see how it kind of pans out where I don’t know what people’s expectations are. But from kind of the developer media side of things, right? It looks a lot like to be successful you have to write and you have to do this and that the other, you basically need to end up in Developer Advocacy.

Noah Gibbs: Yeah, I don’t know who the very best developer in the world that just putting their head down and getting the job done is but I know, I know, I will never have heard of them.

Hugo Di Francesco: Yeah, that one’s an interesting one. I think because it’s very much the core and the heart of a lot of things we need to look at, right? It’s like, I’m sure a lot of developers doing a lot of interesting work, probably won’t even share it, because they don’t think it’s interesting to anybody else. Because to them, it might just be that day today. Right? But in fact, if everybody started sharing all of that, you’d have so much more knowledge and a much better picture of what day to day programming looks like.

Noah Gibbs: Potentially, yeah. It’s weird, because on the far extremely skilled end, I would maintain that programming is a lot like writing. And it’s odd that so much writing is done where the intended consumer is someone else in the same organization. People who have been in the army are laughing at me right now. But still most industries don’t work that way.

Hugo Di Francesco: Yeah, yeah. I think it’s it’s also the growth of it. Right. And it probably all links back to that that constant developer shortage that is always around despite the the kind of hundreds of or thousands of cohorts of bootcamp graduates that can’t seem to get jobs and being able to break into… It’s interesting.

Noah Gibbs: Yeah, I don’t know. I feel very mixed about the way we treat junior developers as a, as an industry. Obviously, we’re not particularly good about how we treat junior developers and mostly we we try to give them some chance to become senior developers, at which point the treatment will get better… Which is itself a whole set of problems, but it’s hard for everybody, I think, that a good engineer is expected to have enormous perception and initiative almost like being an executive, to look at how the company works, and then change how the company works. And a junior engineer, especially if they can do that successfully and well are going to immediately clash with the company and get thrown out.

Hugo Di Francesco: Yeah, it’s interesting how the expectations shift, I think. And again, it’s the five year mark of in your career, right? And all of a sudden, it’s like, okay, you’re not allowed to be a junior anymore? Well, you shouldn’t be anymore, because then maybe this isn’t for you, right? Which is kind of like, well, not everybody needs to be the number one person, right? Like, by definition, probably, you can’t be right, there can only be a single number one, whether that’s an executive, or in terms of just a small scale inside the team, right? If you’ve got too many cooks, that actually wouldn’t flare up if you just have either someone designated as the lead or just naturally ending up in that position within the team, right?

Noah Gibbs: Certainly, yeah. And some of that is about setting team boundaries, you can certainly have more than one person who’s in charge of a team if you’ve got more than one team. But yeah, figuring out how to cut that up is hard.

Hugo Di Francesco: Yeah. And that’s the, the other interesting thing I’ve seen, right? Is having a balance of seniority in a team is actually super useful, because it brings out a lot of the time the best in people, right? So yeah, having a team of very senior people that all want to put their stamp on things is going to be a problem because people start pulling different directions, right? One of them wants to go with a particular kind of whatever interests them at that point. So it might be some type of database, and then the other ones like, Oh, we need to use this pattern everywhere. And very quickly, it starts clashing, right, versus if you’ve got kind of more junior developers, and then mid level developers and more senior ones, you end up with a lot more collaborative environment, right? Where, where people are more willing and able to ask and answer questions, right. And it’s, it makes the whole team gel better as a team rather than you’ve got, I don’t know, hundred years of experience between three people, but they, they still can’t can’t seem to be able to deliver a simple like one page app within a given time, right?

Noah Gibbs: Yeah, it’s interesting, because I feel like that’s a whole other enormously deep topic, which would be a completely different podcast. And mostly that podcast would be Greater Than Code. No, I mean, that’s, that’s like that’s the name of the podcast. Or Storytime with Managers. There’s another great, similar but different podcast called Storytime with Managers. That is a bit of that same topic. But yeah, it’s I agree that in general, you want to be able to have a good mix of seniority is on the team and how well that works, I would say, has everything to do with how the company works. Like whether you can get three really senior developers on a team to cooperate has an enormous amount to do with how the company treats their contributions, after a success or a failure, you can get something like that to be a good idea. And you can get it to be a very bad idea. And it depends entirely on people who are not developers and how they act after the project is delivered.

Hugo Di Francesco: Yeah, there’s also the personalities, right? And I think it’s it’s good as well, that there’s a different kind of types of companies out there, right? So you’ve got your agencies, you’ve got your bigger companies, you’ve got your big tech companies, you’ve got your smaller tech companies, startups and the like. And then you’ve got freelancers, contractors, you’ve got kind of, it’s an interesting industry, because you’ve got everything under the sun, right? And so saying, but but if we go back to CS, right, it’s like, assuming that you can teach people everything they’ll need to know for all these different directions they could go in is kind of crazy, right? It’s So I think in a way, the good thing about computer science degrees is that they don’t try to do that. Just like, if you were to go down an academic track, this is probably the types of things that you would need to know, right? And maybe it’s applicable to some other jobs, but not necessarily. And they get… At least in my experience, they tried to give you a bit of breadth as well. So it’s kind of okay, so there’s all this computer science stuff. But then obviously, we’re aware, there’s soft skills and management and all that stuff involved as well, right? So it’s kind of trying to give you a balance, obviously leaning more heavily to all that theory stuff that they love to give you. So that they’ll they’ll quiz you on, I don’t know, logic, right? Which I mean, if you’re very well versed in logic, it does help with all those finicky Boolean, like, expressions that you’re making, right? Knowing that you can just swap around ORs for ANDs and all that stuff by just negating in the right spot. That is actually applicable, right? But then a lot of other stuff like proving stuff, maybe not. And then you’ve got things like, I don’t know, Truth Tables. If one day you’re in a situation where you need something like that, it’s really, really great to know that you’ve got that in the locker right? But then there are very few days where you tend to need to do that. So it’s balancing that I guess it’s things that are immediately useful all the time. And then things that are tangentially useful a lot less of the time. And then you’ve also got things that are very useful, but even like few of occurrences in your whole career, right?

Noah Gibbs: So what’s what’s a good example of something that they taught you in university that you find pretty useful pretty often?

Hugo Di Francesco: I guess the fact that they stuck us in a functional programming course quite early on, that’s really stuck with me. So they today I work with JavaScript, right. And it’s interesting how understanding recursion in particular, right like, so because in a functional programming language, you don’t have loops, all of a sudden, you’re having to use all these other concepts and patterns. And a lot of it is recursion. And the other big one is things like pattern matching, but they usually go hand in hand, right? Yeah, I found that actually, recursion is great for interviews. Because a lot of the toy projects that they give you in an interview, it’s a lot easier to make it work, if that makes sense. Like if you’re doing it on the whiteboard, conceptually, recursion, because you don’t have this off by one issue, or like, all the loop stuff, right? You have to keep in your head every single step of the iteration. Yeah, recursion has been an amazing crutch for interviews, because you can just be like, so we do this. And then this is how we end up in so you’re only holding two or three steps at a time for iteration.

Noah Gibbs: Yeah, no, absolutely. I guess what I’d say about that, and you can agree or disagree, is that you can absolutely do those same things with iteration by figuring out what the loop invariant is. But that’s kind of counterintuitive. It’s hard to keep in your mind. Whereas thinking, what does the method return when I give it these parameters is just easier to hold in your hand. It’s, it’s, it’s easier to think about what that means… For me, anyway.

Hugo Di Francesco: Yeah. And I mean, the interesting bit is, yeah, when you use recursion in an interview, and the interviewer and you kind of knows what they’re doing, or they’re trying to see how far you’ve got in terms of computer science, the next thing they ask you is, what’s the space and time complexity of this? And then you’re like, well, now I need to rework it into a loop, because it’s probably way more efficient today that way, right?

Noah Gibbs: Well, luckily, if you’re there just having you write pseudocode, you can always wave your hands and say, well, they’ll handle this with tail recursion.

Hugo Di Francesco: Yeah, yeah, yeah, yeah.

Noah Gibbs: Then you’ve got to make sure that the recursive call is the last thing in the function. But if you do, say, well, it’ll be handled by tail recursion.

Hugo Di Francesco: Yeah, the compiler will deal with it. That’s, that’s always a great answer. But yeah, yeah. So the concept again, right, it’s thinking in those terms helps a lot. It’s just, I think the other thing functional programming is about is breaking it down into kind of single step operations. Right? So recursion is all about that. It’s like, you’ve got your your kind of terminating case, and then you’ve got your recursive case. And sometimes you’ve got more than that. But I mean, that’s the kind of idea right? And yeah, breaking it down into, like, Where do I want to end up? And where am I and how do I get there? Right? That’s quite useful. And then, like, he was saying, it’s, it’s easy to keep in your head, a recursive case. And coming from there, I think it does help a lot to kind of, like, I’ve got this big thing I’m trying to do right here, or like the the mid level steps that I need to do. And then here are like, the nitty gritty details of like, I’m actually going to fetch from this database and this, like service and whatever else, right, but being able to go from like, big picture down to small picture and then back up again, right?

Noah Gibbs: Yeah.

Hugo Di Francesco: In a weird way, I feel like being kind of thrown headfirst into the deep end, in functional programming helped quite a lot, because that’s how you start seeing everything, right? And in a way, I feel like coming into university hadn’t having not coded that much beforehand. That in a really weird way helped me a lot with that, because it wasn’t that I had any bad habits or any knowledge to kind of adapt and unlearn. And all that stuff.

Noah Gibbs: I would say that sounds a lot like what you said about academic writing and white papers. So I would argue, and you’ll get all sorts of arguments about this. But I would argue that functional programming, and especially the kind of functional programming they like in university does make you think out your concepts a lot more thoroughly. It is just harder to get it to the point where it works. And then once you’ve thought it all through, then your program actually works. Again, it’s kind of a training in the mountains thing. If you can do that, then doing the same thing with a language as blurry as a standard programming language you’d use day to day is suddenly easy, you know, JavaScript or Ruby or something of that, of that nature.

Hugo Di Francesco: Yeah, again, it feels like… I don’t know that I’d recommend it for anyone else either. It’s kinda like, it’s that like, Is it something up with me that I enjoyed that bit of it. I enjoyed the kind of toughness of it. Maybe just because I, I managed to get through it, right? And it’s kind of like, it has shaped me, but is it really like, would that have been a better way to do it, right? Is still the question in the back of my mind when I say that it’s like… Well, yeah, it’s great. But like, Did you really need to spend, I don’t know, four weeks, six months, with all the stress of those exams and all that stuff, like learning an academic functional programming language? And then I think I even took a second course in functional programming. So that shows you how, how odd it could have been, it’s kind of like, I didn’t get enough the first time, right? They taught us Haskell, but the first time and then I went back for more and even more academic functional programming. So…

Noah Gibbs: So yeah, you mentioned that, yeah, that they taught you a very academic useless in the real world sort of language. And I was going to ask, was it SML/NJ? Was it Standard ML of New Jersey?

Hugo Di Francesco No, no, no. Homebrewed one I think. It was, well, it was Miranda.

Noah Gibbs: I don’t know Miranda. Sounds like I should look that up. Okay.

Hugo Di Francesco: Yeah. I think it must have been because, you know, it’s one of those things where I kind of assumed that the lecturer or someone in the research group, somewhere, at some point must have, it must have been their creation, right? Is that kind of thing where your economics lecturers write the book, and then they make that the textbook for that class, right?

Noah Gibbs: Well, so Miranda apparently dates back to 1985. And was written by a guy named David Turner. Oh, Miranda had a strong influence on the later Haskell programming language. It’s older than Haskell. Wow. Middlesex University England. So okay. Strongly possible, given that he’s also UK that he, yeah, that you’re using it because of that. Good to know. Okay. I did not know Miranda, but you learn something new every day.

Hugo Di Francesco: Yeah, the tooling for that was even worse than Haskell.

Noah Gibbs: Yeah. Well, it doesn’t seem like it was ever a terribly popular programming language. I’ve met a lot more people that have heard of SML/NJ. And when you’re looking at a language that the less popular than SML/NJ, that’s usually a very bad sign. What do you do to improve these days? Do you do any kind of study or practice, classes or anything like at work? Outside of work? Either one?

Hugo Di Francesco: I work right. So that’s, that’s…

Noah Gibbs: That counts.

Hugo Di Francesco: And yeah, I think the longer I’ve, I’ve been working in the industry, the more I kind of try to read in terms of just code. But then also, some books, I’ve never really gotten into reading books. Actually, if I if I’m honest, the way I learn the best is by trying to write books and blog posts and that kind of thing. Because, yeah, it’s one of the only ways I could force myself to sit down and really understand something enough to be able to produce an explanation or a walkthrough or something like that. And then I do a bit of mentoring. But that’s, that can be different things. It can be just some pair programming, some discussion around how you want to structure your project. But obviously, a big part of mentoring is also like, what are your goals? Actually, how are you going to get there, that kind of thing, which is more kind of, yeah, coaching, mentoring, and kind of career trajectory. But a bunch of it is still like, Oh, you forgot a comma here. You’re passing the wrong parameters there. When people get stuck with with things, right?

Noah Gibbs: Yep. I definitely understand learning through teaching and mentoring and writing. That makes a lot of sense to me. But of course, I do a lot of that kind of thing. I’d worry about you being competition, but it sounds like you’re not doing video classes yet. So at least I’ve got that…

Hugo Di Francesco: Yeah, well, I’m more on the on the JavaScript side of things. And it’s interesting, because there’s, like I was saying earlier, I think there’s a lot of people that do a lot of interesting things that don’t write them down, you know? So I remember a couple years back working in a kind of startup that recently got acquired by a much bigger company, but we’re still operating kind of in sort of startup mode. And it was a team of two or three, and we were using Angular, right? So you think most things have been thought out for enterprise, things like localization, all that stuff has been thought out, right. And you think maybe it was a bit too early, I don’t know, what I think is more likely seeing what we ended up doing, which is we solve the problem and got on with our day building the next feature, right, instead of kind of sharing it so that the next hundred developers in the same situation, don’t don’t go and have to, like, figure out how to wire up the localization and all this these other things, right? And I feel like yeah, most of the companies where that would have happened, the developers who don’t feel the need to go and share anything, they’ll just solve the problem move on, right?

Noah Gibbs: I feel like enterprise developers are sometimes justly infamous for that kind of thing. Like it can be a lot harder in a big company to convince them to let you share your solution. Because a lot of the managers don’t necessarily think of that as a competitive advantage. They think of that as telling your, your small handful of competitors, you care about exactly how you do it. And so it’s, sort of, all downside in in a lot of their eyes. I don’t know this is, this is, another one where I’m old enough that it’s possible things have changed completely. And definitely small startups don’t work like that. But much like academic departments move slowly, my experience is that large old enterprise companies move slowly and that kind of thing changes slowly as well.

Hugo Di Francesco: Yeah, I think so. Well, I mean, yeah, there’s there’s also just the I think it goes back to again, one of the things we were saying earlier is like, I think the moment you become competent as a developer, you can go a couple of ways. And a lot of people just take the way of, “I go and solve the problem in front of me, I don’t worry about the bigger ecosystem or anything,” and they just go ahead that way, right? And that that is actually the majority of developers because you need all those apps to be built, right. And so it’s not a bad thing, per se. It’s just, it’s something that I observed. And that’s actually one of the reasons why I started writing a lot more and that kind of thing, because I was like, well, if it happens for this, right? We’ve got hundreds, like, the majority of developers surely are in that, like mid tier range. Anyway, it’s they are senior enough that they know they can work through the problem without a tutorial. But wouldn’t it be nice that someone has kind of got it like 80% there? 100% there, right? for them. And they save, I don’t know, a half day. That’d be nice, wouldn’t it? And it kind of, yeah, across the industry, if you think about it, right? If you got, I don’t know, 1000 100,000 developers every day using a StackOverflow answer and saving five minutes. That’s a lot of minutes saved at the end of the day.

Noah Gibbs: It is. Stack Overflow is nice that way. I feel like blog posts for developers do leave out a huge swath of developers. That’s kind of like what we were talking about with, with university programs. A lot of us didn’t get into this because we wanted to write essays. I mean, I do, but a lot of people don’t.

Hugo Di Francesco: Yeah, but again, it’s barriers to entry. Right? It’s like, it’s an interesting one. I think a lot of it goes back to… If you get into this field, yeah, like you were saying it’s not to write essays, right? But then you get to a point where either you want to end up in a managerial track, or you’re getting to kind of more senior positions where your responsibility is maybe across teams. And then writing becomes surprisingly important, right? Whether it’s creating an RFC, or writing out specs, or even just communicating with people, right? That’s all, more and more that’s becoming written, especially with, yeah, with offices being shut down now and all that stuff. So.

Noah Gibbs: Well, even before that, if you if you are looking at more of a Staff Engineer, or Principal Engineer type role, or certainly anything on the management track, that has always been about communication skills with people, and it’s not always the same communication skills with people depends on the company. Depends what you’re doing, you know, there’s, there’s often a lot of individual leeway. You have to be good at one of this list of skills. But one way or another, the list of skills is a list of skills for communicating with people.

Hugo Di Francesco: Yeah, that’s another one that maybe is not quite in the computer science degree. Yeah, I think that maybe that’s one of the ones where, depending on your computer science degree, you’ll have very, very different focus on it or complete, kind of disregard for it, right? Yeah, I’m guessing most degrees will have some sort of exam, maybe some coursework. But yeah, report writing, analyzing other people’s writing that kind of thing. I don’t know that that always is a kind of core competency that they expect you to have coming out of the CS degree.

Noah Gibbs: Yeah. And while there are degrees with names like Communications, I definitely don’t get the impression that they’re what I immediately think of as the mechanical work of that role. In the same way, to be fair that a computer science degree isn’t all that much like the mechanical work of being a software developer day to day. So, fair enough.

Hugo Di Francesco: I mean, one of the things I’ve seen is actually just the difference between, I guess a mid level engineer and a senior engineer tends to be – okay, now, now I’m getting to like rampant generalization. But the way I see it is that the mid level engineer probably solves the problem eventually. And they work through the issue, right. And they might come up with a couple of solutions. And I think the difference is just it’s an experience thing, right? So we’re in the same situation, the senior straight off the bat will identify this thing as something that they’ve already solved these two or three different ways before. And so instead of having to work through it, it’s kind of like you’ve already got these templates for and maybe mental models for how to solve that. And so that is really experience-based, right? It’s very much, like, if you haven’t seen it before, then you haven’t seen it before. So in an interesting way, actually, the the skills that get you to, basically, out of the junior role, right, which is like you’re able to problem solve, you’re able to fix things on your own, you’re able to get things done pretty much. It gets flipped on its head at the next step, right, which is like, you’ve already seen all these problems. And without even – well, I guess, maybe with a bit of experimentation, but – with less experimentation and less trial and error, you end up with an idea of where you want to head, right? And that I guess that’s why most senior engineers take on more architecture responsibilities and that kind of thing. But that’s always interested me as well as like, how would you even teach that? How would you even begin to teach that?

Noah Gibbs: That’s certainly fair. Teaching somebody to be a good architect is very, very hard before they’re already a good senior engineer. And really, it’s not easy, then. How far along? Are you in your career?

Hugo Di Francesco: Five, six years?

Noah Gibbs: Okay.

Hugo Di Francesco: It’s got a bit of overlap with studying. So it’s, it’s about there, but full time is just a couple of years shorter, I guess.

Noah Gibbs: Okay. There’s a really good essay that I tend to recommend to people who are thinking about being a senior engineer, you may you may well be past it, you may already know everything it has. But on kitchensoap.com, which is John Allspaw’s site, he has a specific essay on being a senior engineer. And if you google kitchen soap senior engineer, it will come up really quickly. And his basic contention is not so much that the senior engineer has a lot more technical experience in terms of how many things they’ve done, although obviously that helps, but that it is much more about how you communicate on it. That is to say, he… According to his essay, and you can, you can decide what you think of it. But according to his essay, I mostly agree, if you put a senior engineer in front of a fully unfamiliar problem, and you put a junior engineer also in front of that fully unfamiliar problem, a lot of the difference in approach will be about communication and about team orientation. And so a senior engineer is going to be a lot more likely when they are approaching the problem, documenting the problem, researching the problem, they’re going to do that in a way that is oriented around the other people. So a junior engineer, if they’re researching the problem, they may, you know, go out and find find a perfectly good solution. And there’s nothing wrong with that. The senior engineer who’s never seen the problem before, you know, in some ways their research is not going to be a lot better. They’ve got a little more practice, but researching by choosing between multiple different possible approaches that you’ve never used before. Being a senior doesn’t give you that much advantage over a junior, except that very often it causes you to document how you did it, write down what your thought process was, keep those documents around. And then if somebody who has solved the problem before happens to wander by they can read through and go, okay, you decided this, this part, you decided for a really good reason. And I should do just exactly how you said it. This other bit, you just looked at a couple of things on the internet, and you decided this sounded like an overall better approach. But I’ve used those approaches. So here I don’t agree with you. It lets somebody else come by and apply their expertise to what you did in a way that the junior engineer research-the-solution write-the-answer approach often doesn’t, I would say. I would argue.

Hugo Di Francesco: Right. So it’s Yeah, it’s about putting down why a lot of the things you’ve decided on, right?

Noah Gibbs: Yeah.

Hugo Di Francesco: Yeah, you’re not so much interested in necessarily the outcome, because, like, I guess we’ve been agreeing on, is about outcome is usually you can get to a solution. There are some really hard problems, but in most situations, you will come to a solution. Right? I guess that’s why I understand that viewpoint in terms of, yeah, the seniors should look at it in terms of how can you make it so that everybody is able to contribute so that the solution is better than what anybody could have come up with on their own, right? So is that that collaboration and showing kind of gaps, or kind of leaving some things open ended? Rather than saying, this is the way we’re doing it?

Noah Gibbs: Yeah. Well, we’re always building sandcastles here. I mean, anytime you’re building a solution, designed for real customers on a team, any solution that you build is going to slowly degrade in ability over time, customer requirements will change, the various services you depend on will change. Other people will write new features that will, will cause bugs with it. One way or another we’re building a sandcastle and we know it’s going to slowly crumble into the sea. But my experience is that… A good engineer with a people orientation will give you a lot more basis for rebuilding and for knowing which bits should be saved and for dealing with that decay gracefully. In a way that somebody who just wants to build their sandcastle as well as possible, maybe isn’t thinking about. It’s, it’s weird. It’s never just the sandcastle, you’d have to sort of get the whole process of it crumbling in your mind, because it’s going to and you should plan for it.

Hugo Di Francesco: Yeah, so that sounds like yeah, frameworks rather than, yeah, you’re more interested in kind of breaking the problem down in pieces that can be changed, right, rather than the solution right now. Because like you’re saying, it’s, the solution right now is not necessarily going to be the solution tomorrow. So making it so that, first of all, you can bring more brainpower to bear on all these different problems is great. And yeah, breaking it down into smaller sets of problems. That’s why I like functional programming, right? So that resonates with me, with like, yeah, if you have tiny chunks, you’re much more likely to end up with something that when you have to swap one out, you don’t have to throw everything you throw away, one bit of the system, maybe two bits of the system, because you’ve got some interfaces that need to change right? But yeah, it’s about how easy is it to change? I think that’s a concept that has been floating around the internet recently and maybe not so recently is a system is only as good as how easy it is to change and evolve, right?

Noah Gibbs: Yeah, that’s definitely an old one. You can find a lot of that in, say… Wow, I’m completely forgetting his name Alan something. He invented Smalltalk. But you can you can find it in a lot of the early writing about Smalltalk and around that, the same guy invented object… The idea of calling it object oriented, and he had a specific thing in mind. But… Alan Kay, Alan Kay, that’s his name. And it’s the same kind of thing. A lot of it is about handling change and handling variety and handling, you know, weird situations. Sandi Metz is another one I usually quote, I don’t know, you’re you’re not as much from the Ruby community as I am. When I say Sandi Metz, do you? Do you know who that is?

Hugo Di Francesco: Yeah, yeah. Well, it’s a, there’s a couple of communities that I keep tabs on just because they they’re nice communities, right. So one of them is, is the Rails community. And obviously, that kind of ties into the Ruby stuff. And then Laravel as well… Kind of it’s nice, nice communities, I feel.

Noah Gibbs: I hear really good things about the Laravel community, I’m only, kind of, right out on the edges. I don’t write a lot of PHP, but you know, I hear wonderful things about them.

Hugo Di Francesco: Yeah. So again, it’s like, I don’t write any PHP. But, I mean, it is very compelling, right. So I guess the core Laravel and Rails philosophies have something similar to them. Which is like not everyone’s building kind of enterprise software, or working for Google and those types of sized companies. And so it’s about like, how do you empower a small team. And the way you empower a small team is by having things that do a bit more work for you, and maybe kind of more of a framework, right? So it’s not, you don’t have to go and pick a new solution or design a new solution. Every time you have a problem. It’s kind of, you’ve got things already within the ecosystem already nicely integrated with everything else that you’re using that do these bits and bobs that you might need that right? So you need a queue library, you need to this than the other in the node ecosystem. It’s like, Okay, great. I need to I need to go research which queue library is the best? And then probably, as a good JavaScript engineer does, I’ll probably come up with my new queuing solution, right? Where, where in, yeah, in Laravel, or the Ruby community, you’ve got kind of packages already built up. You’ve got, again… You probably still evaluate, but I feel like they’ve got a bit more of a don’t reinvent the wheel type of mentality from having kind of a good core to build on.

Noah Gibbs: That makes a lot of sense.

Hugo Di Francesco: Yeah. So it makes for really cool communities, right? Because it’s, because there’s a philosophy really is what it is, right? Like JavaScript is kind of this free-for-all that everybody has to do, because it’s the only thing that runs in browsers.

Noah Gibbs: Yeah.

Hugo Di Francesco: Although that’s changing slowly. And so like, if you think about the range of companies using JavaScript and Node, it’s going to be everything from like, the freelancer working on the site by himself with just a bunch of HTML all the way to like the Facebooks and Googles of the world, right?

Noah Gibbs: Yeah.

Hugo Di Francesco: So it’s kind of, you’ve got so much variety, and there’s no like, underlying philosophy to it. It’s like we use this because we have to, because it’s the only thing that runs where we need it to, right?

Noah Gibbs: Yeah.

Hugo Di Francesco: And so yeah, I guess maybe it’s the fact that there’s just such a bigger, it’s not necessarily a bigger community. But there’s a user base is massive, right? Like, anyone who does anything on the web kind of has to do JavaScript at some point. So.

Noah Gibbs: Absolutely. Yeah, JavaScript is clearly the largest programming language in terms of active development out there. And the only things that might be larger, depending on how you measure is COBOL. Because it has that massive many, many millions of lines, existing source base of big, big companies like banks. And so you could argue COBOL is bigger than JavaScript. Or possibly spreadsheets. The other thing that could give JavaScript a run for its money, as counting as a bigger programming language would be spreadsheets just because of the sheer number of practitioners.

Hugo Di Francesco: Yeah, that causes all sorts of issues. All right. You want to do a very specific thing today is like, Oh, I have to choose between this and that for my server, I have to choose between this and that for my view library. I need to choose something to fetch where they need to choose, do I use GraphQL? Do I use REST, right? And I still probably have the same issues in the Laravel and Rails community, but maybe it’s not what they discuss with their conferences, right? And that they kind of… I think it’s nice, in a way.

Noah Gibbs: I will say it’s part of what they discuss at their conferences, speaking as somebody who’s been to a lot of Ruby conferences, that is part of what gets discussed at Ruby conferences. But yeah, I think it’s a lot less of the of the total. And I think we have a pretty strong core of… This is roughly what we’re doing right now. If you’re used to a more staid and sedate sort of slow moving language, certainly something like C, which is, you know, where I cut my teeth. The speed of the Ruby community adopting new tools is just blinding and breathtaking and more than a little disturbing. But JavaScript certainly makes us look like pikers that way.

Hugo Di Francesco: Yeah, in JavaScript, it’s beyond early adoption, right? It’s churn. It’s just, it’s kind of ridiculous. It’s like, we’ve got this new idea for a new thing, someone comes up with a tool. And then next thing, you know, you’ve got like, five other ways of solving the same problem.

Noah Gibbs: Yeah.

Hugo Di Francesco: And that’s just a I think it’s just a volume thing, right? It’s a user base thing of like, Oh, well, actually, Airbnb did this, but we’ve got this slightly different problem. So we’re gonna do it this way. Right? Yeah. And maybe it’s a bit less collaborative as well. I don’t know. It’s interesting. I feel like people do collaborate, but it’s just that there’s many opinions to be had maybe. Yeah. And because there’s no underlying philosophy, opinions come to the fore, rather than Why don’t we look back at our philosophy and decide from there how we want to tackle this, right?

Noah Gibbs: Yeah. I’m gonna, I’m gonna show some of my bias here. I would argue that Ruby is ridiculously easy to read, as programming languages go. I mean, you can find all sorts of, all sorts of hideous Ruby idioms. But mostly, by and large, if you’re just reading Ruby code in the wild, if you have a particular feature that you’re trying to read through all the code of if you want to read through, I don’t know, a small ORM. Or if you want to read through, you know, some some chunk of functionality, I find that the Ruby code is usually an amazing compromise between very short, so it doesn’t take a long time to read through, but not as dense and hard to read as a lot of more concise, more terse languages. I mean, Haskell can be can be amazing for just how short the code can be. But I find it a lot harder to read through the same amount of functionality, if that makes sense.

Hugo Di Francesco: Yeah, yeah. No, I think that that is something that I saw from the little kind of I’ve hovered around those communities. I did write some Ruby at some point and some PHP and Laravel at some point, but very quickly, you kind of, you head down the JavaScript path. And because of demand, it’s just kind of like, there’s very little need to do anything else nowadays, which is a shame really, but…

Noah Gibbs: But I think Ruby may have a higher density of people who have read through the code of the existing solutions, because the reading’s easier, because Ruby just happens to be a language that’s good at that.

Hugo Di Francesco: I think so too. I think that that is something that I did get into very late. I feel, I think the ratio of packages you’re using from other people, too. Are you actually reading the source? Well, I know from experience, like my personal experience is I’ve been using a lot of packages, without ever thinking about what’s actually, how do they actually do this, right? And it’s only been, yeah, maybe, actually, around the time, I started writing a lot more that I started digging into things, right, because I was like, so a lot of these posts that I’m putting out that are basically like workarounds for weird issues. And I don’t know, test runner, so Jest, right?

Noah Gibbs: Yeah.

Hugo Di Francesco: Weird workaround. I don’t know if you want to, fake a date, right? So there’s a package out there that does this, right? And the package is about 10 lines of code. And my blog post is literally the same thing just inside your tests, right? And in that case, actually doing it inside your test can make more sense than using package because it’s obvious that you’re, for this test, mocking out the day or something, right? When I realized that that package is probably downloaded hundreds of thousands of times, if not millions of times a month, or even week, right? It’s kind of like I realized that I’m likely to do that as well. Right? I would just, if I was in a rush to finish something now, I wasn’t actually trying to kind of think around the problem and, and kind of show with different ways to solve it, I would have just installed it. And I wonder how many developers think like that, right? And my idea is that probably most of them the same way that most developers won’t write down and make public a way they’ve solved some weird problem that they’ve had, much in the same way, most of them won’t bother to read what’s actually in that package they’re downloading.

Noah Gibbs: Yeah, I would tend to agree. Again, I feel like Ruby is… I mean, it’s not perfect. It’s not anything like perfect, but I really feel like it’s unusual in how much people read. And that’s interesting to me, because my mother tongue is C. And C is, by modern standards, really hard to read, like really hard to read, and also tends to be shipped around in precompiled packages where you don’t even necessarily have the source. Coming to Ruby was utterly eye opening to me, because everything I could run I had full source to. And the source was easy enough to read that it was perfectly plausible that I could sit down and read something complex in an afternoon and make significant useful progress on it, which is not either of those my experience in C, certainly.

Hugo Di Francesco: Yeah, definitely. Definitely. And I think what never helped was, again, maybe in the JavaScript ecosystem is I think C might have that issue, as well… Is you’ve got just different ways of writing it, right? It’s very, like there’s styles of the language, right?

Noah Gibbs: Yes.

Hugo Di Francesco: And then that’s that’s made even worse in JavaScript because you had all these like, compile-to-JavaScript type of thing, right? So you’ve got your… now it’s a bit less used, but CoffeeScript. And even now with TypeScript with any build step means that the code you’re running and the code you’re writing is not the same thing, which in C is the same thing. But the output isn’t code that you can try to read, if that makes sense. Right?

Noah Gibbs: Yeah. And see you wouldn’t try. Most people don’t know enough x86 assembly to want to want to weight in on…

Hugo Di Francesco: Yeah, well, then you need to reverse engineer it back to the C code, right? So you’d be like, yeah, that’s, that’s good luck with that. But yeah, so that’s an interesting one, I think. And that’s useful bits of CSS. That’s one that maybe doesn’t get the love it needs anyway, is reading source, right? And that kind of thing. And it does take your problem solving to the next level, I think, because getting rid of that initial fear of, Oh, I don’t know what’s in this package. Maybe it’s… I’m using it wrong, like being able to decide, no, it is in this package, or, yes, I am using it wrong, right, that really takes a lot out of the guesswork, right. And without reading source or being confident enough to go an extra print statement somewhere that doesn’t go away. Right?

Noah Gibbs: Yeah. Well, you kind of start out your career terrified, and you have no idea what anything is, and you don’t know what any of these pieces do. And you you slowly, slowly tame in the wilderness as you go forward, you know, you slowly get to the point where you know what most tools do and you know what most things do. And yeah, being able to read into into the source code of whatever you’re using is a huge step there. You know, it’s a, it’s a massive change toward being able to understand everything.

Hugo Di Francesco: Yeah, I mean, because at the end of the day that’s being able to read the package’s source is not that different to being dropped in a brand new code base that’s been going for a decade or more, and being able to like grasp your way around it, right?

Noah Gibbs: Yeah, it’s exactly the same thing. It’s just a just a question of, of what author name is on the various code that you’re reading into.

Hugo Di Francesco: Yeah. And well, I guess also in the package, a lot of the time is going to be more kind of generic generalized logic. Yeah. Or the business cases and business nomenclature that you’d have in company lambdas repository, right? But it’s, at the end of the day, the source side of it should still be the same thing, right?

Noah Gibbs: Yeah.

Hugo Di Francesco: On one side, you’ve got business requirements. On the other side, you’ve got a, I guess, a package’s contract. But yeah, once you’re able to separate those two, right, that that opens up a lot of opportunities, I think and just frees your mind up quite a lot. Because you’re now able to, yeah, you’re separating the requirements gathering in the business rules, and all those types of things from the implementation itself. Right.

Noah Gibbs: Absolutely. Cool. Well, I should ask you… Pretend to this podcast gets massively popular. Everybody loves what you have to say, everybody hears you. Awesome. On Twitter, when a thread goes viral, you know, you post your SoundCloud. So what’s your SoundCloud? If people hear you, they’re impressed by you, where would you like them to go next?

Hugo Di Francesco: So the blog I writer is CodeWithHugo.com.

Noah Gibbs: Cool.

Hugo Di Francesco: That’s kind of what I’ve been trying to describe, haphazardly throughout the podcast, which is a collection of things that I’ve had issues with a lot of the time, because I do a lot of different things day to day, it could be everything from how to set up ci pipelines a certain way to, I guess, some shell scripting to, there’s a lot of JavaScript on there, there’s a bunch of testing content on there. Because that’s that was my focus recently. And then there’s random kind of ramblings as well, but most of it is very applicable. And it’s very Google friendly. So I don’t expect people to actually go there and read through all of them, but I expect them to, to if they’re working with Jest or in JavaScript in general, they might just land on the website randomly.

Noah Gibbs: And if they see CodeWithHugo, that’s you. Yeah, I have a I have a big soft spot for the fact that I go to it and your first article, The Future of PHP, Is It a Dead Programming Language? Which really reminds me of something I wrote recently called, “What do they mean, when they ask if Rails is dead?” I suspect we’d find some some common ground in how we were talking about the two.

Hugo Di Francesco: It’s that wonderful hype cycle, isn’t it?

Noah Gibbs: Yeah, exactly. That is exactly what it is. Excellent. So let me ask you, before we go, I certainly don’t know you anywhere near as well, as you know you. There are all sorts of things I could ask people and all sorts of people I ask them to, but what is it that I should have asked you that I haven’t asked yet? What is it about this topic that, you know, that you know better than other people that I should have asked you and I’ve completely forgotten to?

Hugo Di Francesco: I guess I know about JavaScript testing. But that’s, that’s not interesting in a lot of ways. It’s a lot of… Yeah, that’s my my thing. Or that’s been my thing.

Noah Gibbs: It’s a good thing. Do you find that there’s… That JavaScript testing has much use for computer science stuff? I’ve made a lot of people who would argue it doesn’t. What do you think? Does that have much use for computer science theory?

Hugo Di Francesco: Probably not. Probably not. Testing in general is very, very language specific, right? It’s I mean, my favorite example is in Python, when you mock something you mock where it’s being used, right? In JavaScript, you mock the thing that’s being used, right? It’s things as simple as that. That it just like, you go from one language to the other, most things are still there, right? You’ll still have your loops, you’ll still have your functions. You might not be able to do certain things like, I don’t know, pass functions around. But then you can pass other things around, right? But testing is one of those where, like, the best practices, and even the way you do it is completely different, even though fundamentally, you’re doing the same thing, right? So yeah, that’s one of the big ones with testing. And yet, computer science doesn’t really, doesn’t really prepare you for that, except, like I was saying, separating between what you’re trying to do and how you do it, because that does stay the same.

Noah Gibbs: That makes sense. That makes a lot of sense. Cool. Thank you very much. It has been wonderful to talk to you. It’s great to have you on.

Hugo Di Francesco: Likewise.

Noah Gibbs: This has been Computer Science: Just the Useful Bits and this has been Hugo De Francesco. Thank you very much.