Stop Sabotaging Your Code…Before You Even Code

We’ve all been there.

A new project lands in your lap and a quick scan of the design is promising. It seems straightforward and so, with a quick pre-coding-whiz stretch, you get to work.

You put on classical piano because you don’t need to pull out ‘Don’t Stop Believing’ for this one. You realize you’ll have a proper lunch hour today and you can finally walk that extra two blocks to get a bacon cheeseburger. You imagine yourself leaving the office at 5 and being the envy of the office.

It’s going to be a good day.

And then, suddenly, you’re ten hours in, you’ve consumed more coffee than an average Italian family, and you’re staring blankly at the screen, fighting the realization that you have no idea what to do. Parent elements are collapsing, each browser has a different output, changing the screen size makes you want to cry, and you’re throwing CSS on the page like a quarterback throws a Hail Mary.

An Angry Developer

There’s no way around it — you didn’t plan ahead and think through your approach. Here are 5 things you should ALWAYS do when starting a new project:


Yes, really. It may seem tedious in the beginning but taking the time to plan the architecture of your webpage will save you hours — and I mean HOURS — in the long run.

HTML Page structure being hand-drawn out on graph paper

This will help you to:

  • Pinpoint sections and design elements that are similar and identify most of your classes.
  • Identify areas that may be more complicated than they initially seemed.
  • Deeply think through how accessible your site is. Don’t be that developer who makes beautiful and responsive websites that are restrictive to people who aren’t you.
  • Write clean and DRY code
  • Make a list of technology platforms, third-party services, or libraries that you will need to set up and use for the project.

Don’t skip this, regardless of your experience-level. This initial 20% of the work will result in 80% of the quality of the finished project.


Color palettes, fonts, images, third-party platforms, and libraries are all things that should be set up before coding begins. There’s nothing more frustrating than getting in the zone, only to realize that one image is sized differently than the other eleven and you have to track down the designer or crop it yourself.

Check the sizing, sort everything in their appropriate folders, link in your source codes, and then move forward.


Most websites are split into different sections, such as Navigation Bar, About sections, Image Galleries, Contact Us sections, etc. And some programmers (like me) will take the approach of fully building out the HTML architecture and stylizing with CSS one section at a time. Do as I say and not as I do.

The premise makes sense, especially for new programmers, because you’d think that you can build individual components and essentially ‘stack’ them on top of each other. But — seriously — don’t do this.

You’ll be more likely to repeat yourself, have a poorly organized architecture, and lose out on implementing classes that will keep your CSS clean as your style sheet grows.

Write ALL of your HTML before you even think of making things look pretty.


Figure out how you want your CSS organized and implement your essentials (such as clearfix and box-sizing). Over time, you’ll find what works for you but here are two examples (one simple and one more complex) to get started.

Two examples of CSS Sectioning


Once coding commences, you’ll likely come across problem areas that you’re having difficulties debugging. When this happens, you’ll either:

  1. Step away from the computer for at least 20 minutes, or
  2. Move on to something easier to do

When you return to that initial problem, and you WILL have to return to it, those running notes will allow you to hop back on the issue more quickly. Once you figure out the problem, write the solution down too!

Every so often, reread those notes so that if you come across the problem again, you’ll know exactly how to fix it.

These things may seem obvious and straightforward…but you’d be surprised by how many programmers that don’t do them. Developers with 20 years of experience have ruined entire projects because they didn’t formulate a plan of attack and therefore had to restart from scratch.

Remember that it’s so much more important to stick to the basics and get it right every — single — time. Your clients and team will thank you for it.

Stop Sabotaging Your Code…Before You Even Code was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Powered by WPeMatico

Please follow and like us: