Programming Throwdown - Congratulations!

Episode Date: January 21, 2016

This show celebrates 50 episodes of Programming Throwdown! We answer questions from the audience live on livecoding.tv . ★ Support this podcast on Patreon ★

programming throwdown episode 50 congratulations take it away j Hey, everybody. This is a special episode of Programming Throwdown. And, you know, if this is your first time listening to a Programming Throwdown episode, we typically talk about a different language or computational concept every show. We start off with some news, tell some jokes, things like that. We're not doing any of that this show. So if this is your first show that you've listened to, if you're brand new to Programming Throwdown, hit pause, go back a few episodes, check out one of our other ones.

This is really just a special episode that we want to do for our fans, give them the opportunity to ask questions, make comments, and we'll read them on the air. And so we're also broadcasting this particular episode live on livecoding.tv slash neural nets for life, the number four. And we'll give a link to it in the show notes and all of that. But that means that we're gonna be fielding some questions

from the live audience. And so that we're going to be fielding some questions from the live audience. And so that might cause us to, for one, it's definitely all one take. It usually is anyways. We always record this. People don't know that maybe, actually. Yeah, good point. We always record in one take unless something really, really bad happens, which has only happened like once or twice where we've had problems.

But otherwise, it's one take all the way straight through, almost no editing, slap on the beginning and the end, which hopefully the beginning part has gotten a little better. I think people used to not like it. Yeah, yeah, definitely have tightened that up. Early, early, yeah, totally. So in this episode, we're going to kind of talk about the history of the show and everything, give you guys an insight. I've heard to say folks instead of guys. Folks.

Someone said don't say guys. Is that more politically correct? Say folks or yous, which I just can't do yous. Y'all? They also said y'all. I don't think I can do y'all either. All right, y'all. Let's get this started.

I've relegated myself to folks. We'll give you folks an opportunity to ask us anything you want to ask us. And we've gotten a ton of questions and comments. And we're just going gonna kind of go through it and also field some from the chat as we go. All right, the first one is one we've gotten several times, and we're gonna only give the partial answer to, so apologies.

And sometimes there's been multiple questions, and I sort of randomly picked a person to represent that question. And we didn't cover all questions. There are many, many questions about, will you cover topic X or Y? So those are left out. Don't feel bad if you email us with those.

Hopefully, we'll cover all those eventually. Yeah, we've gotten so many people saying, will you cover Ruby? We will cover Ruby, but not today. All right, so our first question is from Mariano. And they say, I have a question. I have friends that are taking courses in edX.org, CodeAcademy.com, Lynda.com, which are very useful websites to learn as a beginner going towards advance. Being that the job market for programmers are majority looking for a BA or MA,

a bachelor or master's degree in computer science, would it be tough to get hired by learning to code on your own? Or what would be your experience? And that's Mariano. Cool, Mariano. You're the first question of the show. Congratulations. Fanfare.

So basically, this is a great question. I actually thought a lot about this. I asked a variety of people, personal friends and colleagues. There's sort of an inflection point here. Think about it. Five, 10 years ago, there was really only lynda.com. There wasn't Coursera or –

When this podcast started, we didn't have smartphones. That's right. Or we had just gotten them. I think you had just gotten one. I didn't have one. I think what the iPhone, like, 3GS was out or something. Yeah, something like that. But, yeah, basically, you know, since then, a lot has changed.

It's changing very rapidly. And a lot of people are saying, look, Coursera has these amazing courses. They're taught by MIT professors. But, you know, when I apply for a job, you know, or if I'm hiring somebody, you know, how can I kind of take it seriously? You know, what's the accreditation level and things like that? It's a very difficult question. This is the way I break it down. If you have a bachelor's or a master's degree,

that's always the gold standard. There are accredited universities and that's always gonna be the best thing. If you don't have that, it's good to have good background with Coursera, Udacity, these courses, combined with an active history on something like GitHub, right? So if you have a GitHub with a bunch of repositories, you've contributed a lot, you are one of the authors of Homebrew or something like that, and you have some Coursera courses just to show that you picked up the fundamentals,

then I think even if you don't have the college degree, I think you'll still get noticed. And that's really the key. Once you're in an interview setting, your resume isn't as important. Most people will, you know, jump straight into most people already know what three questions like they're going to ask you. Hopefully not the fizz buzz question and, you know, some dynamic programming question. They know already what they're going to ask you. And if they see that you have a bachelor's in psychology, they're not going to redo the whole interview. But the key is, how do you get to the interview stage with, and I have nothing against psychology, but how do you get to the interview stage with, you know,

a bachelor's that's not CS or engineering? And so I think, again, you know, GitHub links should be the first thing on your resume, bunch of repositories, bunch of open source contributions, and the Coursera courses. And I think that can get your foot in the door repositories, bunch of open source contributions, and the Coursera courses, and I think that can get your foot in the door. Yeah, I would agree. I think it'll be very difficult for having a boot camp

or Udacity, even with their certificates and stuff, which they're getting better. And in five years, this show may just seem completely dated. You pointed that out, that this completely changes. But having worked for, with, and talking to people who also work at large companies, at least, there's a lot of filters because you get a lot of junk resumes in.

And it's, as you said, how do you get into the, let's talk to these people. Because once they talk to you, they may find out you're a great person, they'll hire you, whatever. But how do you get into that pile? How do you get past that filter? And as you said, it's going to be really hard. So I think somewhat you actually have, I don't know,

I've never done this, but I would assume it may be something you have to take a chance on, like you have to take a job that isn't the job you would necessarily want for pay. You might not necessarily want the GitHub stuff is, is great. And that is necessary, but ultimately somebody is going to have to take the first risk on you yeah the thing about the Bachelor of Science or masters or BA or whatever bachelor's degree or master's degree or PhD is that you at least had the tenacity to stick through University which is notoriously grueling you know to various degrees depending on the university and so the company is taking a bet that that is correlated with your ability

to stick it and at least learn something and be productive at the company. And if you miss that, it's much harder. Not impossible, but it is much, much harder. And so you're going to have to do something to get your foot in the door. And that may mean taking a job that is, you know, you just volunteer, like, for instance, to code for maybe a volunteer organization or a startup, you know, that's local to your area where, you know, hang out with them and like try to get involved there. And even if they don't pay you, but at least you can start to

and not just say like, oh, hey, I worked for these people when you didn't, but get them to actually acknowledge your contribution so that you can honestly say like, hey, I worked for this company. Yep. Yep. I know a lot of people at Mozilla are people who contributed massively to Firefox. I mean, it's kind of, it's obvious when you think about it, but it's true. And now, you know, a lot of them also have degrees and things like that.

But I think that showing a lot of contribution to some, one thing that a lot of people don't know, and we've talked about it several times, but it's been a while now, is a lot of these open source projects are really run by large companies. I mean, if you look at LibreOffice or Java

is run, like IBM and Oracle are the two main contributors to Java, right? To the JVM. And so you're contributing to those product, open source projects directly connects you with a lot of engineers in the industry. So that's something to keep in mind. Yeah. And those engineers can put in your resume and an engineer putting in your resume, having noticed you is always going to be better than applying

blindly. So that's another tip is like, if you know someone, always have them put in your resume because that universally leads to better results in my experience. And we should also preface someone pointed out in the chat room that most of our advice is oriented to the U.S. Some of it may be applicable elsewhere, but, you know, Jason and I both live in the U.S. and I have lived in the U.S. all my life. And so I don't know, other countries may or may not be different in varying degrees. So that is a caveat. A lot of people do listen from outside the U.S. and we're thankful to have you guys. Definitely. Definitely. Awesome. So I'll read the next question and I'll go ahead and start answering it. You can find maybe a question from

the chat room to follow up with. Okay. All right. So this is from Ashley and they say, first, what is the story behind Programming Throwdown? What made you decide to get together and make a podcast on programming? I assume Ashley probably had other questions and I probably clipped them out for time. But the story behind Programming Throwdown is Jason and I used to work at a company together

and we would kind of talk a lot about topics related to work, related to programming, but not, you know, just about, you know, the stuff we were working on, and realized we both had a passion for this and said, you know, kind of like people say, how do we do open source?

How do we do whatever? And Jason does a little more open source than I do almost. I do none, not almost none, actually none. And so it was like, how do I get involved? I don't really want to do open source. That's not the way I roll. And so one of the things we talked it was like how do I get involved I don't really want to do open source that's not the way I roll and so one of the things we talked about like hey we could have a podcast at the time it was kind of like hey there are these school podcasts I listen to a couple let's do one like why not yep and

from my perspective I really I had two choices I could either become a teacher or I could go into industry and I decided to go into industry but I still really love teaching. And this was a way for us to both teach something while still being in industry and being able to work on just very large projects with lots of people. And a way to stand out as well, right? So we do the podcast, we get to teach, we get to do something we enjoy. I didn't, to be honest, think it would last 50 episodes. I didn't think it would last five episodes. I think most people say episodes die, I think, before 10. So you can't say you're doing a podcast until you've gotten to 10. So you're on past 10. Maybe someone else

will tell us you can't be a podcast for reals until you get to 100. Maybe. So we've done it past 10. It hasn't always been as regular or irregular. But I think one of the things is to stick out, right? So people say, what makes what makes you different? What, you know, if you have a passion, often people say you'll code whether someone pays you to or not. That may or may not be true due to various life circumstances. I don't happen to do that much coding in my off time, but I do this, right? This is a similar outlet for me. I talk about programming and talk about tech. I teach, you know, so that's kind of the story. That's not a great idea. And then just kept doing it even at one point Jason was in California and I was in Florida we were doing it now we're both out here in Silicon Valley we

work at different companies and we still do it yep so it's just kind of stuck with us they're thinking that no you're thinking didn't so yeah in sickness or in health actually no terrible we're no, no. Actually, no. That's terrible. We're not married. When we're sick, we definitely don't do the podcast. Yeah. So, yeah, definitely the motivation for us is the feedback that we get. I mean, we get so many people who are saying, we got someone yesterday saying, you know, I'm an engineer in Kenya and I don't have, he said he didn't have as many resources as he feels like a lot of people have access to, but he does have access to this podcast. And so that was kind of powerful. You know, I mean, the fact that we could spend some time and hopefully bootstrap somebody who has an incredible amount of passion and might not have the right resources or or or

somebody who has a great background in one field and wants to you know make a change and or someone who's in school and doesn't know what major they want to pick I mean these are all people who hopefully we've we've helped some of them you them through encouragement and through education. We've helped some of them make their decisions. Or just helping people pass time. Yeah, that's right. Like not be bored or laugh at us for how terrible this is. Whatever.

It's all good. I wonder if it's gotten better. The number of people laughing at us has gotten higher? That's definitely true. Okay, okay. So the sheer number of people laughing at us has gotten higher? That's definitely true. Okay, okay. So the sheer number of people laughing at us has gone up orders of magnitude. Yes!

Because, you know, the first episode was just our moms laughing at us. And now there's thousands of people laughing. My mom told me she didn't make it through the whole first episode. I know, mine too. She's like, you boys are so sweet. But yeah, I couldn't listen to more than 10 minutes.

Uh, yeah. But yeah, basically it's feedback from you guys. You know, for people who are brand new, uh, um, subscribers, uh, you know, we have programmingthrowdown.com. We have Twitter, we have Facebook, we have Google plus, we have email. Uh, yeah, I, uh, I'm a social maven, although I don't, uh, post as much as I probably should. I'm a recluse. Um, but yeah, Patrick has none of this.

So actually, it's amazing. Patrick, you have to email him directly. Do you have anything besides email? I have Google+. Oh, OK. People follow me occasionally on Google+, but I don't post. I'm a terrible person. Got it, got it.

But yeah, definitely give us your feedback, questions, comments. That's what drives us. So cool. Next question is, we'll take one from the chat someone said how many female engineers are there in embedded mobile web etc we'll just say in programming the short answer is not enough right I mean the ratio of female to male in software engineering is not 50-50.

But there are a lot of great programs. I feel like this is something. So I have sort of two thoughts on this. One is this is something that's going to just get better over time. I think that every generation, if you look at, if you compare yourself to your parents and to their parents and to your kids, right, every generation has sort of a different understanding of humanity. So you're saying people become more... Okay.

Really? Let's hear the second point. Let's hear the second point. Okay. Well, I just feel like things are on a good place, sort of on a good path there. I think that things are becoming more accepting. I think it's important that we're recognizing it's a problem. Right.

That's a good first step. Yep. I'll agree. So I feel like things are getting better passively, but I do think we need to take more action to sort of help this because it needs some bootstrapping. It needs some acceleration. Otherwise, it will just be floating in this one direction that's been in for a long time. So there are definitely a lot of efforts. I think actually the Raspberry Pi Foundation donated a bunch of money to this,

I think it's Girls That Code. And it's a charity event that, a charity foundation that hosts a bunch of events to try and get more females into software engineering, developing, coding, things like that. There's also, there's a couple of other efforts. I can't think of them off the top of my head. It's like Grace, Chen.

I think I'll agree that it is a problem, and we are beginning to take the steps to try to address it. But I think with anything, it's a long pipeline. I think a lot of studies show that decisions about kind of what general areas you'll go into, what kind of fields, or at least for some fields like engineering, math, computer science, are made as early as like middle school. And so unfortunately, if you kind of say everyone past middle school is going to be very low conversion ratio of fixing the problem, right, then unfortunately, that means it's going to take many years of concerted, continuous and deliberate effort. And so it's not something that we can expect to change overnight by just simply throwing money at the problem. It's something we have to

cultivate. And, you know, so I have two daughters, right? So thinking through like, how do I enable them that if they want to do this as a career, like how to make sure that they don't get told otherwise, right? Or how to make sure that they're encouraged and supported. Right. Um, and those are things you have to culture over a long time. So I think it's going to be a long road and I hope, I don't trust like you that it just by nature will get better, but it seems like we're starting to recognize it's a problem and hopefully enact changes that'll improve things. Cool. And someone just posted in the chat, I think it's girl develop it. I think that's actually the foundation that I was thinking of.

They got it correct. Yep, that's it. So yeah, so girl develop it. There might even be another one, but. I think there's several others, but yeah. Cool. All right, so next one we have is, this is so, we had this from a lot of people.

I didn't even actually go and find some specific one, but this is you guys have this from a lot of people i didn't even actually go and find some specific one but this is you guys to talk too much or too little about the news or programming languages uh i'd like you to talk more or less about the news the programming language is the book um so like again this is like i guess you call it insider baseball behind the scenes about how this podcast is recorded but i mean, the podcast is something we do. We don't really get paid for it. We have some like the Patreon stuff and the Amazon

and your all the subscriptions. We're very thankful for all of that. And that helps encourage us, you know, to a large degree to keep going. And pays our costs. It actually is significantly expensive to, I mean, we,

I checked last month, we used four terabytes of bandwidth last month. Oh, yes. Like one cat video on YouTube. Yeah, that's right. And so these things are encouraging to us, but ultimately it's something we have to enjoy

because if we don't enjoy it, we're not going to do it. This isn't replacing our jobs, right? So we have our jobs. We both have families. And so we need to enjoy doing this. And one of the things we enjoy is just like chatting about tech stuff. Like that's what we do. That's who we are.

And so this podcast is an extension of that. Also, it turns out it's actually really difficult to talk at length about a lot of the topics, the programming languages. So we try to do a good job. We try to cover it. But ultimately, there are other podcasts I've listened to where it's all about a single topic and they talk the whole thing and I find myself drifting off like it's not the same this isn't to that podcast we're sorry if you don't like it we'll give you your money back you didn't pay for it

but you know ultimately the balance we try to strike is covering topics that are interesting to people in the field of programming giving you a little you know tidbit about something we're not trying to bury the lead we're not trying to make you go through all the other stuff we could cover it in the beginning, but it would mess up kind of our flow.

Like we need that other stuff as like a warmup. And as we said, we take this in one take. So we would have a hard time not referencing stuff we already talked about. And then it would be all like confusing. And we'd have, so yeah, that's just not. We tried it. We thought about it.

And yeah, it just doesn't work. It just doesn't work. So we have to do the news and the other stuff first, because that's the progression that works for us. And if we talk too much about it and too little about the other thing, you know, sorry. There's always next episode. Yeah.

The idea is just to leave you with a tidbit, a morsel, something. Hopefully you walk away with something you didn't know. Right. And then if we ever, you know, now that we're 50 in, I guess we have self-granted permission to go back and revisit some topics. And so maybe we can get into more specific aspects. And I think that's something we should do. So like specific parts of C++ or C or the things we're really into, it'll be, you know, cover those in more detail. The other things may or may not get revisited. We'll see 50 is a lot, but there's a lot to come, lots to still

cover. Definitely. I mean, the other part of it too is the audience is kind of different. You know, I mean, a lot of the people who write in and they say, you know, I really love Python. I think Python is such an awesome language. You know, it only got 15 minutes in one episode. And we love Python too. The issue is there's many people who are just getting into this for the first time. And if we really dive into, oh, you know, why you have to use multiprocessing instead of multithreading so you don't get the, you know, GIL, you know, the global interpreter lock in Python, then it kind of loses the spirit of the show,

which is to show you enough about a language that you get really excited or enough about a language where you can give you a foothold where then you can scale that mountain of being an expert in that field. Yeah, I mean, in an ideal world, I guess we could do two podcasts. And one would be for teaching beginners, people not in the field or people just looking to commute. And then another would be in-depth, hard topics. Right. And hopefully wouldn't fall asleep. But well, there's plenty of people are really good at that second one, I think. Yeah, I think there's other topics. And then also,

I'm not sure, like, although it sounds good to say, like, if you actually sat and listened to it, if you would be really into it. Yeah, I think it's much faster to look at for me, at least I need to these things like we talk about are good for me to listen to. But like when gets too detailed i need to see it in front of me i'm a visual guy i guess same here same here cool uh so we'll take one from the chat this is an easy one uh where are you from so i'll go first um i was born uh in canada i lived in canada until i was about 10, moved to Florida. I lived in Italy for about three or four months, then moved back to Florida and then to California. Well, I didn't know all that.

Yeah. I knew some of it. So I was born and raised in Florida and moved to California when I started my current job. So, yeah, it's pretty boring. Yeah. Central Florida the whole time. So someone else also asked about VLSC architecture. I didn't see, or VISC.

I just looked up what that was. So I didn't know what it was. So I can't say anything intelligent about it, but maybe I'll read the article offline. Okay. That will be one of our news topics. News topics. And we'll spend the whole hour talking about it.

All right. So another question someone sent in. Oh, this is the second question from Ashley from above. They wrote, in the last episode, you mentioned how useful it was to have a good knowledge of assembly. I've dabbled in it before, but I'd like to improve my skills. Is there a specific assembler you'd recommend? They've come across several. And is there any good book or learning resource you can recommend for learning assembly?

Yes, lots. And I'm sure we could probably try to generate something better, but actually we had another person write in and answered their question unrelatedly. So I'm just going to read their answer. So this is Tim and Tim wrote in to recommend, which I haven't read this book, but it does sound interesting. Charles Petzold's book, Code, the Hidden Language of Computer Hardware and Software. I've heard about this book. And it says, yes, that's the Charles Petzold of programming Windows. And I'm probably not saying the guy's name correctly, but he wrote a little bit, Tim wrote a little bit more about this book and it sounded interesting. I looked at the webpage for it. We'll have it in the show notes.

That seems interesting. So maybe check out that. There's also several resources for, you know, the interesting thing about assembly is that because the instruction set leads to understanding the architecture, a lot of times there are simulators online. And we'll talk about a little farther down a fun education, fun, but maybe educational way

of possibly learning assembly a little in a few minutes. But there are lots of simulators and you can use those simulators online and you don't really even need to, like it's cool to write assembly for Windows, but it's really hard because you need to do a lot of stuff. So you really don't want to be doing,

or I don't want to be doing that. You want to use a microcontroller or something. Yeah, and even when I write assembly in my day-to-day job, it's always in a very specific context and for a specific reason, I don't start there. And that's because it's a lot of verbosity to really do everything that way. That makes sense. Someone in the chat asked,

What programming language paradigms will we see in new programming languages and work their way into existing ones? So this is a pretty tough question to answer on the fly, but I will tell you about one thing that I think is super, super cool. And I've tried to look it up. It's basically a probabilistic programming language. And I had a great article on it, but I don't have it with me at the moment but the idea is all of your variables are actually distributions so you can have a variable that says you know instead of saying X let's say you wanted to roll a die right

but you wanted to have a system that handles you know the dynamics of a die roll right so if you just said X equals you know Rand six you'd get a number a system that handles the dynamics of a die roll, right? So if you just said x equals rand six, you'd get a number between zero and five, right? But in this case, you can actually say x equals uniform distribution from zero through five, and x actually holds that distribution. It doesn't just hold one number from that distribution.

And you can do crazy things like add distributions and things like that and then um there's also pi mc if you if you want to look at a python library that has this but you can do all of this complex math and when you're done you end up with this like really heinous joint distribution and then you can just say you give me the expected value, and it'll go through and crank a bunch of simulations and things like that. But the variables are literally variable.

The variables are holding... The distribution. The distribution. They're holding the hyperparameters. Interesting. And you do all your programming like that. So I think PyMCMC is one, and there's a bunch of others, but we'll talk about it in a future episode. But I think that is one thing that will kind of get to be more popular

as more and more of the world has to deal with noisy data. I mean, anything big data is going to need kind of something like this. Yeah, my thoughts about this is that all the things we see, the functional, the actor stuff, the object-oriented, all of these are trying to say this is the way to solve problems. And I'm increasingly convinced that we're coming to an understanding as a software community that that isn't the right attitude to take. There's not one. And I hope that's one of the things that programming throwdown we mentioned is that most languages have strengths and weaknesses. I don't think all of them have weaknesses.

I'm not sure all of them have strengths. But all of them have weaknesses. And the idea is I think we're going to move not to one language that's multi-paradigm, like a C++, but instead moving to things where we're able to smoothly move between one and the other. And I think this is things where like, it sounds weird, like Microsoft may

have been ahead of its time a little, like supporting everything, or even like Java. We have like Java in Scotland, like C Sharp. The C Sharp, J Sharp, all that. Yeah, yeah, yeah. Right? And even- So just for people who don't know, Microsoft has this thing, what's it called? The dot, well, this.NET framework. Yes. Microsoft has this thing, what's it called? Well, it's a.NET framework. But basically, they took a lot of the existing languages,

C Sharp, J Sharp, which is like a Java kind of knockoff thing, and a bunch of Visual Basic.NET, and all of it compiles down to one common language. It's similar, actually, LLVM is really the same way. Right, so I was going to say, so now that we have LLVM, you have the Clang front end. This is all very similar. And now it's starting to happen on the web a little

where people are writing and it's happening with frameworks in JavaScript. I think, I'm not a big JavaScript, but I kind of see it a little from looking from the outside. Totally. That people are having frameworks

with different paradigms, but they now are interoperating. Like, let's pick the thing that's best for this task instead of trying to do everything in one task. And that's a pro and con. So the con is that now people need to know multiple paradigms and how to program in them and move between them,

which is very hard, but it has the pro of hopefully using the right tool for the right job. The question becomes how far out of inefficient, how inefficient should you get before you switch to the other thing? And as we make that friction and moving back and forth between them, I think that will be the future where teams won't be able to just do

in one language anymore. But- And things like, you know, protobuf, thrift, and these other technologies that are designed for communicating between processes very efficiently and things like that will make all of that very easy. If you figure, you know, this sort of deep learning package in Python is really great, but all of my code bases in Java, well, it's no big deal, right? You just write some kind of thrift or protobuf RPC layer. And so a lot of that technology is pretty new. I mean, before you would have to do a lot of that by hand. So it lowers the barrier for doing multiple languages on one team. Why do programmers love to hate on PHP and praise Lisp?

And this is from Ariel. And yeah, so the reason why is because this is just common in what I guess you get into the nerd culture, which is the my way is the best way. Everyone else is, you know, Star Trek is better than Star Wars. No, no, no, Star Wars is better. You know, just getting in that kind of fanboyism is maybe other parts of society have it as well, but I know it's very rampant in tech, and I think it's just that is what you see,

is that people like to say, oh, PHP is terrible. And it just happens because most people working at the big companies aren't writing in PHP. And so they kind of throw those stones that PHP, from what I understand, I've never done a lot of coding, but does have some flaws,

has some problems, has some bad assumptions. They try to fix it, patch it. And ultimately what it ends up is people know what we talked about last question. It's like people know a language, and they try to solve all the problems in that language. And then some languages handle that better than others. And so I think you start to see that problem.

One of the things that I think about Lisp is that it's so minimal that people end up building up a lot of infrastructure to make the language support their current paradigm yep so you write like domain specific language kind of things in lisp to help you do what you want to do so that list becomes the language you need for the the current opportunity but that like we said before has pros and cons and you know depending if you're not a language designer by trade you can kind of work yourself into a trap. But people kind of have that belief like, oh, Lisp is so beautiful because it's so minimal,

because it's so flexible, because you can really make it do anything and not be like, oh, look, it's failing down there. That's why I think you get that fanboyism of it's an artistic, beautiful expression to see how far you can stretch this minimal set of instructions. Right, right.

Creativity through restraint or something. Yeah, I haven't seen too much of the Lisp love i have seen a lot of the php hate um i mean obviously you see it with like functional love like oh you got to be programming functional or you're not doing it right yeah that's a lot of haskell and and a lot and for a long time it was universally accepted like well that oh was the only way yeah Yeah, that's right. Everything needed to be an object and objects and object, right? And in college, like, that's how I was taught. It's like, just everything's OO, right? I remember, like, basically having discussions about, you know, how do you solve these problems where you have different objects and they're holding

basically the same data, but they do different things. And basically I was trying to arrive at functional programming, but I didn't know what it was at the time. This was, you know, I'm like, I don't know, in high school or something. And, yeah, everyone was just like, oh, yeah, you just make a bunch of objects, and you inherit the other objects and just override the functions without changing the data types. And then you end up with kind of like how Hadoop is now, where you end up with a mapper

class with a map function and it's just kind of a nightmare. So I think that again, as Patrick said, for different tasks, different languages are amenable to that task. And yeah,

OOP isn't great for everything. Functional languages aren't great for everything. And so it's just, yeah, I think a lot of it is just finding the right tool for the job. It's kind of like being a mechanic. I mean, a mechanic has a huge toolbox. And, you know, maybe, you know, a torque wrench is good for this. I mean, you could use a socket wrench, but it's very difficult. And so a lot of being a mechanic is knowing sort of what tools to use at the right time. And specifically for PHP 8,

I think it is somewhat just class derision, a caste system, as it were. Because I think what happens is people were using, who learned PHP learned it to do like web development, but that was early web, right? And so, well, relatively early, I guess. And so people were like, oh, you're a web developer. You're calling yourself a software engineer, but you're not.

Like the code you're writing isn't at the level of complexity that someone else is writing. And so therefore you're a worse person. That's true. And so I think the same thing happened with JavaScript for a long time. But now web apps have become so complicated, it doesn't really work anymore. And it kind of just faded away.

But a lot of people, it was like, oh, you do web programming and you make JavaScript apps or Flash apps. You're a second-class citizen, right? You're not a software engineer. That's child's play. And that's just ignorance, immaturity of the thing. And as time has gone on, a lot of those people, now some of them probably made the leap.

Some of them probably just because they wrote you know a web app that was really simple doesn't mean they can also write a game engine right or whatever but they didn't need to that was fine what they were doing was the right tool for the right job perhaps and they did a good job but then they tried to say they were something more and then you know not all of them were able to actually do that but some of them were some of them that was just their first language they, and then they moved on and did other stuff, right? And it turned out they were great programmers. I'm sure great programmers and terrible programmers started in PHP. Yeah, that makes sense.

Makes sense. And then we had to follow up. Why haven't you covered PHP? We will. I've actually done a decent amount of PHP. Really? A long time ago, a very long time ago. So why'd you stop?

No, I'm just saying. Really? A long time ago, a very long time ago. So why'd you stop? I'll say I stopped because really when Rails came around, I mean, Ruby on Rails and then Grails, and then I felt like, I mean, PHP was great at the time, but I feel like if I had to make a web app now, it would definitely be like Node.js or Ruby on Rails. I think these things have really eclipsed PHP. And it's not a dig on the language.

It's just the scaffolding. Yeah, there isn't a lot of excitement around PHP anymore. Yeah, that's right. But there's not a lot of excitement around, really, around C++ or Java anymore either. But they've just reached such critical mass that there's so much work to be done in them that they survive. Yep.

Yeah, definitely. Okay. I would like to hear an episode about the open source and free software, the ethics behind it, and how someone could actually have a viable business which creates open source software. This is from Christopher. Good question, Christopher.

So, right. So, well, there's obviously companies that run on open source software or make use of open source software. I mean, almost any company, really. If you look at any of the big name companies, they're using some open source software. I mean, if you, I remember, this goes way back, but when I beat Warcraft 3 3 or might even be warcraft 2 but but when i got to the ending credits they actually put the open source um uh um attributions in the ending credits and i remember seeing you know zlib and all these open source prod lib png all these open source projects and and looking them up online and learning about them.

And it's so cool. And basically, since forever, I mean, I don't even know, probably 20 years or something, all the major companies have been using open source, right? So there's a lot of things with licenses, what you can and can't do, and GPL. And I don't really want to go into that. We're not lawyers. We'll just say there is some open source software that if you're a private company, you can't use. You can't package with your solution or you have to use it in a certain way.

And there's other licenses that let you sort of do whatever you want. Some of those have both. So they offer one under if you want to use this and you're not a company making money off of it you can use a free one but if you are you need to pay to license it right appropriately with a different license yep that's right um another thing so someone uh so so some part of this question is actually um can you build a whole company around open source? You know, say Red Hat, for example, right? And yes, you absolutely can.

I mean, there's a lot of companies where maybe not everything, but everything except the secret sauce is open source. I mean, if you go on, say, Twitter's GitHub page, they have just tons and tons of projects. No, I don't know, but that's a good example. I mean, I think an example would be more like someone who's really behind like Hadoop or something, right? And they're like pushing,

they're owning that community. Like Apache Foundation or something. No, but that's not a good example. But yeah, like if you took someone, and I don't know if they do, but like if you took like Cloudera or someone who's really pushing that technology. They're mostly doing open source,

but maybe they sell a couple of modules that are secret sauce, but they have alternatives that aren't, but they are mostly, I think, in my opinion, selling consultancy. That's right. We'll help you run your jobs. We'll help you optimize your jobs.

If you want features added, you can pay us and we'll add the features you want. That's one opportunity. Another opportunity is one I described, which is like you have two versions of the software, an open source one, but it has a license such that you can't use it if you're not also open source or whatever. But then you can pay me and license it instead. And then that's kind of like a try before you buy almost.

And, you know, that's another way. You can sell consultancy as yourself or your company, bug fixes. Yeah. And keep in mind, like something like Hadoop is a great example. Git is another good example. You know, if you're a huge enterprise and you're using Git, and all of a sudden your repository just, you know, gets too big or you need, like, directory-specific access control lists or something like that, you know, you can go to, I guess, Linus Thorvald's

company. I don't know what you would do in this case, but there's people who you can pay who will fork the Git project and do something custom for your company. And so by getting a lot of the mind share on a particular feature, such as Git has a lot of mind share on version control, you can then make a lot of money

and build a viable business out of just supporting that for people for whom that software has a lot of value. Or even just hosting it for them. So that would be something like WordPress. Yeah, WordPress. So you can run WordPress on your... I might be misspeaking.

No, you're right. You can run WordPress, but it may not be open source, but at least it's free, right? You can run it on your website for free, open source, but then they'll offer to host it for you, which has the advantage that it'll be secure, up to date, and even they could offer early release of features

if they wanted to, and they'll host it for you. They have metrics that they won't you know, that sort of stuff. Yeah, yeah, yeah. So that's another way. Yep. So Great question, Christopher. Can you talk about third-party metrics and data collection systems from Kenny? So there's a lot of these. We should do a show on this.

So what do they mean? I don't actually know what this question, like data collection. So this is actually a huge paragraph. I just took the last sentence. Context. Yeah, I'm cheating. So Kenny wrote some apps and he has a website and they're all, you know, using the same server. And the question is sort of how can I get some good metrics. Got it. We'll cover this in a ton of detail. We'll do another show on this.

But one thing that I'm starting to get into, which I think is pretty cool, is called ELK. And the ELK stands for Elasticsearch, Logstash, and Kubeana. And like I said, it's a whole show. But basically, you can give them logs where it's just lines of JSON objects. And they parse the logs. They do some kind of filtering and machine learning.

They generate a bunch of pretty graphs. They basically do all of it for you. You can even have 100 machines that are generating these logs. They'll handle aggregating it and everything. There's a bunch of pipelines like this that are open source. That's one that I'm most familiar with.

But these are like Google Analytics or something where you just put a little tag. You basically send a request out to a server and it logs that someone did something. Yeah, Google Analytics. There's Google Analytics. There's Google Analytics. There's a couple other ones.

Yeah, there's several, yeah. Yeah, I can't remember off the top of my head. But that is even more hands-off where you don't even generate the raw logs yourself, but you sort of send hints to, I guess, Google. Say like a hint, like someone clicked on something or a hint, someone went to a page. And then they

take all of these hints and group them all together yeah all right next question is how frequently do programmers make use of open source software in their production quality projects from alex oh i think you already answered their question a little we covered you we were uh thinking ahead we covered you with christopher's question so cool all right next question oh go ahead a lot yeah pretty much yeah and at big companies it is a concern you always have to write down when you use or bring in open source stuff and make sure you obey the licenses because it typically goes through your legal team yeah like oh you if you use the software send me a postcard well is that like a legally binding agreement are your lawyers okay? Is like, you had to like send them a registered postcard so you can prove

that you did that, right? Like, you know, I'm not a lawyer, so I can't say if those things are, well, hold up in court, but you don't want to get sued, right? Getting sued sucks. Getting sued is a nightmare. Just, okay, a little bit off topic, but we'll talk a little bit about, have you been sued or been part of a lawsuit or anything? Okay. So if your company gets sued, a number of things will happen that you won't like. Number one, they will give you a new machine. You can copy your things to the new machine, but the old machine has to stay sort of like just preserved.

Yeah. So pain point number one, right? Number two is, you know, you're just going to have to deal with a litany of back and forth and meetings and things like that that you don't want. So, so... Dispositions, is that what they're gonna have?

Like go make statements and they record you and like, yeah, that sounds not fun. Yeah, not fun, not fun. So, so yeah, I mean, it's a huge time sink. Yeah, don't get sued. All right. So the next, oh, we have one from somebody asked. So has Docker found its way into your daily workflow?

Has Docker found its way into your daily workflow? I got Docker up and running. I did it actually to run the TensorFlow. Did you see this? Yeah. You know about TensorFlow. So Google released this thing, TensorFlow, where it lets you do a bunch of data analysis and machine learning and things like that.

And they released it as a Docker image, which I'd heard about Docker, the company, but I'd never really gotten into it. I was able to get it up and running, but to be honest, I haven't gone beyond that. Oh, no, actually, I did. I got a Docker image for... There's a way you can compile Windows binaries on Mac

using Docker. So it actually... There's a Docker image that has MingGW, which is the Unix Windows, I don't even know what it's called, Minimalist. Windows GCC compiler? Something like that. It produces a Windows binary, basically.

So there's a Docker image for that, and it was pretty slick. You could just point it to your directory with your make file, and through Docker it would just spit an exe out on the other end, and you didn't need anything at all. I've seen some things like that, too, for projects out there where normally you would need to get a lot of pieces together and just put them in a Docker and release it. But I haven't come across it yet.

It's not in my personal workflow yet. I increasingly hear about it, so maybe I need to spend more time looking into it. Same here. Is there a preferred term for programmers today? Do you prefer programmer, developer, software engineer, etc.? Do you think there are significant differences that go with the various terms, or are they roughly

interchangeable? From Mark. Do you want to answer their question first? I have an opinion. You go first. Oh, you have a strong opinion? You definitely go first. Okay. My strong opinion is I don't care which you call me, and I will argue to anyone for a very long time that they all mean the same thing in general vernacular.

So people tell me all the time, software engineers aren't engineers because, insert whatever statement, this was making the rounds like a month ago on the internet. Fine, whatever, I don't care, sure, call me a developer, call me a programmer, call me a coder, call me... Yeah, it really doesn't matter. Occasionally there are terms which have more or less connotation like typically coder is a little more like someone said code slave oh no no no so like coder is more like oh you don't do programming you don't do software engineering it's like coder is a maybe a little more connotation that way and like software

architect is seen as a little you know different in some places, these things do have meaning. Right, right. But universally, these things don't have an actual agreed upon formal definition. And there's no certifying body that says you must have X to be a programmer and Y to be a software engineer. And if you have a degree in computer science, does that make you a software engineer? Like, no, it doesn't matter.

It's like currencies. Imagine every company as being their own country with their own currency and having, you know, being an architect might be like having a thousand dollars in some currency, but you have no idea what it translates to in, you know, Euro or US dollars or something. And so it's kind of... Yeah, so many companies, for instance, for software architect as a good example, that's a very senior person. They report to a high-level manager. They're many years of experience,

and they're brought in as kind of like when they say something, you should kind of do what they say, like that kind of recommending person. And other companies, it's just a different role from software engineer where you spend a little more time on requirements and designing the system. And you're more what some places would call a systems engineer.

And they start junior engineers in that position. You can be a software architect right out of school. Interesting. So, yeah, no. They don't mean. Someone asked me on Quora. Someone asked me to answer, does it matter whether you are data scientist or software engineer? And even there, I mean, clearly there is a difference. But there are so many people who

have the wrong title or not the wrong title. There's so many people who are spending all day doing statistics who are software engineers or spending all day building systems who are data scientists, that separation hasn't happened yet. You may use it to mean something, but you can't guarantee the person on the other end. Exactly. Yeah, also means the same thing. So you should be really careful. I did find one place where it really matters, and that is the immigration office.

Are they going to say the payroll. Yeah, not first hand. But I've heard from several people who wanted to be data scientists because it helps you in the immigration department. But I would say that's, if I had to venture a guess, and I know nothing about the immigration process. Not me either. But if I had to venture a guess, I would say that's just because it's a newer title, so it's less overloaded by people. Possibly.

Anyways, next question. My degree allows me to focus on one of five fields. Software development, web development, information security, networking, and database management. What are your takes on the future applicability and in-the-field work environment for each of these from Shadrach?

Do you want to go first or me? You thought about it. I'll go. So software development is mostly what we talk about here on this podcast. It's what I would say of these categories that Jason and I both do. And of these, right off the top of my head, I would say it's probably the most in-demand, at least of where we are. That isn't to say that you're guaranteed to make the most money because some of these others I think have more variance in the

numbers. Right. But I would hazard a guess that it's the, if you want to talk about salary, the highest average salary. Software development. Software development. Yeah. I would argue that. It's also the one on here that, you know, you know a lot more about what you're getting when you get someone who does that thing right um so then we can talk about web development web development can be anyone from doing software development in a web-based language so think about like the person who's writing the facebook like the facebook.com that website right that's not just html displaying i mean there's a huge application there's hundreds and probably thousands of people working on that.

I mean, can you imagine how many lines of JavaScript that is? No, I don't want to think about it. It's probably millions. And so I guess it used to be PHP too, right? But web development there is very hard. But I think a lot of times if someone doesn't say software engineer or software development and they say web development, they can be using that word to say,

to try to claim something a little more. It can open themselves up. I do CSS and images and mock-ups, and I'm a web developer. Or there's those sort of build-your-own-website tools, like I think Wex is one. Oh, WissyWig Editor. And so focusing in school, if you're interested in web development and it includes a heavy emphasis on programming, like JavaScript, not necessarily a heavy focus on

HTML and CSS, that's probably fine because you can get jobs doing that. But I would be careful because I would hazard to say it's a little easier to go from software development to web development if that's what you're interested in than vice versa. Information security, I feel, although is related to computers and you do need to understand programming, you don't actually do a lot of programming from the people I've talked to. So information security, they may do a lot of scripting. They may do a lot of sysadmin work. And they do need to be really knowledgeable.

And it's a really hard job to do and really hard to find. And I think here you could get a huge variance in pay. That's right. So if you're a very elite black hat hacker working on tiger teams and stuff, you may make a lot of money or not. I don't know. And if you're just somebody doing sysadmin work but calling yourself information security, maybe not. But the stuff itself is really fascinating to me.

But I don't know how much demand there is or isn't for it. I don't think the number of people working in information security approaches the number of people working in software development. So there's a risk there. Networking, same thing. I don't think this means like programming for, you know, TCP. This means like understanding how to manage networks and managing large networks is very, very difficult and you have to be very careful. And at places like Facebook, they've now said, like, they're building their own custom networking gear and stuff. Oh, really?

They handle, like, just massive amounts of stuff in their data center. Wow. So that stuff is crazy. But, again, I don't know how many people are there doing that. And I'm biased. I'm a programmer. I think, yeah. Anyways.

Well, another. Oh, what was that? Was there another one? Last one is database management. Oh, okay. And so I was that? Was there another one? Last one is database management. Oh, okay. And so I think that's a very specific niche and very important and probably very highly paid in a lot of circumstances. I think so. But I would imagine harder to find a job than just software engineering.

Yeah, definitely. Yeah, I actually. So everything Patrick says is totally right. My very short answer would be do what you want to do. I mean, if you're really passionate about any of them, follow your passion. All of these are, you know, well-compensated jobs. Doing the one you're most interested in will probably lead to a better result because you'll be engaged, you'll apply yourself at work,

probably get promotions or that kind of stuff. Yeah, I mean, you know, you have to follow your passion. And you have to be happy. Now I'm not trying to say anything deep there, but very superficial comment. Yeah, definitely. You have to be satisfied. If you're not... Thank you, that's better. If you're doing something you hate, it really, nothing

else matters. You're just going to... I mean, think about it. You're at work as many hours as you are at doing anything else, right? Just during the week. You probably will spend more time with your teammates than you will with your family. Right. Especially if you forget about weekends.

If you just look at during the week, it's definitely true. I mean, you're at work eight hours. Or awake. I should say awake hours, yeah. Right. Oh, you're right. Yeah, awake hours. Yeah.

And then you're doing all this time, and then, you know, you're doing all this time and then there's a, some kind of crunch and you have to work weekends or overtime or something like that. If you're not happy at your job, you're going to get just completely, you know, demotivated and burned out. Um, so, so yeah, follow your passion. Um, someone else asked about, which has become a common thing. As technology replaces jobs, do you see developers becoming like welders, machinists from the first machine age? That's my theory on how we get around the job destruction issue

associated with technology. That's a ward. So, yeah, I talked a lot about this with some colleagues about the job destruction. So is this saying developers will become more important because, like, welders and machinists or became increased necessary because there were more machines? I think what he's saying is... I think that's what he's saying.

He's not saying developers' jobs will be destroyed. I think what he's saying is the whole pyramid shifts. So in other words, maybe, you know, used to be there were tons of farmers. Then there's not as many farmers, but each one is basically a mechanic controlling, you know, the machines that are harvesting the wheat. And so the pyramid kind of shifted. The farmers got dropped off the end of the pyramid. And now what we now call farmers is really a different job. And so I think what he's saying is it will shift again. And then, you know, developers will become many more developers will happen because so many things will be replaced with developers.

And then maybe there'll be, you know, another thing. So I think, um, in general, um, this is kind of, it's a little, kind of a little macabre, I guess, or morbid, but, um, you have these massive, uh, shifts all the time historically, right? You look at say the industrial revolution, right? Tons of job loss, right? And typically what happens isn't very pretty. I mean, historically, you have, you know, massive job loss, then that causes massive income disparity, and then that causes revolution. And so if you look at like the Chinese revolution, the French revolution, a lot of these are because of massive job loss. So that paints sort of a dark picture for the future with, you know, a lot of this robotics and things So that paints sort of a dark picture for the future

with a lot of this robotics and things like that. You hear about if Uber does self-driving cars, all taxi drivers are out of a job and things like that. I do think that we have a society now where people can be much more fluid. We obviously don't have the same caste system as they did in the medieval times and things like that. And I think people will adapt.

And I think it will cause, if there is, and I'm not saying it's a guarantee, but if there is massive job loss because robots replace humans at a large scale very rapidly, I think you'll see adaptation. And so I feel hopeful. I don't really have a strong opinion. I mean, I hear the arguments.

This is one of the arguments for universal basic income where everybody should just make X amount of dollars because we're all going to... I think that's... Yeah, there's a lot of opportunity for deviations from that course between now and then. And I think it's really hard to predict the future. But I would say as far as like developers themselves,

like I don't see a future where we become less needed. Like all of a sudden there's massive developer layoffs in total. There may be in little areas or companies or sectors or if they're market tanks, right? But in general and long-term, I don't see it going down. Same thing healthcare. I don't see there needing to be like less nurses. Nurs nurses may be like less compensated i can't say but like i don't see like we're going to just suddenly need less nurses and doctors right right definitely

maybe if robot nurses you know who knows all right uh you should try quine relay and tis 100 steven so we were referring to earlier about assembly, because this is TIS100. So we did do... I'm pretty... Oh, no, actually, we didn't. We didn't... The two of us talked about the Quine Relay, but we didn't put it on a show yet.

Oh, okay. So very quickly, because it really deserves its own news segment in a future show, but Quine Relay is the super cool thing this guy wrote where you take this ruby program and um when you uh when you execute it it generates a program in another language and when you execute that it generates the output of that is another program another language and uh it it actually goes through, I think, 30 languages

and comes back to Ruby looking exactly the same. It's kind of mind-blowing. That's kind of crazy. Yeah. And TIS 100 is a game in which you need to use assembly language for a made-up processor to kind of solve the game. I haven't played it yet. I actually have this as something I intend to try very soon.

I'm in the same boat. It came out on iPad recently? It did. I actually replied to Steven at the time, and I said, you know, if it's not out on iPhone or iPad or some type of mobile device, it's going to be very difficult. I think it came out on Android and iPad, so I intend to try this.

I don't know how typing it. We'll definitely do it, Steven. This is like my day job. I don't know if I want to do it. We'll do it for Steven. Okay, all right. I don't know how typing. We'll definitely do it, Stephen. This is like my day job. Like, I don't know if I want to do it. We'll do it for Stephen. Okay. All right. I was wondering if you could talk about editors or just about what you like to use and why.

So let's just, we're going kind of long. So like what editor do you normally use at work? I use mostly Emacs and IPython Notebook, which is I guess now called Jupyter. Oh, I didn't know that. So. I use Eclipse. Actually, I use Eclipse for Java, but I use Emacs for everything else. I use Eclipse for Java and for C++.

Really? Because I'm a glutton for punishment. Mostly because that's what is offered at my thing. But I like a lot of what an IDE offers. And I know you can do the same thing in VI. Like, for instance, I don't use Emacs, but I can jump into VI and do what I need to do. I just never – You have to set up G tags and do all that.

You have to learn a lot. Yeah. And the problem is if I go to someone else's computer and they're using that, I don't know how to use the way they have it set up and they won't know how to use the way it's set up. And so a lot of what I spend happen to spend. People always look at me funny. But I spend a lot of time at other people's computers for some reason. Really?

It's the thing like you said, like teaching or whatever. Oh, right, right, right. Debugging people's stuff, having conversations. So like I like to be able to go to their computer and not be like, ah! Be productive. Yeah, so like maybe that's just me. Maybe I'm just a weird person. But yeah, I use Eclipse. You can hate on it, whatever. I don't care. I've actually never

tried it for C++, so it could be great. I'll have to check it out. It's not great, but I mean, all of these tools, this is really hard because there's all these sort of bits and pieces that are moving. The IDE at least keeps it consistent. Does it have, like, the, you know, where you can command-click on a function and it takes you to the definition?

Yeah, F3. You push F3 and it takes you to, like, the variable definition. In C++. So it must do some kind of, like, preprocessing or something. Yeah. So it works pretty well, and I like that. And when I go to someone who's using VI Remax, I think I can't stand in this main ABU, So it must do some kind of preprocessing or something. So it works pretty well, and I like that. And when I go to someone who's using VI Remax,

the thing I can't stand in this main IBU is when I say, like, where is this defined? And they open up a thing and do a grep across the code base looking for the thing, and then they can't figure out where is the definition versus use, and that annoys me. Yeah, they have to set up gtags. If you are doing that, I'm sorry. I don't feel you have an argument to tell me that I'm doing it wrong by having an ID. If you have it properly set up, you know, C tags, D tags, whatever, like, fine.

Oh, that's what it is, C tags. C tags, like, oh, I didn't. That's the one I know. If you have C tags set up properly and you want to make the argument that I'm inferior, fine. I don't, okay, whatever. No, I don't, yeah. But if you don't do it and you do the, like, oh, I'm just going to drop into grep and look. No, sorry.

Unless you're really good at grep that I've not seen people do where like you can write the regular expression such that it finds the definition, not just the use. If you can do that more of our, do you? That's not how I normally see people. I'm actually pretty good at grep. For a long time, I was the grep my way through it. And then I finally kind of said, you know,

like let me take half a day and figure out C tags and G tag, all this stuff. So I probably offended a ton of people. And, like, half the people just dropped off the chat. Yeah, we went from 40 viewers to 20 viewers. No, I'm just kidding. So, but, yeah, I mean, really all the editors, most of the editors work pretty well. I am not strongly biased in this domain. Me neither.

I am frustrated more by people who are strongly biased. Yeah, I don't understand. I'm self my strongly biased. What a waste of energy. Yes. Okay. Want to know about programming basics and concepts like object-oriented, imperative, functional, and so on.

It would be nice to have episodes about these titles. We covered it a little bit here. But, yeah, it's a good point to, like, have a functional episode or something. Yeah, we should do that. Good job. That's Alex. Alex. That said, oh, apparently we injected something

and out of order these. Oh, that's probably me. Any pearls of wisdom? Any things you wish you'd known sooner? Any recommended resources? You know, perspective from Ari. Pearls of wisdom. Oh, I think this one is supposed to have been Ari.

Anyways, it's fine. I think we got the name wrong, but that's okay. Sorry. Keep going. Pearls of wisdom. To close out the episode. I think this is the last question. but that's okay. Sorry. Keep going. Pearls of wisdom. To close out the episode. I think this is the last question. All right.

Let's do it. So one of my pearls of wisdom is look for good mentorship. I think that's very important. And I think a lot of times people will join a certain job or a certain company, and they don't really know who they're going to be working with. I think a good mentor makes just incredible, incredible amount of difference. I had some very good mentors through the years. I think you have as well. And they've really been instrumental. I mean, I constantly think about sort of what they have taught me

and things like that. And I feel like, you know, software engineering, there's a science to it, but there's also a vocation, right? I mean, there's a part of it that's like carpentry, where there's not necessarily, like, you don't get a PhD in carpentry. I mean, I'm sure you can, but most people, they become master carpenters through just doing it for a long time and having good mentorship. And I feel like people, I don't know if they're afraid, like ashamed, afraid, or they don't want to think about it as a vocation because it requires you know a lot of you know a full education and things like that but but ultimately a lot of it is vocational and having a good mentor will guide you especially in the first few years i don't know that

i having a good mentor at some level is important but you know when you think about like at least the stuff i've seen in the schools people can become master carpenters on their own but a lot of times they do they go and they learn the techniques and they may move past those techniques but like they start out learning this is how you plane an edge of a board to be straight and you know the same basic like this is the construction technique to get to this end goal or whatever but i'm not sure the same thing happens like i feel like coding is just so different like the order i would program something is gonna be very different than the order you would program it not just like start a new project what do you do first but even just like here you need a new class to do this like what do you do

first do you write do you go and do the variables first or do you define maybe that stuff doesn't matter but it does because that's how my brain you're describing kind of it more as an art which i think even even if i don't like that argument i don't really, I know what you're saying, and I've heard this argument before. Even then you need a good mentor. I mean, the best artists have the best mentors. I'm just saying, like, there are certain things which are common amongst good designs, like having a design in mind, having an architecture that you can describe. I think trying not to use every last feature of a language just to show off.

Absolutely. Oh, that's the worst. I can't stand that. That's my pet peeve, too. I'd rather you write code that looks like a five-year-old could write it. That's awesome. Yep. And if it works and it's not so far going out of the way because you're not using a feature, great.

Yep, yep. So those kinds of things, in my mind, are very common amongst it. But how you get there is so different. And like now I find in my role, like I tend to review other people's code and like try to say, oh no, but you didn't do it the way I, and then it's like,

wait, hang on. That was a perfectly fine way of doing it. Is it better? Is it worse? No. Okay. That's fine.

Yep. Yep. Totally. Yeah. That's a good point. So other, my bit of wisdom would be, don't get hung up, that's a good point. My bit of wisdom would be don't get hung up on your way being the right way. We talk about this a lot now, but I see so many people that burn out on just raging against everything.

It has to be my way. If you don't use your VI, you're an idiot. Sorry for the strong language. If you don't use blah, oh, I can't believe you did your code that way like only a silly person would do code that way like always try to understand other people's like perspective or where they're coming from or whatever and let it be and also like for me it's a pet peeve there should be a style but like don't don't and it should be consistent but don't get like super hung up about it in like weird ways yep or like if someone's trying to do a little something

non-standard don't like if they have like a good reason for it it's probably just okay yep yep totally um i had another pearl i think i lost it um oh see things through to completion oh definitely yeah do this really easy early on to just be like, oh, I got down to the last little bit of something, and that's good enough. Like, I got to this hard part. I'll just, like, eh, I'll just go ahead and move on. And it's like, no, no, no, no, no.

Like, often that's where, like, the good learning happens because you are really terrible at identifying the easy and hard parts in the beginning. At least I am. Yep, same here. I often misidentify them. The other thing is refactor your code. And a corollary of that is write your code

expecting to refactor it. And so what that means is don't try and solve all the world's problems or the next five years worth of problems at your company right now because it changes frequently. You're not really going to get it right anyways and you're going to waste a lot of time, right? The flip side of that is...

That's a delicate balance, yeah. Yeah, if you're going to code based on this year's problems, then make sure everybody knows that next year you're going to rewrite a lot of it. I think you have to strike some balance there. Like, another thing I've been trying to do is strike the balance of things which I have more confidence that won't change, I'll spend more time on.

And things which I think are likely to change, less time on. Yep. Like, I'll do them a little more hacky, a little more, you know, rough around the edges and let that be okay until we are sure we want to do that. Yep. And that's a subjective decision. And you should be proud to redo your code. I mean, like definitely don't get – I've seen this where some people get sort of defensive about their code.

I mean, they look at it as sort of their territory, like, oh, you're wiping my name off the map, you know. And it's like I feel like, you know, if your name isn't wiped off the map in five years then then there's some old code that probably needs to be rewritten yeah we have a lot more questions there was more questions in the chat room but I think we're running a little long on time I think we're gonna cut the episode off here but then we can try to answer some in the chat room yeah yeah all right well that's episode 50 50 on the half a hundred a

half a quarter of 200 yeah we could just keep going but thank you all for Episode 50. 50. Unbelievable. 50. Half a hundred. A half a century. A quarter of 200. Yeah. We could just keep going. Thank you all for listening. We didn't have a book of the show or tool of the show. But there are lots of other ones, so check them on the blog. Yep.

Visit our Patreon site. That's right. Thank you for all of you who have done that. Yeah, we got some donations yesterday, in fact. We asked for questions and we got donations saying thank you for 50 episodes and everything. We really appreciate that. Appreciate all of your support. And then if you're

bored like me on your commute, you can check out our links for Audible and get a free thing that's always awesome. I'm listening to one this morning on my way to work. Yep. Yeah, I definitely I'm just getting the account now. We have to find out what your first book's going to be next episode that's right that's right i'll give you advice

show oh really follow it sweet i have lots to do it all right well i think that's a wrap thanks guys thanks a lot oh thanks y'all oh yeah thanks folks the intro music is axo by biner pilot programming throwdown is distributed under a creative Commons Attribution Sharealike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I and sharealike in kind.