Short Coding Videos A Career Booster for Developers

Welcome to building better developers, the developer podcast where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are just chugging right along. We have been actually gets missed a whole lot of bonus content if because you're listening to this. The podcast is preceded and post seeded actually, I guess succeeded by video stuff that we have. We have a little bit. We have extra content all the time out on the development or channel on YouTube. If you're watching it. Hi. If you're not, you didn't see me just wave to you. And we have that content. It's sometimes it's a lot of times actually after the podcast. It's sort of a continuation. Sometimes before we get into very different stuff. For example, this time, if you want to learn a little bit more about what the heck is Twilio, we just had a little conversation about that. And check us out, like I said, YouTube, developer.com or check out the site and then you can go there. As always, or if you've never been here to introduce myself, I am Rob Brodhead. I am one of the founders of developer also known as building better developers. That's its own little story. And also founder of RB consulting, a software solutions group where we do integrations and migrations and things of that nature. You could check us out at RB dash SNS dot com. Enough for that kind of stuff. I will also allow Michael to continue. Michael, go ahead and introduce yourself. Hey, everyone. My name is Michael Moss. I'm also one of the co-founders of developer with Rob. And I am also the founder of Envision Q8, where we help health care and small businesses build integrated web systems or software to meet their needs. And I just realized I haven't even talked about what this episode is going to cover. What we're going to talk about this time is essentially it comes out of the source code for happiness book where we were talking about skills and side projects and hustles and how you can define those in a way that will help you along your career roadmap, whatever your path is. And one of the things that has gotten into specifically is doing shorts, doing video shorts of you coding, which is what we've done. You go out to the YouTube channel, you'll find bunches and bunches and bunches of those where, for example, I walk through getting a Python certification, learning Python, learning SQL. There's a couple others. Using Python to build an API, building a link shortener app. Lots of stuff out there. And I wanted to talk about the mindset of that because it's something that Michael and I were having a discussion. And I realized how much it really is something that I think anybody can do that you could jump in just basically if you've got a phone or better yet, if you've got a camera on your PC, which for a laptop, almost everybody does now, is you just click record or screen record and just put that onto your Zoom call or pick your, you know, you can use quick time and use whatever you want to record stuff. And there's a lot of screen recording things out there. You don't have to have your face on the in the video at all, is just put it, record your desktop or your IDE as you're going through it. And then all you have to do is just talk through what you're doing code wise. Now, you may say, OK, that's easy for you to do because you talk all the time. Yes, some people may say I do. I would argue for a long time with them and then realize that I just spent a lot of time talking. What you want to do, though, is this is I think some of us anyways, we work better just verbalizing some of the thoughts that are going on in our head as we're working our way through problems. But also. This is going to help you sort of explain what you're doing as you're doing, because it's it's good practice, because at some point, even if you're doing code that nobody ever, you know, nobody's like behind your shoulders and watching you code, they may at some point say, why did you do that or what was your thought process or why did you build it in that way? And this is going to help you build some of those skills. Plus, you're going to be able to show off your ability to code in whatever that language or environment is. You're going to have those videos. So now you have this branding that you can start working with, that you can you can include it in blogs. You can point people to it. You can use it as a sort of like a lead magnet kind of thing. If you could have just like a lot of people do, you can have a a YouTube channel that you just record yourself doing various coding tasks. It's also useful from a reference point of view. If you're going through and setting up, for example, a server, this one of the things we've done a lot where we get out on Amazon, grab an EC2 instance and go install a LAMP stack. We've done it several times. We've got notes on it. I've searched and found them and reused them multiple times. We've built scripts around it, something like that. If you've got a little video that you did, then you can walk through there and go, OK, that's right. I did this. I did this. I did this. And it's it's an excellent reference for you. So I highly recommend in a general sense, try recording yourself writing code and talking through it. Worst case, when you get done, you don't have to publish it or anything like nobody ever has to see it. However, I think it's valuable. Now, as I mentioned earlier, I've talked a little bit. So let's start with some questions from Michael, because I know this is you sort of prompted this conversation anyways. So throw me some things of where you'd like to see this go. Sure. So what kind of prompted this whole discussion was I've been. Working on retooling my test driven development tool, my code generator into multiple languages, and I've come to the conclusion that while it's very useful in Java, it's not quite as scalable to quickly generate frameworks in other languages from the Java from my initial approach, because the initial approach was, hey, I want to hack something out. It got really useful, but the code's dirty and it's a bit dated and it needs a refreshment. So it's like, hey, I'll go to Python. You're like, oh, yeah, hey, I've got all these Python classes out here. Just refresh your memory with that. So I started going through those and I know we've done a lot of classes, a lot of recordings. I've done a whole series on test driven development and testing. But coding to me to record the small segments you did, which was really cool. However, when you're doing something like that, how do you get it refined enough to where you have, OK, here's the approach I want to do where you're not spending an hour or two for a 15 minute video. Do you essentially script it out first or do you just do it once and then come back, refine it in your mind and then record it like. Like, do you actually like code it once, then stop and then go back to and record based on how you went through it? I feel like I'm giving away the magician's secrets here a little bit. Actually, I most not most some of those were 15 minute videos. It took me two hours of recording and another hour of editing to clear them out. What I do, this is an approach that I take is one I come I come into it with a. A small section of work I want to do that's like, you know, I want to I just want to do an example of this kind of code or tackle this little problem that and it's usually that I think is a little problem. Sometimes there were these multi-parters because I thought it was going to be quick. And then I realized, oh, no, I'm going to have to show some other pieces to get to that. So it's going to have to be a two or three part series. But those were usually done usually in one sitting, essentially. And what I do a couple of tricks of the trade. As I sit down and I start into what I'm going to sit down and do it. My first little bit, and you probably notice, is usually cleaner because it's basically my first minute or two, I'm saying this is what I'm doing. This is my goal. One of the things that I did for the shortener app that was actually very helpful to me is I had a little markdown page that you know, the standard project notes that you see that gets generated out of GitHub or something like that. Well, I went in and the first thing I did is I said, basically did like a I did actually an episode of generating requirements. And so what I did is I did it was in a very a really fast and loose, quick kind of way. But I said, here's the requirements for my application. And the way I did is I set up a bunch of bullet points of I'm going to have to do A and B and C and D and did them in ways that were broken down so that I was like, I should be able to do these in 15 minute, you know, 15 to 20 minute increments. Because that's there's no magic to that time. It's just that's what I've found. I like that works best for me as far as me generating it. Nobody's ever complained. So that's that's worked well. And it's for me, it's in then it's a a bite size thing. So somebody searching for a specific solution. How do I do X? I've got something that doesn't take them three hours to figure out how to do that thing. OK, so to tack on to that. So that was the first part of this. Now, the second part is I noticed when you were going through some of these, you had a particular environment, IDEs, set up, whatever. Is it better for our listeners if they want to do something like this to do it generically with like notepad or a text editor and then use the straight up compilers to try to enforce the environment set up that you want to use or what you're teaching? I would not use the compilers and text editors because it's just this is because it's the this century. It's like nobody that's and that's honestly that's a conversation I had with a couple of guys not too long ago that had just come out. I mean, these are degree computer science, degreed guys that they never saw an ID. They didn't know what an ID was. They could barely spell it when they graduated college. And then they get into the real world. And the first thing that happened, the one guy he was I was his first. The first thing that happened, I said, here's here's a couple of IDEs that you need to to install. Here's the plug ins you want to do. And he it took him a week to get going because he had to he had to Google. What the hell is this stuff? And we talked about it. And it's because as soon as you get into the real development world, you're not you're going to use an ID. Now, granted, if you if your content is ID specific and it's it's very easy. It's very hard almost not to be because whatever your language is, there's almost always going to be at least two or three major IDEs. If you're Java, there's like IntelliJ. There's Eclipse is still out there. There's actually multiple flavors of Eclipse. And then there's Visual Studio Code. And then you get like Visual Studio. There's. Take your pick, but I think it's better off to to give examples that are to do it in a way that like this is me working. Now, if you want to do it as a as a training material or something that is there's more of a class and a course, then I do I do like that. I mean, I've always started whatever the languages I did. I'll start with command line. This is how you run it from the command line. But I will usually very quickly, like within the first week of material, switch over to an ID because you really don't want you're not going to be sitting in an editor. You don't want to be doing some sort of weird command line debugger. You want to have a full blown ID. You want to be able to debug it. You want to be able to run it as easy as possible. And so. I would pick an environment that's comfortable for you, particularly in this case, is just because you're essentially going to just click record, do something that is comfortable for you and then start going. And that's what I did. Now, I I did tweak, I think, depending on what I did, I did select the the ID based on my task at times. There was one that I did a while back that was all on Cloud nine. Amazon's it's the you know, the mobile it's basically Eclipse again, it's the mobile eclipse ID and wanted to make sure see if I could do that to actually go through and see if that actually worked as a full blown ID. You know, spoiler alert, it did. But this goes back to sort of that first question. Get yourself something that's comfortable, because you may end up where I did this. I'll be coding along and I think this is good. And what we always do, we hit a bug. Something's not working. And so what's fun and like this, what I do is I would I would go in and go, oh, here's a bug and be something like, oh, this isn't working right. And usually I give it about one attempt. And if it looked like I was going to need to take more, then I would just shut up. And so when I'm watching the video, I'll have like my little, you know, I can see the audio line and then suddenly it flatlines for a while. And then I would always come back and I go one, two, three or actually, you know, surprise, you know, guess it's not a secret. I go three to one. And then I could see the, you know, I could see each of those little hills. And so I could see when I saw three hills together, it's like, oh, this is me coming back in, because what I do is I go through, fix it. And then or, you know, get through that bug and then say, OK, where was I at? And then basically then set myself back up to say, OK, now I'm going to start talking again and move forward like that. Like one case, I had an hour and a half of trying to track something out. That hour and a half did not show up on the video because I just cut the whole thing out. And it was literally it was like a two hours of video that turned out to be, I think, 20 minutes that I when I finally cut it all down, because I just threw out all the crap. I was just sitting there, you know, like you're trying to figure it. And it's like if you get configuration issues or something where you come back after 30 minutes and you go, oh, by the way, I had the case wrong on this letter or I misspelled this parameter. Then you can edit that stuff out. All right. So let me sum this up a little bit for those that are listening, because you just kind of unloaded all whole package of information. So my initial idea or question was, how do you break down your recordings into smaller segments? For those that are new. You kind of want to go into it, just hit record, start doing it, but do it in an environment or in a ID that you're comfortable with so that you can just kind of flow, get used to it, do it a couple of different times. For those that are a little more advanced or you're getting a little more custom, getting into a more course driven. Typically use something that you're comfortable with, but would it not be safe to say use something that is a little more industry standard, like visual code or at least something that's more exposure for what people are used to seeing or might see in the industry. So you don't want to necessarily have them go show them something like maybe Cloud 9. That may not be as useful today, but like visual code is or like PyCharm. Regardless, but take a look at where you are today and what's available and make sure you're doing something that's generic enough that can kind of stay in the test of time release for a couple of years. So you don't have to go back every year and keep rehashing your videos if you're doing a course. The second part of that was, it was interesting. So as you kind of laid out your courses, and you and I have both taught multiple bootcamps, software classes, and things like that. My favorite approach, and I kind of want your take on this because I've seen you do it different ways, is if I know that I'm going to be teaching X or I'm covering this topic and it has code, I typically like to put together a empty file with nothing but some comments in it to basically fill in the gaps as I go along. That way the user see what's there, I have placeholders, and I don't have to jump around a bit. What are your thoughts on that? I have taken that approach at times. I find that it's a little... It takes a little bit extra time to actually build out that recording. So what I'll usually do is I'll do it like that, is I'll have comments and I'll build out all the code and then I'll have comments around the code and then sort of walk through the file as I go. Sometimes it's actually stuff where I'll have like spoiler alerts in the code because I'll have stuff that I haven't covered yet. And I'll say, oh, by the way, we're going to come back to this section because that's also something you run into is particularly if you're building out a language. Like when I was doing the Python certification stuff, there were cases where I treated it as if you haven't seen Python before for the most part. I mean, it was like wasn't perfect, but it's along those lines. And there are cases where I would build a little applet to cover a topic and there would be other things in there. And it's the obligatory, hey, we'll come back to that later kind of thing that you'll see in almost anything. You know, it's even, you know, if you go back to like calculus professors, you're like, well, we'll leave that up to the student to solve that problem or something like that. It's something where it's like, hey, just for now, trust me, because this code works or you can use this code and then we will come back. And usually I'll even mention that or I'll take a note as well that, oh, I need to cover this topic in this section of coding or something like that or have some sort of callback so I can say, hey, we're going to talk about this in the collections topic or whatever it is so that while you're looking at it, you don't need it right away. It's sort of a trust me, this is solving this problem. Just go with the code that we're giving you in this area and then reference to, if you want to know what this block of code does, go check out this other topic or something along those lines. And it's also as good to like you throw stuff in the show notes or something like that. That just is a link back to, you know, episode one where we covered this or those kinds of things. To kind of tack on to that, the other thing that I like doing with something like that is I like kind of doing like a student copy of a project, which is just a very structural, just driven project. Like here's an empty project with the files that we will build with the comments in them. So as I kind of go along through the lecture, they already have that. They don't have to spend the time building that. But then they can kind of follow along and fill in the code, try to, you know, make it work. As I go through the lecture, the other thing that I like doing with that is I also like providing like a student handbook. Like with that also, so you have the student handbook, but I also give a student workbook. So on top of that, I give like a little lab section for homework assignments and that. That basically is a big comment to go with the PDF and they basically go in and they have to like do the work, fill it in. Then when I'm all done with the lecture, I essentially dump out to GitHub. I'll open up to the group. Here is the student solution to that project. I kind of like to wait till the end and so dumping it at the beginning because you want to make sure that they work through the assignment. But for those that are trying to do their own projects or their own ideas. What do you think of that? Do you think they should give it away with GitHub or do you think they should keep it proprietary? Me personally, I like GitHub for one of two things. One, and I know I kind of ask you that, but I kind of want to give my two cents on that. But one, I like to get a hub idea because it goes with what we've talked about previously about building that roadmap. Where do you want to go? But also you're building your resume with, hey, I have experience in this. Here's examples of what I've done. And now you have an online profile to go with that. But you got to be careful though, because if you do put out in GitHub, if you do it public, people can make changes to that. You could get in trouble if someone comes in and screws with your project and you say, hey, take this out and an employer or someone comes and looks at it and your code is a hot mess. Anyway, you can block that. So you can't. There are ways you can block it. So people can't fork your code and stuff or they can only do it if they fork it and things like that. So there are ways to so they're not going to screw up your code. Plus you have a you have a GitHub history. So what I've done with a couple and I do like using the GitHub approach, I like to just what I do is I build. The last couple of times I've done it, I build as I go. So I start with a public GitHub repository and then one or two episodes into it. I have committed code into GitHub and then I give them the link and say, here you go. And then I tag them as I go so you can go and you can say, you know, here's episode one, episode two or class one, class two, class three. So they can go in and they can pull based on that label. They can see what's there. And then it's if nothing else, you can you can pull the prior version and then you can sort of work along as I do if you want to pull the code in. And so it's and it's again, this isn't aimed at like a quiz or something like that. It's more of a hey, watch the video. You're going to get an explanation of what's there. You can skip to the end and just grab the code, but then you're not going to know what the code does unless you watch the video or read the whatever the documentation is and things like that. So I do find it very useful. And then it gives you an excuse to have a public GitHub repository that people can check out your code. They can and then they get the best of all worlds. They can see you coding. They can see what came up after the fact, what the final results are and really get a feel for who you are and how you how you develop. Perfect. Before you get I know we're getting close on time. So I got one final thought for you. So if we're building these short courses or we're building out a kind of road map or a structural content for our listeners, as you're building your GitHub or your markdown language, is it useful to think about using things like ASCII docs or some other type of documentation that as you're writing kind of the read me's or you're scripting out these classes to kind of generate an ebook format as you're building it. So when you're done with your presentation, you essentially have this free ebook you can hand out with it. It can. It depends on what your goal is. If you're if you're trying to build a course, then yes, I mean you want to do that. You're going to want to really have a there's a lot of those pieces you're going to do like you're going to want to include unit tests and things like that and like build it out. Or if you want to show off your your total skill set is cover all of those bases. If you're just wanting to show your little like vignettes of you coding, then I don't know that you want to go that far. This is it's one of these things that gets into scope. It's like really how much do you want to get into this? Do you want to just show solving a problem or do you want to show off solving a problem? And it's it's the kind of stuff is like do you know, do you want to add like a presentation and all these things around it? And you really just want to be like, hey, here's me writing code. And if you do always use those tools, then by all means incorporate those in. But if it's something that you normally don't use at all, then one you can decide you're going to do it with this project to give yourself exposure and experience doing that. But two, watch out. You don't want to get into something where you like, you know, go all out and you say, here's how I code and you've got all these really cool things and these really high end things that you produce. And then when it comes down to what do you really do, you're writing, you're just cranking out code. Then there's going to be that disconnect. And it does help. You know, if you want to do the whole thing, if you want to do the really well polished code, then by all means do so. But just make sure that you're going to follow through with that and realize that that changes when you go out and do projects and you use those as references, that changes what people are going to expect of you. And you want to make sure that you are not setting false expectations when you put these things together. It's all it's one of those things that's really in it. I guess one last thought, because otherwise we'll go really long on this. Don't put yourself in a situation where you're doing these little things and you're over architecting the snot out of solutions and doing a lot that you really don't need to do. Yeah, it's great. It's it's cool. It's in some cases you will say the sort of the right thing to do or the right way to do it. But in a lot of cases, it's not if you're dealing with somebody that's just trying to get a project like an MVP together, then yeah, they're still going to need documentation. They're going to do some testing. But you don't you're not going to go all out with those because you're not going to have the bandwidth to do it. So you don't want to be in a situation where they say, hey, we need to build a simple landing page and you say, oh, yeah, I can do that. It's going to take me three months to do it because there's all of these other pieces that I'm going to build into it is I just be careful of getting too. And enamored of technology and some of the tools that are that are out there. But if you can use stuff that's part of your process, then by all means, do so. And I'm not going to give you the last word because we've gone a bit too long this time. So we're going to wrap this one up, but there will probably be bonus content hint hint after this. For those of you who are listening, feel free to check us out. Subscribe. You can shoot us an email at info at development. Or dot com. If you have questions, comments or do you want us to take a look at some of the videos and code stuff that you've done or if you have suggestions for what you would like us to do, we're happy to help you out. And if you do, we'll do a lot of that. So thank you for listening to this. I hope you enjoyed this. And if you have any questions, please do not hesitate to ask us. We'll do a lot of that. And if you haven't already, please do so. We'd love to hear what you think. And if you have any questions, please do not hesitate to ask us. We'll do a lot of that. So thank you for listening to this. We'll see you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. Thank you.