Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we continue the great developer mindset series. Today we're talking about redefining complete. This series is dedicated to guiding you, the listener, the listening developer, regardless of where you are in your career, towards the mindset of the great developer. My job on this podcast is to help provide you with the tools, the insights and the inspiration you need to shape your career as a developer. It becomes truly great at what you do. Today's episode is sponsored by Hired. On Hired software engineers, project managers, data scientists and designers can get five or more interview requests in a given week. We will talk more about Hired later on in today's episode. But first, let's talk about what it means to have complete code. This happens all the time with developers. We get tasks assigned to us in whatever task management system we are using and we go and we write the code and we check it out on our local system, whatever it is that we're building, we go and look at it real quick, we push it up and then we mark it as complete. And the reality is that this marking as complete is only marking one part of the process as complete. And truly, any great developer will tell you that completion is a series of things, not just simply writing the code, but a scale of things. There are multiple levels of completion that make up truly complete code. And we're going to talk about those multiple levels today, but I want you to understand the importance of today's episode, the importance of this concept of complete. Because if you view completing a particular task with code as a simple write the code and push it and it's done, if that is your metric for complete, then you're going to systematically have problems, right? Number one, you're going to underestimate everything that you do. That is a huge issue. You're going to underestimate everything you do because you believe that it only takes writing a little bit of code and you have that code already basically planned out in your mind, so it's not a big deal, right? We think that completing a particular task is not really a big deal because we can write the code and push it and we're done. And that's simply not the case, but if we think that it is the case or if we have ingrained into our brains by practicing it that way, if we go through those motions, if we think, well, I'm basically done with this, I just have a few other details to tie up before I'm totally done. If we think that way, then we're going to, again, chronically, systematically underestimate the work that we do. Not only will we underestimate, but we're also going to undercharge for the work that we do. I don't want to hang on this subject for too long because everybody has a different way of understanding this subject and it's easy to swing the total opposite direction and way overcharge for your work and way overestimate for your work. But it's important to understand that completion of code is not simply completing the code and that if you think that it is that, right? If you think that you can write the code and push it and it's done, you're going to have systematic business level issues that may be debilitating to your career. Okay, it is that serious to understand the truth of this message of completing and following through all the way with all of those different elements of completion. Here's another problem you're going to face. If you don't think about completion at every level of the scale, you're going to face so many bugs, it'll make your head spin. And because you've already put yourself in a whole of underestimating, you're already going to be behind. Well, now your client is coming to you putting more stress on your plate because guess what? The code you pushed yesterday broke today. And the problems continue compounding because if you believe that completion just means pushing the code and calling it done, well, now you're going to have issues when that particular client wants to scale. So if you want to be a great developer, then you have to avoid these problems. You have to learn how to estimate properly. You have to be able to deal with bugs before they occur. Hopefully more often than not, right? You shouldn't be buried all the time trying to catch up because of these issues that keep on occurring. And you should be ready to help your client's scale when they need to. Now we're going to do another episode in the future, most likely on this concept of scale. But when I say scale in this particular context, basically what I'm talking about is changing the software, changing the software as the business grows. I'm not saying that the software suddenly needs to accommodate 10 million users. That's not what we're talking about when we talk about scale. We're talking about changing requirements as the business grows. If your software can't do that tomorrow, then what you've built today is going to be incomplete tomorrow. Does that make sense? What you build today is incomplete tomorrow. If you are unable to scale that software at the speed that the business is scaling. And you're going to see each one of these things played out ways of solving these problems beforehand, right? Giving yourself the padding that you need, giving yourself the proper way of understanding what it means to complete code. And we're going to talk about what it means to complete code right after this short sponsor break. Today's sponsor is hired on hired software engineers, project managers, data scientists and designers can get five or more interview requests in a given week. Each of these offers has salary and equity provided up front, which means that you don't have to ask the awkward question of how much am I going to get paid if I take this job. They have full time and contract opportunities. So this isn't just for those of you who don't have jobs. It's also for those freelancers out there who are looking for better contract opportunities. Users can view the interview requests they get and accept or reject them before they ever talk to the company. So there's never an awkward conversation hired works with over 3,000 companies ranging from startups to large public facing companies. And it's totally free for you as a developer or as a project manager. Whatever you are, you can go to hire.com and use it 100% free. Now, before you head over to hire, let me tell you about the special link and what you get. Since you're already getting to use hired for free, why would you use a special link? Well, hired normally provides a thousand dollars of a thank you bonus if you accept a job through their system. But if you use the special link, which is hire.com slash Developer Tea, that bonus doubles to $2000 when you accept the job. That's hired.com slash Developer Tea, you get a double bonus up to $2000. Hired cares about your privacy and they'll hide your profile from your current employer and anyone else you want. So you basically have no reason not to go and check it out. Hired.com slash Developer Tea, and that'll double that $1000 bonus to $2000 when you accept a job. Thanks so much to hired for sponsoring today's episode of Developer Tea. So hopefully I've convinced you of all of the reasons you have to redefine what you think of complete code. But what is complete code? Well, I'm going to give you a couple of different things that maybe you haven't thought of in the past. Of course, writing the code itself, right? Writing the code that accomplishes the task that you've been given. That's a part of completing that code. But there are a few other pieces of the puzzle that I want to talk about today. Today we're going to talk about three specific ones. And if you aren't thinking about these three things, then you are not completing your code period. I don't care what anyone else tells you your code is not complete until you've thought about these three things. Number one is your code tested? Is your code tested? If you can test it programmatically, especially that is a good start. Testing means something different for every piece of code, though. The most important thing here is that you have what are called acceptance criteria or test criteria. What this means is that you have defined the state that your application will be in when this code is complete. All right. So when you can do this programmatically, it's even better. Your your programmatic test will define certain actions and the the expectations of those actions. Go and read through a few tests online. You can read our spec tests. If you're writing Ruby, jasmine tests, if you're in JavaScript, there are plenty of testing suites out there. It doesn't really matter which one you use. But you'll notice that all of these have a particular structure of way of doing things. These test criteria are expressed in those tests. You can write test criteria in plain English, particularly if you're not testing your code programmatically, which I recommend that you do test it programmatically. But sometimes that's that's impractical or that particular language or that framework doesn't have testing really supported. So it's kind of a difficult piece of overhead to introduce testing. For example, if you're if you're building a a WordPress site, it may be a little bit difficult to test that programmatically. So you may need to write out in plain English what the acceptance criteria is for that particular piece of code. Sometimes that test criteria may actually be based on performance like this particular algorithm needs to run at this particular speed. It may also be based on functionality to take the previous algorithm you may need for that algorithm to actually work properly. Most times you're going to have multiple tests to accomplish a single criteria. And there are a ton of things that we could talk about with testing here. But we're going to leave that for you to go and explore and determine what are the best practices when it comes to testing. But if your code is not tested in some way, whether that's manually or programmatically, if your code is not tested, then it is simply not complete period. Go and test your code. Don't ship code until it is tested. You're going to face problems in the future if you don't test your code. Eventually, eventually, you're going to write code that has a bug in it. And then you're going to push that code. And once you push it, once you push code that has a bug in it, you may not know it until down the line. And it's going to be a whole lot harder to track that bug down when you're out of the context of working on that code than it would be to just avoid it altogether in the beginning. Now, don't hear me wrong. Tests do not prevent bugs. They don't prevent bugs. People prevent bugs. Right? And people are fallible. And therefore, your tests are going to be fallible. You're not going to be able to catch every single bug. And your clients need to know that sometimes they will find bugs in software, even the best software companies in the world ship software that has bugs in it. If it doesn't have bugs in it today, it could have bugs in it tomorrow because the environment that the software is running in may change. So it's not the end of the world if you end up shipping a bug, but it's not a good idea to ship software that isn't tested for obvious bugs. If you ship something to a website that takes down the entire site, that's an example of when you should have tested it. You should have figured out that that particular piece of code was going to change that site was going to break that site. Now, we're going to take a quick diversion and talk about environments. If you are testing and you're only looking at your code locally and it only works on your local computer and then you push it up to your remote environment, your staging or your production server and it's broken on the server, then guess whose fault that is. It's not the person who is managing the server's fault. It's your fault. I know that sounds harsh and I'm not meaning to place blame on you or make you feel bad, but ultimately your local machine doesn't really matter. Your local machine needs to be matching whatever that remote environment is. There are plenty of ways to make this happen, but make sure that your local machine, at least in the major portions, the PHP version, for example, on your local machine, you need to be able to set that to the same version that you have on the remote machines. You need to be able to have the same serving environment. For example, if the remote machine is using NGINX and your local machine is using Apache, you need to install NGINX on your local machine. Here's why. I'm going to explain to you why what you're doing. If you write code for your local machine and it doesn't have bugs on your local machine, that doesn't mean it's bug free. Here's why. If you were to try to run Ruby with a PHP interpreter, if you try to run your Ruby code through a Java interpreter, if you try to put your Ruby code into the browser and expect it to output HTML, it's not going to work. The reason is, because you're trying to run Ruby in the wrong scenario. There's virtually no difference in you trying to run your Ruby through a JavaScript interpreter and you trying to run code on your local machine and on a remote machine when those machines are not at parity with each other. In other words, if you're writing PHP for PHP 7 on your local machine, but your remote server has PHP 5 installed, then you're probably going to have issues when you push that code. Now, if you happen to have control of your remote server, if you are running something like a Linode server, Linode is a sponsor of the show. Thanks Linode. If you happen to have root access to that server and you can update PHP to PHP 7, well then great. You can make those two machines have parity with each other. You can make the remote machine match your local machine, but it is never an excuse for a great developer to say that it works on my local machine. That is never a good excuse. If your local machine can interpret Ruby through its JavaScript compiler, then that doesn't matter in practice. That doesn't matter because when you push it, suddenly it's broken, suddenly the code that you wrote that didn't have bugs on your local machine, it has bugs in the real environment that it's running for the user. The user is experiencing bugs. It doesn't matter if it runs on your local machine if it doesn't run on the remote machines. So, once again, number one, for completion of code, it has to be tested. Number two, your code needs to be verified. Your code needs to be verified. What's the difference between verification and testing? Well, your code could be passing all of your tests, but it could be a usability nightmare. Your code could be passing all the tests, and it could still have bugs because you didn't write the right tests. Verification means that not only have you tested your software, but you have verified that the solution meets the user's needs. You've actually walked through all of this processes for the user and using both quantitative and objective means and qualitative and subjective means, you have evaluated that that software is complete. Typically, this involves a bit more human evaluation rather than programmatic evaluation. Remember that passing tests does not mean bug free. I can't stress this enough to you just because you have 100% test coverage and all of your tests are passing does not mean that your code is of good quality. It doesn't mean that it's verified. No tests will cover every possible use case. So verification is needed to determine if the practical use of that code has actually been accomplished. Okay, this is well after you've written all of the code for that particular problem. Writing that code does not mean complete. Once again, you have to test it and you have to verify it. And number three, you need to review that code or specifically, you need someone else to review that code, particularly if you're on a team. If you're freelancing, this is a little bit harder to do. Maybe you can have another freelancer come in on a project or maybe you can have a mentor look over your code, but really you need to have someone reviewing your code. You need to make sure that the code is reasonably flexible for future changes, particularly if you have someone else who has worked on the same project, and especially if they worked on the same project a little bit longer than you, really what you're doing is you're saying, hey, I've written this code for something that you've already been writing code for. You know the system and I know a little bit about this system. Let's both do a cross check on my sanity on the things that I've written here. So if they come in and they say, hey, you know, this is this looks like it's not going to be very flexible for the changes that we're going to be doing in this other part of the same project. Well, maybe you need to change that code a little bit before you ship it, right? Maybe that means that that code that you wrote is actually not complete. Surprise. Once again, we're in a situation where you wrote code that may have functionally passed the tests. It may have passed the verification standards, but because it created a unnecessary restriction on future changes, it needs to be changed to be more flexible. Does your code follow code style standards? Maybe there is a particular style for this project, or maybe you are a junior developer and you have a senior developer looking over your code, and they say, hey, you know, we use two spaces instead of tabs and you need to go through and change all of your tabs to two spaces. Very simple things like that, linting. These are things that can happen with a code review process. Your code could be reviewed by the way by a linter, which is not a human. It's just a process of running your code through and checking to see, am I actually following the code style guides that have been set up through the linter? Does your code depart from the general structure of the project? This is another thing that a code review might reveal. Maybe you like to name your files a particular way, but that doesn't necessarily match up with the structure of the file naming system that the project already had set up. Another question you could ask, does my code introduce any dependencies that are unnecessary or redundant with other parts of the code? If someone has been working on the project for a little bit longer than you, they may say, hey, you know what? That code looks like something else that we did over here. It would be nice if you could catch that a little bit earlier in the process. You might recognize that reviewing your plan is probably a pretty good idea as well. Certainly, you don't want to introduce any extra dependencies that are already solved by a different code package. You don't want to have two XML parsers that do the same thing, but you're using two different versions of that in the same project. That is redundant and it's unnecessary, and it's going to make the project really kind of convoluted into the future. So you want to catch that before you ship it. And finally, when you do a code review with another human, having that second set of eyes will catch bugs that you may have completely overlooked. They may also be able to provide better solutions. Maybe they have a particular experience with an algorithm that they've written in the past that solves what you're trying to do a little bit better than you solved it. Having a code review will reveal these things to you. And it doesn't always have to be someone that's senior to you. It could be somebody that is even junior to you, right? Somebody who has less experience than you can come in and maybe they need to learn from your code, but maybe they have insight as to how you could do something different. So once again, we're talking about code completion standards, redefining the concept of complete. When you ship code, when you send code to the production server, if it has been tested, if it's been verified, and it's been reviewed, you were in so much better of a place than if you simply wrote the code and pushed it up without thinking about it. And you'll notice that testing your code and verifying it and reviewing your code takes more time than it does just to write it. And so you're going to start estimating differently and you're going to start avoiding more bugs in the future. You're going to start writing better software period. You're going to be a great developer if you can adopt this standard for your code completion. Don't send out code that hasn't been tested. Don't send out code that hasn't been verified and don't send out code without having it reviewed. Not only will you have better estimations and fewer bugs from the start, but you're also going to have much more flexible, scalable software so that you can grow with your clients. Thank you so much for listening to this second installment of the great developer mindset series. Once again, this series is dedicated to guiding you, the listener, towards the mindset of the great developer. My job on this podcast on Developer Tea is to help provide you with the tools, the insights and the inspiration you need to shape your career as a developer and become truly great at what you do. Thank you again to today's sponsor hired on hired software engineers, project managers, data scientists and designers can get five or more interview requests in a given week. Not only is hired free for you as the user, but if you use the special link in the show notes at spec.fm, you get a doubled bonus whenever you accept a job through hired. That's a $2,000 bonus by going to hired.com slash Developer Tea. Thank you so much for listening to Developer Tea. I hope that this series is continuing to be useful to you. Make sure you reach out and let me know if you are enjoying the great developer mindset series and until next time, enjoy your tea.