Developers all over the world can agree on this. There is a lot of poorly written code out there in every shape and form possible. We're being faced with the problem of people getting pushed to produce work too fast and it's dropping the quality of our code. It's amazing how quickly some projects get pushed through because they miss some of the most basic parts of a project, like a plan!

Even amongst the chaos of the business side, you can still do a few things to write better code.

Plan it out

Sometimes I'm sad that this still needs to be mentioned but there are a lot of reasons planning gets skipped. You'd be surprised how many projects get passed to developers and all they have to go on is a few vague sentences about what "it" should do. The people involved in managing the project will set up meetings to talk you through what they are looking for and that's all you get.

It's up to you to make something out of the little scraps of information you can get up front. So you need to really plan this out because at the end of the day they're going to be asking you when it's going to be done.

I mean really sit down and think about the potential scope of this thing. How big of a project is this? How much time do you think you'll spend testing and debugging? Are there other features you think they will need or anything that will make it easier to use? If you take your time and plan things out like this, it won't stop all of the major meltdowns but it will help you avoid a lot of them.

Think about how a person will use it

I know that's usually the web designer's job, but it won't hurt you to think about usability as the developer. If you can slap an auto-completer on a search input just do it. It can take a extra time to do these little things but they will make a world of difference to the end users.

When you're doing testing in your local environment and you notice you need to do some trickery to get a button working, just fix it now. The people who end up using this thing will kind of thank you for it. Plus it'll help you find and think through any potential bugs.

After you consider some of the crazy, most unlikely things a user could do and you write the code to handle those things, you'll save yourself hours of debugging time. Yes, it's more work up front but the effect it'll have on your career is great. Once you become known as that person who writes bug-resistant code, it's only up for you.

Go one layer down

This is one I recently learned that's changed the way I think about my code. It goes back to those… … frameworks. Sometimes the level of abstraction they use goes too far and you lose track of what you're really writing. One subtle example of this is jQuery.

How many times have you used the $ for variables? Do you remember what it means? Go a layer below the jQuery and you have pure JavaScript. If you dig through the JavaScript you can figure out what the $ is.

That's what I mean by go one layer down. Make sure you understand the language or the concept that the tool you're using is built on because it'll make it easier for you to fix problems that pop up.

Keep your code clear

All of the code you write should have a purpose. If there's anything in your code that's confusing to you then you need to find a way to make it clear. Use good variable and file names. Stick with a certain naming convention. These are some basic best practices that are easy to overlook in the heat of a sprint.

Consistency is going to make your code a lot easier to debug and update because you'll know exactly what everything is. No one will have to wonder what you were trying to do when you wrote that chunk of code because it'll be clear as day. You have to find a balance here though.

Getting caught up in the super small details isn't going to make your code better. If you have a time crunch and the IDE did some weird formatting thing to your files and the code still runs, deal with it later. It's just a bunch of spacing that makes the file look ugly.

Documentation

One of the most dreaded things for web developers is writing documentation. You have to decide how detailed you get and how much time you have but some documentation is better than none. Even if it's just a few tips on how to get a project set up or a quick guide on how the project works, something is better than nothing.

Documentation gives your project that polished feel and it'll help other developers who join you or maintain it after you get up to speed faster. Even if it's just a few comments in the code about what stuff does or why it does it a certain way, anything is helpful.

This all sounds good, right? If you're wondering where you would get the time to do all of this on top of actually writing the code, let me tell you a secret. You take it out of your "research" time. You know what I'm talking about. 😏 It can be as short a 10 minutes. Spending any time on any of this stuff will help you more than you think.

Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding