Header Ads

How To Write Code Faster: Easy Tips

How to Save the Most Money on Textbooks

So in my opinion, one of the worst parts about coding is how time-consuming and mentally exhausting. It can be. Oftentimes you spend entire days, multiple hours in a day, just trying to find bugs, just trying to solve problems. Well, it's really frustrating when you put a whole day's worth of work into writing some type of code and really have nothing to show for it.

So in this article, I wanted to share with you 5 tips/strategies that you can use to write code faster. Now, what I mean by this is not just typing faster on the keyboard or getting more lines out into the IDE. I'm really talking about how you can write code in a better way, such that you're going to have less bugs.

And you're just going to be more efficient when you're actually going through the programming and coding process. This is something that I really didn't figure out until I got into university and started working my first job and a lot of these tips and strategies are super simple.

And they're just things to keep in the back of your mind while you're actually writing your code. So with that said, let's go ahead and get started and talk about 5 tips/strategies you can use to write code faster...

5 Ways To Write Code Faster

1. Make a plan

So the first and most important tip on my list is to write a plan before you write any kind of code. When I say the plan, this can be whatever you want it to be. It doesn't even have to be written down. But the idea here is that you really should think about your project or think about the problem you're solving pretty deeply. Before you go into the code and start writing anything.

This is going to save you a lot of lines of code in general. It's going to save you a lot of time and it's going to force you to really make sure that the solution you're coming up with is accurate and works for your entire project.

It's very easy when you jump right into the code immediately, without thinking about anything, to forget about different aspects or to, you know, forget a feature that you need to implement or something like that. And then all of a sudden be halfway through your project and realize that, Oh crap, what I just wrote is no longer going to work.

This is not compatible with the other thing that I need to implement, where I've made a critical error. Now I'm going to have to redo this because it just doesn't work the way it needs to. This is what a plan helps you avoid. And it also just makes it so that when you get into the coding environment, you really know exactly what you're doing.

You don't have to stop and think about all of these small little things that should have been thought about beforehand. You have a little sheet or you have some steps that you're gonna fall along with just take those steps and you transcribe them into code.

It's much easier to do these two things separately and not have to come up with a solution while coding it out at the exact same time. So hopefully this was persuasive enough to get you to write a little bit of a plan.

Again, this does not need to be very detailed. What I do for myself is usually just write bullet points of kind of the main things that I need to complete.

And then maybe within those main things, I have some subproblems and that just gives me a good place to start. It makes me have a very kind of structured approach to my coding and genuinely saves me a ton of time.

2. Keep it simple

I'm going to keep it short. This is to keep it simple. That is the tip. Keep it simple. Whenever you are faced with a decision and you have different routes that you can go down or different paths that you can take almost always is going to be preferred to take the simple approach.

The reason for this is that the simple approach is easier to understand, easier to read and write, and easier to debug.

And that is going to save you a tremendous amount of time. If you decide to try to implement something using like the most complicated, convoluted way you can think of doing it, that is just going to be more difficult to do naturally, right? It's going to be harder to think about doing that.

it's going to be much harder to debug, especially if something goes wrong, you're going to have to try to understand what you were thinking when you went through this approach. And if anyone else has to read your code, well, good luck to them because it's going to take them a tremendous amount of time.

Even yourself, let's say a month or even a week in the future, you go back and you're looking at this. Cody wrote all of a sudden, you have no idea what's going on. And it spends you at least the same amount of time. It took to write it, even just understand what is going on in this code.

So hopefully those are enough of a reason, but really it's just much better to do things simply. And oftentimes I see this, especially with a lot of beginner programmers, you know, they learn some new tool or they learn some new, I don't know, like language feature and they just want to use it.

They want to show off. They want to be like, yeah, I understand how to use Lambdas. Oh, I can write this function that solves this problem in one line of code, only look at this. That's great. That's cool. Good for you, but it doesn't help you at all right. It solves the exact same problem.

It just much more complicated. And if anything, it's going to cost you time in the future. So hopefully that's enough of the reason.

3. Use a Debugger

To write code faster is simply to use a debugger. And there's not really much more I can say about this. A debugger is just a superior tool when it comes to finding bugs in your program. If you've never used one before I promise you, it's a knotty difficult tool to learn how to use a lot of people for some reason are intimidated by it.

But what it lets you do is pause the execution of code at any point in time in your program. So let's say you want to look at the state of a bunch of variables. Well, you would place a breakpoint right before, or right after say variable gets changed to something.

And then at that point in time, once you hit the breakpoint, you can view all of the variables in the current scope. You can see all of the methods on them. You can see what type they are. You can see all of the internal information and just anything that you would print out. You can see.

And it's just an, a better interface. It's better to look at. You can then step through the code slowly and see how variables are changing. It just helps you a ton, saves you a ton of time, and is really necessary if you're working on a large project. So, learn and use a debugger.

4. Write automated tests

Now, when I say test, this could be anything that you could imagine. This could be a unit test, a functional test. This could be a full test suite of a bunch of different things. You can go as crazy as you want with tests, but just writing really basic tests that will test out things that you manually are going through constantly will save you a ton of time.

And usually, I'm very guilty of this. I get stubborn. I really don't want to write the test. And then I end up manually testing the exact same thing like 20, 30, 40 times until eventually it starts working. Whereas what I could have done is spent two minutes write a really basic test script, and then just ran that script.

Whenever I wanted to see the output, it would tell me, Hey, your test passed, Hey, your test failed. And then I can continually use that test throughout the entire project to make sure I didn't break something that I wrote previously. So tests are super valuable.

They are your friends. Yes, they are a pain to write, but really they're definitely worth it. And if you find yourself spending more than a few minutes, testing out something manually, it's probably a good idea to just bite the bullet and write a damn test for it.

5. Take frequent breaks

Tip number five may seem counterintuitive. I promise it is not. And this is to take frequent breaks. Now, this is fairly well known in the programming community. And there's a lot of jokes about this. You know, you see the jokes of like programmers solve a lot of their problems on the toilet, things like that, but it honestly could not be more true.

I cannot tell you how many times I've been looking at a bug for, you know, hours at a time I get up, I walk around and I go talk to my friends, something like that. And then all of a sudden, I just have this kind of, you know, epiphany or light bulb in my head. And I've just solved the problem out of nowhere.

I have no idea how it came to me, but as soon as I got up from that screen walks around, had the blood pumping. I was able to fix the problem or even other times where maybe I don't fix it in that small break. I come back to the computer. I look at the screen and within two minutes, I'm like, Oh, this was a stupid issue.

This is where the bug is. And it was just something that I never would've thought to look at. I was so kind of dived into my perspective. I was, you know, have this tunnel vision on where a thought the problem was. And it wasn't until I took kind of a step back, took a small break, and came back to the computer that I was able to solve that problem.

So especially if you're stuck on a bug, if you're really frustrated, take a break, relax, and come back to it. That's going to be a lot more productive than just sitting there, banging your head on the table, and trying to find where it is. So with that said, I hope you all enjoyed the article if you let me know in the comment section below.

No comments

please do not enter any spam link in the comment box.

Powered by Blogger.