Transcript from the "Portfolio Checklist" Lesson
>> So now let's look at this portfolio checklist. Now I really want you all to go, especially for those who are looking to push thing live to the web and back in engineer. You two over here, there are some things in here, they're very important to you, right?
[00:00:14] So we have the most obvious, the first one where we're talking about, I'm using clean code, your code. When I say clean code, what I am referring to, particularly if you're using a framework or something is your code needs to be maintainable, readable, scalable. What that means is that when I talk about, when I look at your code, I'm able to buy the naming conventions to have some idea of what that code can do.
[00:00:45] Maintainable you're not having all your code, you're not having a 500 line file, of course it does four or five different things. This file has not the code for it to do one thing and one thing well and to be brought into another place. Be able to be utilized elsewhere in other parts of your code base, right?
[00:01:08] A maintainable, so when I say about maintainable, alrl ight, let's say it's backward. It needs to be backwards compatible or it needs to change to some way like that. You've written it in a format to where if I add a console log or make a change somewhere, it's not gonna break your entire code piece, right?
[00:01:27] So think of it as conceptualize it in the format of how React components are done, but everywhere that ideology that react has with the components was actually my first time seeing it was not in React but was in Rails. They believed a lot of real good rails devs they believe that you're code should be small your code do you wanna be in one file.
[00:01:52] They were like, shouldn't you be more than one program to help me shouldn't be more than like 30 lines of code in that file and that coach only do one thing well, and then you make those files or files or CO work together. Think of this function, does one thing as all the things supposed to do.
[00:02:39] [LAUGH] Yeah, so we helped you.
>> So, kinda segregation of concerns, yes, separation of concerns. [INAUDIBLE] log in, might have one little piece just was logging into the Program or
>> one thing doing just a little bit of logic another part so if it's login let's say for instance you're off and login section your office section is for logging in.
[00:03:03] And you have you want to use multiple different ways logging analysts so you wanna use apple you wanna use Google and Facebook I guess those are big three right? People use Apple, Google Facebook for authentication, right? So you have that file, there handles login, but you also handles those three they haven't clearly named or showcase which one it uses.
[00:03:26] Here's apple off here is Google off here is FB off and which parts of authentication trailed is that it's focusing on and you're just using those functions as needed right but that one file does that. So that's what I mean by clean, clean code, right? Yes, Ma'am.
>> Could you speak about the scalable piece of that?
>> Yeah, all right. So scalable essentially what I mean by that is you're able to make you able to make the work scale, you're able to make the, you've written your code in a manner that where you can expand it, make it larger, like say
>> He's off once again in his piece of off code right let's say there is a new form of authentication he wants to add.
[00:04:13] Let's say he wants to add WhatsApp for to FA or or just or another two FA authentication format for his authentication. Now we can scale it, we can extend that to add this to f a factor for it to sin, a sin it takes if a user chooses to send a text message for this piece of code.
[00:04:34] Here we go right here, but that's still in its authentication. But it's two factor like it's a new, it's a new feature that he's added within this code, right? So that's what we were referring to making it scalable. Using version control, now, when it comes to learning how to code, people use GitHub to just to store their stuff.
[00:04:54] When it comes to learning how to code professionally to a job, I want you to think of using version control as a magnifier and amplifier for your career. All right. So what I'm saying is this is that one, you should find someone to collaborate with anyone that you'd be on your level it'd be a little bit higher does matter but have someone to collaborate with.
[00:05:20] Two, what you should be doing is when you're doing your version control, you're your primary branch, anything new you're building. You're going to check out a new branch and you're going to build your feature on that branch Then when you push that feature branch up and you're done with that feature, you're going to have the person that you're collaborating with do a PR and They're going to review your code And then only after they look at that code and say that is good.
[00:05:51] You're going to put that back into your feature branch I mean to your primary branch. Now I know you're thinking that is a lot of work for free for you know for free when I'm not doing us on a project and I'm that I'm not going to pay it off.
[00:06:05] See, that's exactly the point. You want to show that to an employer that you already have these practices in place, right? And you don't have to do that on every project. You can do it only on your portfolio right where that's where they're gonna be looking at and viewing the most and you wanna that's where you wanna show all of this height of like your work you want to show this.
[00:06:27] Project border how I plan this portfolio you wanna show this form of how I've done this then the theory, you wanna show these these PR branches and all of this like collaboration, so that way when you say it. They can see it and, you know, they you know it, that connection.
[00:06:44] This person did see on their resume, they collaborated on this and they've done a lot of PR and things of this nature. And they pull tickets and created issues. I'm like, wow, you did, this person did all this, okay. So this person actually knows how to code and as a unit with other people.
[00:07:02] I like that, that's nice. I wanna hire this person at least talk to this person, right? That's what you want, right? So, yes.
>> So I'm kind of curious. Are there any projects that are, like, it is worse to do them badly than not at all if you don't check off all these boxes on, like, good Git.
[00:07:24] Good habits or this project is like a little bit messy in the code base.
[00:07:46] That's what it's focused on. It is not a project that is designed to be on your portfolio, though. That is a skill builder project, right? Not a portfolio project. What I would consider a portfolio project is like making a miniature. Like,you know, social network or making a small like Markdown editor of some sort, right?
[00:09:01] So you're using Azure, you've pushed a chat bot to your to your website and you have so you have a chat app on your on your website, you know, using psycho node. And you know Azure or AWS or ledger gave it a handle on that data so now that is a project that you can look small but you can actually talk about on your portfolio because You have its push live, it's interacting directly with users, and you're showcasing like solving a problem, right?
[00:09:38] I used to have a chatbot on my first project using Socket.iloin node because I wanted to be able to talk directly to people that went to my portfolio when I was like 2015, 2016. I want to talk to them directly. If they had questions. And I knew that if someone saw a chat bot bubble that clicked that bubble and if they wanted, they would see if it would work.
[00:10:01] And then I'm like, Hey, how are you doing? I'm actually doing this. I would even take pictures and upload it where I was at at the time just to show people. so that you know this actually works right so like that is where you know that's where the you know the thinking of projects comes into play