Great Developer Mindset: Redefining Complete

Summary

In this episode of the Great Developer Mindset series, host Jonathan Cottrell challenges the common misconception that writing code equals completion. He argues that viewing completion as merely writing and pushing code leads to systematic problems including chronic underestimation of work, undercharging, and an abundance of bugs that compound over time.

Cottrell introduces three essential components that define truly complete code. First, code must be tested, either programmatically or through defined acceptance criteria. Testing doesn’t prevent all bugs but helps catch obvious issues before deployment. He emphasizes that “it works on my machine” is never a valid excuse, stressing the importance of matching local and production environments.

Second, code needs verification beyond testing. Verification involves ensuring the solution actually meets user needs through both quantitative and qualitative evaluation. Cottrell stresses that passing tests doesn’t guarantee bug-free or usable software, as tests can’t cover every possible use case.

Third, code requires review, ideally by another developer. Code reviews help ensure consistency with project standards, identify unnecessary dependencies, catch overlooked bugs, and improve flexibility for future changes. Even junior developers or automated linters can provide valuable review perspectives.

By adopting this three-part definition of completion—testing, verification, and review—developers can produce higher quality software, make better estimates, avoid more bugs, and create more flexible systems that scale with client needs. This mindset shift is fundamental to becoming a great developer.

Recommendations

Tools

Hired — A job platform where software engineers, project managers, data scientists, and designers can get multiple interview requests with salary and equity details upfront. The platform offers both full-time and contract opportunities and allows users to hide their profile from current employers.
RSpec — A testing tool for Ruby mentioned as an example of a testing suite developers can use to write programmatic tests for their code.
Jasmine — A testing framework for JavaScript referenced as an example of testing tools available for different programming languages.
Linode — A cloud hosting provider mentioned as an example where developers might have root access to servers, allowing them to update software versions to match their local development environments.

Topic Timeline

00:00:00 — Introduction to the Great Developer Mindset series — Jonathan Cottrell introduces the episode as part of the Great Developer Mindset series, focusing on redefining what “complete” means for code. He explains the podcast’s mission to help developers shape their careers and become truly great at what they do, mentioning today’s sponsor Hired before diving into the main topic.
00:01:02 — The problem with marking code as complete after writing — Cottrell describes the common developer pattern of writing code, checking it locally, pushing it, and marking it as complete. He argues this view is flawed because completion involves multiple levels, not just writing code. Thinking otherwise leads to systematic underestimation of work and business-level issues that can be debilitating to a developer’s career.
00:03:44 — Consequences of incomplete code: bugs and scaling issues — The host explains additional problems that arise from incomplete code, including numerous bugs that compound when developers are already behind schedule. He discusses how code that can’t adapt to changing business requirements becomes incomplete as soon as the business needs to scale, emphasizing that great developers must avoid these problems through proper practices.
00:08:09 — The three essential components of complete code — Cottrell introduces the three things that define truly complete code, stating that code isn’t complete unless developers consider all three. He begins with the first component: testing. Code must be tested either programmatically or through defined acceptance criteria, with different approaches for different contexts like WordPress sites versus custom applications.
00:11:32 — Testing limitations and environment parity importance — The host clarifies that tests don’t prevent all bugs since people are fallible, but they help catch obvious issues. He stresses that local and production environments must match (PHP versions, servers like NGINX/Apache) to avoid the invalid excuse of “it works on my machine.” Environment mismatches are likened to trying to run Ruby through a JavaScript interpreter.
00:15:43 — Second component: verification of user needs — Cottrell explains the second component: verification. This goes beyond testing to ensure the solution actually meets user needs through both quantitative and qualitative evaluation. He emphasizes that passing all tests doesn’t guarantee bug-free or usable software, as tests can’t cover every use case. Verification typically involves more human evaluation.
00:17:15 — Third component: code review for quality and flexibility — The third essential component is code review, ideally by another developer. Reviews ensure code follows style standards, matches project structure, avoids unnecessary dependencies, and remains flexible for future changes. Even junior developers or automated linters can provide valuable perspectives. Reviews also catch overlooked bugs and may suggest better solutions.
00:21:17 — Benefits of adopting the three-part completion standard — Cottrell summarizes that code shipped after testing, verification, and review places developers in a much better position than simply writing and pushing code. This approach leads to better estimations, fewer bugs, and more flexible, scalable software that grows with clients. Adopting this standard is fundamental to becoming a great developer.

Episode Info

Podcast: Developer Tea
Author: Jonathan Cutrell
Category: Technology Business Careers Society & Culture
Published: 2016-06-06T09:00:00Z
Duration: 00:23:38

References

URL PocketCasts: https://podcast-api.pocketcasts.com/podcast/full/cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263/a3a20c22-c815-4015-87be-83d95c351534
Episode UUID: a3a20c22-c815-4015-87be-83d95c351534

Podcast Info

Name: Developer Tea
Type: episodic
Site: http://www.developertea.com
UUID: cbe9b6c0-7da4-0132-e6ef-5f4c86fd3263

Transcript

[00:00:00] Hey, everyone, and welcome to Developer Team.

[00:00:05] My name is Jonathan Cottrell, and in today’s episode, we continue the Great Developer Mindset

[00:00:11] series.

[00:00:12] Today, we’re talking about redefining complete.

[00:00:16] This series is dedicated to guiding you, the listener, the listening developer, regardless

[00:00:22] of where you are in your career, towards the mindset of the great developer.

[00:00:28] My job on this podcast is to help provide you with the tools, the insights, and the

[00:00:34] inspiration you need to shape your career as a developer and become truly great at what

[00:00:41] you do.

[00:00:42] Today’s episode is sponsored by Hired.

[00:00:45] On Hired, software engineers, project managers, data scientists, and designers can get five

[00:00:50] or more interview requests in a given week.

[00:00:53] We will talk more about Hired later on in today’s episode, but first, let’s talk about

[00:00:58] what it means to have complete code.

[00:01:02] This happens all the time with developers.

[00:01:05] We get tasks assigned to us in whatever task management system we are using, and we go

[00:01:10] and we write the code, and we check it out on our local system, whatever it is that we’re

[00:01:15] building.

[00:01:16] We go and look at it real quick.

[00:01:17] We push it up, and then we mark it as complete.

[00:01:21] And the reality is that this marking as complete is only marking one part of the process as

[00:01:28] complete.

[00:01:28] And truly, any great developer will tell you that completion is a series of things, not

[00:01:36] just simply writing the code, but a scale of things.

[00:01:40] There are multiple levels of completion that make up truly complete code.

[00:01:47] We’re going to talk about those multiple levels today, but I want you to understand the importance

[00:01:51] of today’s episode, the importance of this concept of complete.

[00:01:57] Because.

[00:01:58] If you view completing a particular task with code as a simple write the code and push it

[00:02:05] and it’s done, if that is your metric for complete, then you’re going to systematically

[00:02:11] have problems, right?

[00:02:13] Number one, you’re going to underestimate everything that you do.

[00:02:18] That is a huge issue.

[00:02:20] You’re going to underestimate everything you do because you believe that it only takes

[00:02:25] writing a little bit of code and you have that code.

[00:02:28] Already basically planned out in your mind.

[00:02:30] So it’s not a big deal, right?

[00:02:32] We think that completing a particular task is not really a big deal because we can write

[00:02:37] the code and push it and we’re done.

[00:02:39] And that’s simply not the case.

[00:02:41] But if we think that it is the case, or if we have ingrained into our brains by practicing

[00:02:46] it that way, if we go through those motions, if we think, well, I’m basically done with

[00:02:52] this.

[00:02:52] I just have a few other details to tie up before I’m totally done.

[00:02:56] If we think that way, then we’re going to.

[00:02:58] Again, chronically, systematically underestimate the work that we do.

[00:03:02] Not only will we underestimate, but we’re also going to undercharge for the work that

[00:03:07] we do.

[00:03:08] I don’t want to hang on this subject for too long because everybody has a different way

[00:03:12] of understanding this subject.

[00:03:14] And it’s easy to swing the total opposite direction and way overcharge for your work

[00:03:21] and way overestimate for your work.

[00:03:24] But it’s important to understand that completion of code.

[00:03:28] Is not simply completing the code and that if you think that it is that right, if you

[00:03:34] think that you can write the code and push it and it’s done, you’re going to have systematic

[00:03:39] business level issues that may be debilitating to your career.

[00:03:44] OK, it is that serious to understand the truth of this message of completing and following

[00:03:52] through all the way with all of those different elements of completion.

[00:03:58] Here’s another problem you’re going to face.

[00:03:59] If you don’t think about completion at every level of the scale, you’re going to face so

[00:04:06] many bugs, it’ll make your head spin.

[00:04:09] And because you’ve already put yourself in a hole of underestimating, you’re already

[00:04:13] going to be behind.

[00:04:14] Well, now your client is coming to you, putting more stress on your plate because guess what?

[00:04:20] The code you pushed yesterday broke today.

[00:04:23] And the problems continue compounding because if you believe that completion just makes

[00:04:28] pushing the code and calling it done, well, now you’re going to have issues when that

[00:04:34] particular client wants to scale.

[00:04:37] So if you want to be a great developer, then you have to avoid these problems.

[00:04:42] You have to learn how to estimate properly.

[00:04:44] You have to be able to deal with bugs before they occur.

[00:04:49] Hopefully more often than not, right?

[00:04:51] You shouldn’t be buried all the time trying to catch up because of these issues that keep

[00:04:56] on occurring.

[00:04:56] And you should be ready.

[00:04:58] You should be ready to help your clients scale when they need to.

[00:05:02] And we’re going to do another episode in the future, most likely on this concept of scale.

[00:05:06] But when I say scale in this particular context, basically what I’m talking about is changing

[00:05:11] the software, changing the software as the business grows.

[00:05:15] I’m not saying that the software suddenly needs to accommodate 10 million users.

[00:05:21] That’s not what we’re talking about when we talk about scale.

[00:05:23] We’re talking about changing requirements as the business grows.

[00:05:27] If you’re scaling, you’re going to need to be able to do that.

[00:05:28] If your software can’t do that tomorrow, then what you’ve built today is going to

[00:05:33] be incomplete tomorrow.

[00:05:36] Does that make sense?

[00:05:37] What you build today is incomplete tomorrow if you are unable to scale that software at

[00:05:43] the speed that the business is scaling.

[00:05:46] And you’re going to see each one of these things played out ways of solving these problems

[00:05:51] beforehand, right?

[00:05:53] Giving yourself the padding that you need, giving yourself the proper way.

[00:05:58] Giving yourself the proper way of understanding what it means to complete code.

[00:06:02] And we’re going to talk about what it means to complete code right after this short sponsor

[00:06:07] break.

[00:06:08] Today’s sponsor is Hired.

[00:06:10] On Hired, software engineers, project managers, data scientists, and designers can get five

[00:06:15] or more interview requests in a given week.

[00:06:18] Each of these offers has salary and equity provided up front, which means that you don’t

[00:06:24] have to ask the awkward question of how much am I going to get paid?

[00:06:27] How much am I going to get paid?

[00:06:28] How much am I going to get paid?

[00:06:28] How much am I going to take this job?

[00:06:29] They have full-time and contract opportunities.

[00:06:32] So this isn’t just for those of you who don’t have jobs.

[00:06:34] It’s also for those freelancers out there who are looking for better contract opportunities.

[00:06:39] Users can view the interview requests they get and accept or reject them before they

[00:06:44] ever talk to the company.

[00:06:45] So there’s never an awkward conversation.

[00:06:48] Hired works with over 3,000 companies ranging from startups to large public facing companies.

[00:06:53] And it’s totally free for you as a developer.

[00:06:58] Or as a project manager, whatever you are, you can go to Hired.com and use it 100% free.

[00:07:04] Now, before you head over to Hired, let me tell you about the special link and what you

[00:07:08] get since you’re already getting to use Hired for free.

[00:07:12] Why would you use a special link?

[00:07:13] Well, Hired normally provides $1,000 of a thank you bonus if you accept a job through

[00:07:19] their system.

[00:07:20] But if you use the special link, which is Hired.com slash developer T, that bonus doubles

[00:07:27] to $2,000 when you accept the job.

[00:07:30] That’s Hired.com slash developer T.

[00:07:33] You get a double bonus up to $2,000.

[00:07:37] Hired cares about your privacy and they’ll hide your profile from your current employer

[00:07:41] and anyone else you want.

[00:07:43] So you basically have no reason not to go and check it out.

[00:07:46] Hired.com slash developer T and that’ll double that $1, 000 b o n u s t o$ 2,000 when you accept

[00:07:54] a job.

[00:07:54] Thanks so much to Hired for sponsoring today.

[00:07:57] Episode of developer T.

[00:07:59] So hopefully I’ve convinced you of all of the reasons you have to redefine what you

[00:08:04] think of complete code.

[00:08:06] But what is complete code?

[00:08:09] Well, I’m going to give you a couple of different things that maybe you haven’t thought of in

[00:08:13] the past.

[00:08:14] Of course, writing the code itself, right?

[00:08:17] Writing the code that accomplishes the task that you’ve been given.

[00:08:20] That’s a part of completing that code.

[00:08:23] But there are a few other pieces of that.

[00:08:27] The puzzle that I want to talk about today.

[00:08:29] Today, we’re going to talk about three specific ones.

[00:08:31] And if you aren’t thinking about these three things, then you are not completing your code,

[00:08:35] period.

[00:08:36] I don’t care what anyone else tells you.

[00:08:38] Your code is not complete until you’ve thought about these three things.

[00:08:43] Number one, is your code tested?

[00:08:46] Is your code tested?

[00:08:48] If you can test it programmatically, especially, that is a good start.

[00:08:54] Testing means something different for every piece of code.

[00:08:57] The most important thing here is that you have what are called acceptance criteria or test criteria.

[00:09:05] What this means is that you have defined the state that your application will be in when

[00:09:12] this code is complete.

[00:09:15] All right.

[00:09:16] So when you can do this programmatically, it’s even better.

[00:09:19] Your programmatic test will define certain actions and the expectations of those actions.

[00:09:26] All right.

[00:09:27] Go and read through a few tests online.

[00:09:29] You can read RSpec tests if you’re writing Ruby, Jasmine tests if you’re in JavaScript.

[00:09:34] There are plenty of testing suites out there.

[00:09:36] It doesn’t really matter which one you use, but you’ll notice that all of these have a

[00:09:41] particular structure of way of doing things.

[00:09:43] These test criteria are expressed in those tests.

[00:09:47] You can write test criteria in plain English, particularly if you’re not testing your code

[00:09:52] programmatically, which I recommend that you do test it programmatically.

[00:09:56] But sometimes, you can write test criteria in plain English.

[00:09:56] Sometimes, that’s impractical or that particular language or that framework doesn’t have testing

[00:10:02] really supported, so it’s kind of a difficult piece of overhead to introduce testing.

[00:10:07] For example, if you’re building a WordPress site, it may be a little bit difficult to

[00:10:13] test that programmatically, so you may need to write out in plain English what the acceptance

[00:10:19] criteria is for that particular piece of code.

[00:10:22] Sometimes, that test criteria may actually be based on performance.

[00:10:26] Like, this particular algorithm needs to run at this particular speed.

[00:10:31] It may also be based on functionality.

[00:10:34] To take the previous algorithm, you may need for that algorithm to actually work properly.

[00:10:39] Most times, you’re going to have multiple tests to accomplish a single criteria.

[00:10:45] And there are a ton of things that we could talk about with testing here, but we’re going

[00:10:49] to leave that for you to go and explore and determine what are the best practices when

[00:10:54] it comes to testing.

[00:10:55] But if your code is not testing, then you’re going to have to do a lot of testing.

[00:10:56] If your code is not tested in some way, whether that’s manually or programmatically, if your

[00:11:01] code is not tested, then it is simply not complete, period.

[00:11:05] Go and test your code.

[00:11:07] Don’t ship code until it is tested.

[00:11:09] You’re going to face problems in the future if you don’t test your code eventually.

[00:11:13] Eventually, you’re going to write code that has a bug in it, and then you’re going to

[00:11:16] push that code, and once you push it, once you push code that has a bug in it, you may

[00:11:21] not know it until down the line.

[00:11:22] And it’s going to be a whole lot harder to track that bug down.

[00:11:26] If you’re out of the context of working on that code, then it would be to just avoid

[00:11:30] it altogether in the beginning.

[00:11:32] Now, don’t hear me wrong.

[00:11:34] Tests do not prevent bugs.

[00:11:37] They don’t prevent bugs.

[00:11:39] People prevent bugs, right?

[00:11:41] And people are fallible, and therefore your tests are going to be fallible.

[00:11:46] You’re not going to be able to catch every single bug.

[00:11:48] And your clients need to know this.

[00:11:50] Sometimes they will find bugs in software.

[00:11:53] Even the best software companies in the world.

[00:11:56] In the world, ship software that has bugs in it.

[00:12:00] If it doesn’t have bugs in it today, it could have bugs in it tomorrow because the environment

[00:12:05] that the software is running in may change.

[00:12:08] So it’s not the end of the world if you end up shipping a bug.

[00:12:11] But it’s not a good idea to ship software that isn’t tested for obvious bugs.

[00:12:16] If you ship something to a website that takes down the entire site, that’s an example of

[00:12:21] when you should have tested it.

[00:12:22] You should have figured out that that particular piece of code was going to be a bug.

[00:12:26] That site was going to break that site.

[00:12:30] Now we’re going to take a quick diversion and talk about environments.

[00:12:33] If you are testing and you’re only looking at your code locally, and it only works on

[00:12:38] your local computer, and then you push it up to your remote environment, your staging

[00:12:42] or your production server, and it’s broken on the server, then guess whose fault that

[00:12:47] is.

[00:12:48] It’s not the person who is managing the server’s fault.

[00:12:51] It’s your fault.

[00:12:52] I know that sounds harsh, and I’m not meaning to place blame on you or make you feel like

[00:12:56] or make you feel bad, but ultimately your local machine doesn’t really matter, right?

[00:13:01] Your local machine needs to be matching whatever that remote environment is.

[00:13:07] There are plenty of ways to make this happen, but make sure that your local machine, at

[00:13:13] least in the major portions, the PHP version, for example, on your local machine, you need

[00:13:18] to be able to set that to the same version that you have on the remote machines.

[00:13:22] You need to be able to have the same serving environment.

[00:13:26] So, for example, if the remote machine is using NGINX and your local machine is using

[00:13:31] Apache, you need to install NGINX on your local machine, and here’s why, okay?

[00:13:35] I’m going to explain to you why, what you’re doing.

[00:13:38] If you write code for your local machine and it doesn’t have bugs on your local machine,

[00:13:43] that doesn’t mean it’s bug-free, okay?

[00:13:45] And here’s why.

[00:13:46] If you were to try to run Ruby with a PHP interpreter, if you try to run your Ruby code

[00:13:55] through a Java…

[00:13:56] Java interpreter, if you try to put your Ruby code into the browser and expect it to

[00:14:00] output HTML, it’s not going to work.

[00:14:03] And the reason is because you’re trying to run Ruby in the wrong scenario.

[00:14:07] There’s virtually no difference in you trying to run your Ruby through a JavaScript interpreter

[00:14:13] and you trying to run code on your local machine and on a remote machine when those machines

[00:14:20] are not at parity with each other, okay?

[00:14:22] In other words, if you’re writing PHP for PHP…

[00:14:26] PHP for PHP 7 on your local machine, but your remote server has PHP 5 installed, then

[00:14:31] you’re probably going to have issues when you push that code.

[00:14:35] Now, if you happen to have control of your remote server, if you are running something

[00:14:40] like a Linode server, Linode is a sponsor of the show, thanks, Linode.

[00:14:44] If you happen to have root access to that server and you can update PHP to PHP 7, well,

[00:14:50] then great.

[00:14:51] You can make those two machines have parity with each other.

[00:14:54] You can make the…

[00:14:56] The remote machine match your local machine, but it is never an excuse for a great developer

[00:15:02] to say that it works on my local machine.

[00:15:06] That is never a good excuse.

[00:15:08] If your local machine can interpret Ruby through its JavaScript compiler, then that doesn’t

[00:15:14] matter in practice.

[00:15:16] That doesn’t matter because when you push it, suddenly it’s broken.

[00:15:21] Suddenly the code that you wrote that didn’t have bugs on your local machine, it has…

[00:15:26] Bugs in the real environment that it’s running for the user.

[00:15:30] The user is experiencing bugs.

[00:15:31] It doesn’t matter if it runs on your local machine, if it doesn’t run on the remote machines.

[00:15:37] So, once again, number one, for completion of code, it has to be tested.

[00:15:43] Number two, your code needs to be verified.

[00:15:47] Your code needs to be verified.

[00:15:49] What’s the difference between verification and testing?

[00:15:52] Well, your code could be passing all of your tests,

[00:15:55] but it could…

[00:15:56] It could be a usability nightmare.

[00:15:58] Your code could be passing all the tests, and it could still have bugs because you didn’t

[00:16:03] write the right tests.

[00:16:05] Verification means that not only have you tested your software, but you have verified

[00:16:10] that the solution meets the user’s needs.

[00:16:14] You’ve actually walked through all of those processes for the user, and using both quantitative

[00:16:19] and objective means, and qualitative and subjective means, you have evaluated the

[00:16:26] software, and you can see that that software is complete.

[00:16:28] Typically, this involves a bit more human evaluation rather than programmatic evaluation.

[00:16:35] Remember that passing tests does not mean bug-free.

[00:16:40] I can’t stress this enough to you.

[00:16:42] Just because you have 100% test coverage and all of your tests are passing does not mean

[00:16:48] that your code is of good quality.

[00:16:51] It doesn’t mean that it’s verified.

[00:16:53] No tests will cover every…

[00:16:56] Every possible use case.

[00:16:57] So verification is needed to determine if the practical use of that code has actually

[00:17:02] been accomplished.

[00:17:04] Okay?

[00:17:04] This is well after you’ve written all of the code for that particular problem.

[00:17:08] Writing that code does not mean complete.

[00:17:10] Once again, you have to test it, and you have to verify it, and number three, you need to

[00:17:15] review that code, or specifically, you need someone else to review that code, particularly

[00:17:21] if you’re on a team.

[00:17:23] Now, if you’re freelancing, this is a little bit harder to do.

[00:17:25] Maybe you can…

[00:17:26] Maybe you can have another freelancer come in on a project, or maybe you can have a mentor

[00:17:30] look over your code, but really, you need to have someone reviewing your code.

[00:17:35] You need to make sure that the code is reasonably flexible for future changes, particularly

[00:17:40] if you have someone else who has worked on the same project, and especially if they worked

[00:17:44] on the same project a little bit longer than you, really what you’re doing is you’re saying,

[00:17:49] hey, I’ve written this code for something that you’ve already been writing code for.

[00:17:52] You know this system, and I know a little bit about this system.

[00:17:56] Let’s both do a cross-check on my sanity on the things that I’ve written here, so if

[00:18:02] they come in and they say, hey, you know, this looks like it’s not going to be very

[00:18:06] flexible for the changes that we’re going to be doing in this other part of the same

[00:18:10] project, well, maybe you need to change that code a little bit before you ship it, right?

[00:18:15] Maybe that means that that code that you wrote is actually not complete.

[00:18:20] Surprise.

[00:18:20] Once again, we’re in a situation where you wrote code that may have functionally passed

[00:18:26] the tests, it may have passed the verification standards, but because it created an unnecessary

[00:18:33] restriction on future changes, it needs to be changed to be more flexible.

[00:18:38] Does your code follow code style standards?

[00:18:41] Maybe there is a particular style for this project, or maybe you are a junior developer

[00:18:46] and you have a senior developer looking over your code, and they say, hey, you know, we use

[00:18:51] two spaces instead of tabs, and you need to go through and change

[00:18:55] all of your code.

[00:18:56] All of your tabs to two spaces.

[00:18:58] Very simple things like that.

[00:19:00] Linting, these are things that can happen with a code review process.

[00:19:04] Your code could be reviewed, by the way, by a linter, which is not a human.

[00:19:08] It’s just a process of running your code through and checking to see, am I actually following

[00:19:13] the code style guides that have been set up through the linter?

[00:19:18] Does your code depart from the general structure of the project?

[00:19:22] This is another thing that a code review might reveal.

[00:19:25] Maybe you like to name your files a particular way, but that doesn’t necessarily match up

[00:19:31] with the structure of the file naming system that the project already had set up.

[00:19:37] Another question you could ask, does my code introduce any dependencies that are unnecessary

[00:19:41] or redundant with other parts of the code?

[00:19:44] If someone has been working on the project for a little bit longer than you, they may

[00:19:48] say, hey, you know what?

[00:19:49] That code kind of looks like something else that we did over here.

[00:19:53] Now, it would be nice if you could catch that.

[00:19:54] A little bit earlier in the process.

[00:19:56] So you might recognize that reviewing your plan is probably a pretty good idea as well.

[00:20:03] But certainly, you don’t want to introduce any extra dependencies that are already solved

[00:20:09] by a different code package.

[00:20:10] You don’t want to have two XML parsers that do the same thing, but you’re using two different

[00:20:16] versions of that in the same project.

[00:20:18] That is redundant.

[00:20:19] It’s unnecessary.

[00:20:20] And it’s going to make the project really kind of convoluted into the future.

[00:20:24] So.

[00:20:24] You want to catch that before you ship it.

[00:20:27] And finally, when you do a code review with another human, having that second set of eyes

[00:20:32] will catch bugs that you may have completely overlooked.

[00:20:37] They may also be able to provide better solutions.

[00:20:41] Maybe they have a particular experience with an algorithm that they’ve written in the past

[00:20:45] that solves what you’re trying to do a little bit better than you solved it.

[00:20:49] Having a code review will reveal these things to you.

[00:20:52] It doesn’t always have to be someone that’s senior to you.

[00:20:54] It could be somebody that is even junior to you, right?

[00:20:58] Somebody who has less experience than you can come in and maybe they need to learn from

[00:21:03] your code, but maybe they have insight as to how you could do something different.

[00:21:09] So once again, we’re talking about code completion standards, redefining the concept of complete.

[00:21:17] When you ship code, when you send code to the production server, if it has been tested,

[00:21:23] if it’s been verified.

[00:21:24] And it’s been reviewed, you are in so much better of a place than if you simply wrote

[00:21:31] the code and pushed it up without thinking about it.

[00:21:34] And you’ll notice that testing your code and verifying it and reviewing your code takes

[00:21:39] more time than it does just to write it.

[00:21:43] And so you’re going to start estimating differently and you’re going to start avoiding more bugs

[00:21:49] in the future.

[00:21:50] You’re going to start writing better software, period.

[00:21:53] You’re going to be.

[00:21:54] You’re going to be a great developer.

[00:21:57] If you can adopt this standard for your code completion, don’t send out code that hasn’t

[00:22:02] been tested.

[00:22:03] Don’t send out code that hasn’t been verified and don’t send out code without having it

[00:22:08] reviewed.

[00:22:09] Not only will you have better estimations and fewer bugs from the start, but you’re

[00:22:15] also going to have much more flexible, scalable software so that you can grow with your clients.

[00:22:24] Thank you so much for listening to this second installment of the Great Developer Mindset

[00:22:30] series.

[00:22:31] Once again, this series is dedicated to guiding you, the listener, towards the mindset of

[00:22:36] the great developer.

[00:22:38] My job on this podcast on Developer Tea is to help provide you with the tools, the insights

[00:22:43] and the inspiration you need to shape your career as a developer and become truly great

[00:22:49] at what you do.

[00:22:50] Thank you again to today’s sponsor, Hired.

[00:22:53] On Hired Software.

[00:22:54] Engineers, project managers, data scientists, and designers can get five or more interview

[00:22:59] requests in a given week.

[00:23:01] Not only is Hired free for you as the user, but if you use the special link in the show

[00:23:06] notes at spec.fm, you get a doubled bonus whenever you accept a job through Hired.

[00:23:12] That’s a $2,000 bonus by going to Hired.com slash Developer Tea.

[00:23:18] Thank you so much for listening to Developer Tea.

[00:23:20] I hope that this series is continuing to be useful to you.

[00:23:24] Make sure you reach out and let me know if you are enjoying the Great Developer Mindset

[00:23:28] series.

[00:23:29] And until next time, enjoy your tea.

Vox

Explorador